Как одному собрать серьёзный продукт: разбор опыта разработчика, который 5 лет писал платформу по вечерам

Один человек, пять лет вечеров после основной работы, ноль команды — и в итоге живая платформа, которая держит трафик и почти ничего не стоит в обслуживании. Автор поста прошёл путь от «а почему не сделать своё» до щелчка тумблера «разрешить публичный доступ». История полезнее типичной заметки об успехе, потому что в ней видно, где именно одиночный проект увязает.

Замысел был скромный: не сносить чужие замки, а взять свою долю крошек. Пять лет назад он решил собрать полноценную платформу для найма с нуля — по вечерам, не бросая работу в корпорации.

Где на самом деле умирают одиночные проекты

Не в коде. Код пишется медленно, но пишется. Умирают на стыке: терминал, пайплайн деплоя, доступы, переменные окружения, часовой пояс между сервисами. Автор дошёл до запуска и обнаружил, что вместо одной стены перед ним очередь из стен — Kudu terminal, workflow деплоя в GitHub, IP-адреса Azure Web App Service, которым нужно соединиться с базой данных. За одной проблемой следующая.

Потом была та самая кнопка публичного доступа, звонок жене и маме, обратный отсчёт 3… 2.. 1 — и технические ошибки вместо праздника. На разбор с переменными окружения ушли выходные. Дальше платформа поехала.

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

Почему он не отдал весь код генератору

Попробовал. Как и большинство. А потом посчитал риски: как поддерживать то, чего не понимаешь, что делать при обновлении пакетов, корректно ли и безопасно ли обрабатываются данные. Ставить бренд на чёрный ящик, который вы не способны починить, — так себе идея.

Рабочий компромисс выглядит так: генератор кода — для черновиков, рутины и подсказок, но архитектурные решения и всё, что касается работы с данными, вы держите в голове сами. Иначе первый же сбой превращается в простой на неопределённый срок.

Набор навыков на одного человека

Разработка — только начало. По ходу проекта пришлось осваивать облачную архитектуру и UI-дизайн с UX-дизайном. И маркетинг, который он сам помечает как самую неприятную часть пути.

• UX — чтобы понимать, куда человек вообще нажимает и почему уходит.
• Архитектура облака — чтобы платить за инфраструктуру мало и спать спокойно.
• UI — потому что некрасивый интерфейс читается как недоделанный продукт, даже если под ним всё работает.
• Маркетинг — и вот его обычно оставляют на самый конец. Зря: публика о продукте сама не узнает.

Что даёт собственный стек

Два практических следствия. Первое: счёт за поддержку небольшой, потому что всё написано с нуля и под конкретную задачу. Второе: разворачиваться быстро — один человек принимает решение и меняет курс без согласований.

Дальше в планах аналитика и отчётность на d3.js, когда наберётся несколько месяцев данных. Сначала накопить данные, потом уже рисовать графики.

Самое интересное — продуктовая логика

Платформа задумывалась под контракторов, но оказалась полезной и для постоянных позиций. Смысл в прозрачности: кандидат получает заранее то, что обычно выясняется на третьем созвоне или после офера.

Мелочь, скажете вы. Но именно из таких мелочей складывается воронка найма: одна сторона экономит время, вторая не сгорает на переписке.

Что здесь можно повторить, а что не стоит

Перенимать стоит метод: строить по вечерам годами, не выпускать в прод незнакомый код, держать стек настолько своим, чтобы обслуживание стоило копейки. И отдельно — чек-лист запуска, собранный по граблям:

1. Прогнать деплой в отдельном окружении и убедиться, что соединение с базой поднимается само.
2. Проверить переменные окружения на всех стендах — классика, которая съедает выходные.
3. Включить публичный доступ и пройти путь нового пользователя руками.
4. Записать, что делать при падении: резервные копии, логи, кому звонить. Даже если звонить самому себе.

А вот самоуверенность из финала поста перенимать не надо — «вопрос не в том, добьётся ли продукт успеха, а когда». Публика может проголосовать иначе, и это нормально: платформа собрана так, что автор способен развернуться.

Присмотреться стоит к другому. В подписи под своим постом он перечисляет роли: продакт, дизайнер, архитектор, владелец бизнеса. Это точный список того, что в одиночном проекте никуда не делегируешь, и он же объясняет, почему пять лет — честный срок. Если у вас есть идея на вечера, важна не скорость, а то, останется ли у вас контроль над тем, что вы выпустили.