Это не туториал и не «10 советов как стать 10x-разработчиком». Это честный рассказ о том, каково в одиночку тянуть проект, который начинался как «сделаю себе небольшой сайтик про кино», а в какой-то момент превратился в полноценную соцсеть с лентой, профилями, рейтингами, совместным просмотром и фоновыми задачами. Без команды, без инвестора, без тимлида, который скажет «так делать не надо». Только ты, IDE и продакшен, который почему-то падает в два часа ночи. Делюсь стеком, организацией и граблями — без прикрас.
Как я докатился до жизни такой
Начиналось всё невинно. Хотелось места, где можно вести список фильмов, ставить оценки и видеть мнения живых людей, а не накрученные цифры. Прикинул — да тут на пару выходных работы. Знакомое чувство, да?
Через некоторое время «пара выходных» превратилась в каталог на десятки тысяч карточек, ленту активности, систему друзей, рейтинги, рецензии, подбор по вкусам, совместный просмотр и кучу фоновых процессов, которые что-то парсят, что-то генерируют и что-то рассылают. И всё это — на одном человеке. Я сам себе фронтендер, бэкендер, девопс, дизайнер, тестировщик, контент-менеджер и служба поддержки в одном лице. Спойлер: это одновременно и кайф, и боль.
Стек: почему именно так
Когда ты один, выбор стека — это не про «что хайповее», а про «на чём я доеду до результата и не утону в обслуживании». Мой набор:
Бэкенд — FastAPI. Python я знаю, FastAPI быстрый в разработке, асинхронный, с автодокументацией из коробки. Для соло это важно: меньше бойлерплейта — больше успеваешь.
Фронтенд — Next.js (App Router) на React. SSR из коробки (критично для SEO, об этом ниже), нормальная маршрутизация, и я могу не держать в голове отдельный фронт и отдельный бэк как два разных мира.
База — PostgreSQL. Поначалу был соблазн остаться на SQLite (быстро, без сервера), но как только появляются конкурентные записи и сложные запросы — упираешься в стену. Перешёл на PostgreSQL и ни разу не пожалел: JSONB, нормальные индексы, надёжность.
Redis — для кэша, рейт-лимитов и временных штук, которым не место в основной базе.
Плюс по мелочи: Nginx как реверс-прокси, systemd для сервисов, всё на обычном VPS. Никакого Kubernetes — для одного человека это способ потратить жизнь на обслуживание инфраструктуры вместо разработки.
Главный навык соло-разработчика — это не код
Звучит странно, но самое сложное в одиночной разработке — не написать фичу, а не утонуть в них. Когда ты один, у тебя бесконечный бэклог и ноль людей, чтобы его разгрести. Поэтому выживание — это дисциплина, а не скорость печати.
Что реально помогло мне не сойти с ума:
Один патч за раз. Звучит банально, но это спасение. Не «перепишу пол-проекта за вечер», а одно изменение — протестировал — убедился, что работает — поехали дальше. Когда некому делать code review, твой единственный страховочный трос — маленькие проверяемые шаги. Большой смелый рефакторинг в одиночку почти всегда заканчивается продакшеном, который не поднимается, и тобой в три ночи с глазами по пять рублей.
Тестировать там, где живёт прод. Локально «у меня всё работает» — самая дорогая фраза в соло-разработке. Другое число воркеров, другой Redis, другой Nginx — и фича, идеальная на ноутбуке, разваливается в бою. Я приучил себя проверять критичное прямо на боевом окружении (аккуратно, на тестовых данных), а не верить локалхосту на слово.
Беспощадная приоритизация. У меня список идей длиннее, чем доживу. Поэтому вопрос не «крутая ли фича», а «оно вообще кому-то нужно прямо сейчас или это я просто хочу поиграться с технологией». Половина «гениальных» идей отлёживается в бэклоге и тихо там же и умирает — и это нормально.
Грабли, которые стоили мне нервов (и сна)
А теперь то, ради чего вы, возможно, и открыли статью. Грабли, на которых я честно посидел — и которые ждут любого, кто в одиночку тащит подобное.
Фоновое состояние в памяти и несколько воркеров. Завёл фичу, которая хранит состояние прямо в памяти процесса. Удобно, быстро. Запустил сервер в несколько воркеров для производительности — и фича развалилась: пользователи попадают в разные процессы, состояние не шарится, всё рассинхронено. Урок: либо состояние в общем хранилище (Redis/БД), либо такие фичи держим в одном воркере. Я выбрал второе и зафиксировал это железно, чтобы случайно не «оптимизировать» обратно.
Права на файлы после сборки. Классика: собрал фронт под одним пользователем, сервис запускается под другим — и привет, EACCES, белый экран, паника. Теперь после каждой сборки явно выставляю владельца на артефакты. Записал в чек-лист деплоя, потому что забывается ровно тогда, когда некогда.
node_modules не переезжает между ОС. Разрабатываешь на Windows, прод на Linux — нативные зависимости со скомпилированными бинарниками просто не заведутся, если тащить папку как есть. Только чистая установка на целевой системе. Очевидно? Да. Наступал? Тоже да.
Кэш сборки трогать нельзя. Один раз «почистил на всякий случай» кэш сборщика на проде — и сломал инкрементальную регенерацию страниц на сутки. Теперь правило: не уверен — не трогай, особенно то, что само себя обслуживает.
dev и prod базы — это разные миры. Держать конфиг так, чтобы случайно не сходить локальным кодом в боевую базу (или наоборот) — отдельная дисциплина. Один невнимательный запуск скрипта «не туда» — и ты долго думаешь, почему данные не меняются (а они меняются, просто в SQLite-файле, который никому не нужен).
Не запускай два тяжёлых процесса разом. Сервер не резиновый. Запустил тяжёлую фоновую генерацию — и параллельно пересборку фронта «чтобы не ждать». Память кончилась, OOM-killer пришёл и молча прибил процесс без всякого трейсбэка. Полчаса гадал, что случилось. Теперь тяжёлое — по очереди.
Миграции без тяжёлой артиллерии. Полноценные миграции через Alembic — это правильно, но в соло на ранней стадии я пошёл по пути «добавляем недостающие колонки на лету при старте». Спорное решение, и я понимаю риски — но для одного человека на этапе бурного роста схемы это сэкономило кучу времени. Главное — осознавать, что это технический долг, а не «так и надо».
SEO, про который все забывают, пока не поздно
Отдельная боль одиночки — про SEO часто вспоминают в последнюю очередь, а это для контентного проекта половина смысла. SPA без серверного рендера поисковики индексируют плохо, и можно полгода писать контент в пустоту. Пришлось разбираться: серверный рендер метаданных, карта сайта на десятки тысяч URL, корректный robots, борьба с «мягкими 404», когда фреймворк отдаёт «не найдено» с кодом 200 и портит индексацию. Скучно, неблагодарно, но без этого контентный сайт невидим.
Самое тяжёлое — вообще не техническое
Если честно, код — это самая лёгкая часть. Тяжелее всего психология.
Некому передать. Заболел, выгорел, пропала мотивация на неделю — проект просто стоит. Нет коллеги, который подхватит.
Некому сказать «ты молодец» или «ты идиот». Нет ревью, нет обратной связи. Ты варишься в собственных решениях, и легко месяцами катиться не туда, потому что некому ткнуть носом.
Туннель из фич. Когда видишь весь проект целиком только в своей голове, легко закопаться в бесконечное «ещё чуть-чуть допилю» и забыть, что продукт уже должен жить и приносить пользу, а не вечно полироваться.
Качели мотивации. Сегодня ты горы свернёшь, завтра смотришь на свой же код и думаешь «зачем я вообще это начал». Это нормально. Я научился просто переживать спады, не принимая в них стратегических решений вроде «всё снести и переписать».
Что я понял за это время
— Маленькие шаги побеждают героизм. Десять спокойных коммитов лучше одного бессонного подвига.
— Скучные вещи (бэкапы, мониторинг, чек-листы деплоя) важнее красивых. Именно они спасают, когда всё горит.
— Готовое и работающее лучше идеального и ненаписанного. Пользователю плевать на чистоту твоей архитектуры, ему нужно, чтобы кнопка нажималась.
— Один человек реально может тащить удивительно много — если не воюет сам с собой за идеальность.
Если интересно посмотреть, что из всего этого выросло — проект живой и доступен: кино-сервис vibemuvik.ru. Не зову регистрироваться и ничего не продаю — просто, если вам по ходу статьи стало любопытно, на чём всё это крутится в бою, можно зайти и потыкать. Там и лента, и рейтинги от живых людей, и совместный просмотр — то самое, что один человек собрал по вечерам.
А теперь к вам, потому что обратной связи в соло мне как раз и не хватает: кто ещё тащит большой проект в одиночку? На каком стеке, как боретесь с выгоранием и бесконечным бэклогом, где проводите черту между «допилить» и «уже пора показывать людям»? И главный вопрос — где, по-вашему, та грань, после которой соло-проект пора превращать в команду (и стоит ли вообще)? Делитесь, очень интересно собрать опыт таких же одиночек в комментариях.