Рекомендуемый путь по умолчанию для одиночного разработчика

Вот маршрут, который сработал для бесчисленного множества проектов одного человека. Каждый шаг делается только тогда, когда он вам действительно нужен.

1. Прототип: статика + управляемый бэкенд-сервис. Разместите свой фронтенд на статическом хостинге (Cloudflare Pages, Vercel или Netlify). Для данных и авторизации опирайтесь на управляемый бэкенд вроде Supabase или Firebase, чтобы не запускать базу данных самостоятельно. Стоимость: фактически ноль.

2. Ранний продакшен: добавьте edge- или бессерверные функции. Когда вам понадобится серверная логика — секретные вызовы API, вебхуки, нестандартная авторизация — добавьте функции на той же платформе. По-прежнему масштабируются до нуля, по-прежнему дёшево, по-прежнему один деплой.

3. Настоящий продукт: перенесите бэкенд на контейнерную платформу. Когда приложение перерастёт функции (долго работающие процессы, фреймворк, которому нужен постоянный сервер, фоновые задачи), упакуйте его в контейнер и задеплойте на Railway, Render или Fly.io. Пусть AI напишет Dockerfile и конфигурацию платформы.

4. Масштаб или специализация: только тогда подумайте о VM или облачном провайдере вроде AWS. Вот где сложность (и ваш счёт) подскакивает. Большинству одиночных разработчиков этот шаг никогда не нужен, и это признак того, что вы делаете всё правильно, — а не ограничение.

Ошибка, которой следует избегать, — начинать с шага 4 потому, что это якобы то, чем пользуются «настоящие инженеры». Верно обратное: начинать с простого — это ход уровня сеньора. Вы всегда можете подняться к большему контролю, но вы не сможете легко вернуть месяцы, которые потеряли бы, сражаясь с инфраструктурой, которая вам не была нужна.