Выбор стека для одиночки: меньше частей — меньше поломок

Вход, оплата, письма, хранение файлов нужны почти каждому продукту, но ни один покупатель не выбирает вас за красивую систему сброса пароля. Это «типовые» части — их разумно брать готовыми (подробно — в следующем уроке). Свой код стоит писать там, где заключена ваша гипотеза из первого урока.

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

Прежде чем брать технологию или сервис, пройдите по таблице. Ответов «не знаю» должно быть мало, иначе вы выбираете по рекламе.

Критерий «Выход» полезно проверить заранее: попробуйте выгрузить тестовые данные из сервиса и открыть их у себя. Если выгрузить нельзя, вы привязаны сильнее, чем кажется.

Идея, которая стоит за этим критерием, описана в принципах The Twelve-Factor App: внешние службы подключаются как присоединяемые ресурсы, а код не должен различать локальный сервис и сторонний. Тогда замена базы или почтового сервиса сводится к смене настроек, а не к переписыванию приложения.

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

1. 1.Сайт и сбор заявок. Конструктор сайтов или статический сайт, форма заявки, заявки уходят в таблицу или в мессенджер. Подходит для проверки спроса. Своего сервера и базы нет — поэтому нечему ломаться.
2. 2.Веб-приложение со входом и данными. Один полнофункциональный фреймворк (интерфейс и серверная часть вместе), управляемая база данных с готовым входом пользователей, хостинг с выкладкой из репозитория. Частей мало, большая часть эксплуатации — на стороне поставщиков. Цена: вы зависите от их правил и лимитов; доступ к данным нужно настраивать осознанно, см. урок про доступ к данным в MVP на базе как сервисе.
3. 3.Продукт с собственной серверной логикой. Отдельное серверное приложение (например, для интеграций или обработки данных), управляемая база данных, платформа для запуска приложений. Больше частей, но больше свободы. Берите, если готовые платформы не покрывают ваш сценарий.

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

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

• не берите технологию только потому, что она модная или её хвалят в обсуждениях;
• не смешивайте без нужды несколько способов сделать одно и то же (два способа входа, три формата дат);
• держите проект в репозитории и фиксируйте версии зависимостей — основы Git здесь обязательны;
• если вам что-то подсказал ассистент, спросите у него альтернативу и компромиссы, а не только «как»; затем примите решение сами.

Выбор стека стоит записать в один абзац и положить в репозиторий (файл DECISIONS.md или раздел README). Через полгода вы или инженер, которому вы передадите проект, поймёте, почему всё устроено так.

Решение: <что выбрано — фреймворк, база, хостинг, готовые сервисы>.
Почему: <1–2 причины из критериев>.
Отказались от: <что рассматривали и почему не взяли>.
Цена выбора: <от чего мы зависим, какие лимиты и риски принимаем>.
Когда пересмотреть: <признак, что решение перестало подходить>.

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