Полтора года назад я сидел с идеей сервиса для учёта заявок мастеров-ремонтников, пустым кошельком и стойким ощущением, что без бюджета на команду ничего не выйдет. Инвесторов не было, знакомых разработчиков тоже, а на руках — вечера после работы и пара выходных в неделю. Тогда я дал себе жёсткий срок: две недели и никаких оправданий. Если за это время не появится работающая версия, значит идея недостаточно хороша и её не жалко выбросить.
Главный вывод, который я сделал: стек выбирают не по хайпу, а по скорости получения обратной связи. Каждый инструмент я оценивал по одному критерию — сколько часов он сэкономит мне до первой живой заявки. Всё, что требовало изучения с нуля, настройки серверов или чтения длинных мануалов, отправлялось в корзину без сожалений. Побеждала не модность, а скучность и предсказуемость.
В итоге мой минимальный набор оказался скучным до зевоты. Фронтенд — обычные страницы на фреймворке, который я знал наизусть, без изобретения дизайн-системы и без красивых анимаций. Бэкенд и база — управляемый сервис, где таблицы, авторизация и права доступа настраиваются мышкой за один вечер. Хостинг — статический, с автоматическим деплоем из репозитория по коммиту. Уведомления и письма — готовый внешний сервис. Платежи на первом этапе я вообще не подключал: деньги собирал вручную, чтобы проверить готовность людей платить. Никаких контейнеров, очередей и микросервисов.
Самое сложное — не выбрать, а вырезать. Я запретил себе админ-панель и правил данные прямо в консоли базы. Отказался от мобильного приложения, потому что тот же веб отлично работает на телефоне. Выкинул личный кабинет с настройками, тёмную тему, историю изменений и онбординг с подсказками. Каждая такая фича — это дни работы и ноль информации о том, нужен ли продукт вообще. Минимальная версия должна отвечать ровно на один вопрос: возвращаются ли люди после первого использования.
Мой чек-лист запуска выглядел так. Сначала одна ключевая функция, описанная одним предложением, — если предложение получается длинным, значит это уже не MVP. Потом два-три реальных пользователя, которых я знаю лично и которым могу позвонить вечером. Далее самый уродливый интерфейс, который решает их задачу, без споров о кнопках и отступах. Затем форма сбора контактов и уведомление себе о каждой новой регистрации. После этого закрытый доступ по прямой ссылке, без рекламы, анонсов и постов в соцсетях. И в конце десять дней наблюдения за тем, что люди делают, а не за тем, что они говорят на словах.
Первые результаты оказались скромными, но честными. За неделю после запуска пришли одиннадцать человек, пятеро вернулись на третий день, а двое написали, чего им не хватает. Именно эти сообщения и стали моей настоящей дорожной картой — куда точнее любых моих догадок, придуманных в тишине кабинета. Одна из функций, которую я считал ненужной и едва не вырезал окончательно, оказалась ровно тем, за что люди были готовы платить. Я узнал об этом через двенадцать дней, а не через полгода разработки в стол.
Что бы я посоветовал тем, кто сейчас стоит в такой же точке. Не ищите идеальный стек, ищите самый короткий путь до первого пользователя. Пишите код так, будто завтра будете его выкидывать, — с высокой вероятностью так оно и случится. Договоритесь с собой о дате запуска и держите её, даже если внутри всё ещё стыдно за кривой интерфейс. И не считайте отсутствие денег главной проблемой: на старте деньги нужны не для разработки, а чтобы проверить, что кто-то действительно ждёт ваш продукт.
А теперь вопрос к вам, коллеги. Какой самый минимальный стек вы использовали для своего первого запуска и что помогало вам не утонуть в бесконечных доработках?
Главный вывод, который я сделал: стек выбирают не по хайпу, а по скорости получения обратной связи. Каждый инструмент я оценивал по одному критерию — сколько часов он сэкономит мне до первой живой заявки. Всё, что требовало изучения с нуля, настройки серверов или чтения длинных мануалов, отправлялось в корзину без сожалений. Побеждала не модность, а скучность и предсказуемость.
В итоге мой минимальный набор оказался скучным до зевоты. Фронтенд — обычные страницы на фреймворке, который я знал наизусть, без изобретения дизайн-системы и без красивых анимаций. Бэкенд и база — управляемый сервис, где таблицы, авторизация и права доступа настраиваются мышкой за один вечер. Хостинг — статический, с автоматическим деплоем из репозитория по коммиту. Уведомления и письма — готовый внешний сервис. Платежи на первом этапе я вообще не подключал: деньги собирал вручную, чтобы проверить готовность людей платить. Никаких контейнеров, очередей и микросервисов.
Самое сложное — не выбрать, а вырезать. Я запретил себе админ-панель и правил данные прямо в консоли базы. Отказался от мобильного приложения, потому что тот же веб отлично работает на телефоне. Выкинул личный кабинет с настройками, тёмную тему, историю изменений и онбординг с подсказками. Каждая такая фича — это дни работы и ноль информации о том, нужен ли продукт вообще. Минимальная версия должна отвечать ровно на один вопрос: возвращаются ли люди после первого использования.
Мой чек-лист запуска выглядел так. Сначала одна ключевая функция, описанная одним предложением, — если предложение получается длинным, значит это уже не MVP. Потом два-три реальных пользователя, которых я знаю лично и которым могу позвонить вечером. Далее самый уродливый интерфейс, который решает их задачу, без споров о кнопках и отступах. Затем форма сбора контактов и уведомление себе о каждой новой регистрации. После этого закрытый доступ по прямой ссылке, без рекламы, анонсов и постов в соцсетях. И в конце десять дней наблюдения за тем, что люди делают, а не за тем, что они говорят на словах.
Первые результаты оказались скромными, но честными. За неделю после запуска пришли одиннадцать человек, пятеро вернулись на третий день, а двое написали, чего им не хватает. Именно эти сообщения и стали моей настоящей дорожной картой — куда точнее любых моих догадок, придуманных в тишине кабинета. Одна из функций, которую я считал ненужной и едва не вырезал окончательно, оказалась ровно тем, за что люди были готовы платить. Я узнал об этом через двенадцать дней, а не через полгода разработки в стол.
Что бы я посоветовал тем, кто сейчас стоит в такой же точке. Не ищите идеальный стек, ищите самый короткий путь до первого пользователя. Пишите код так, будто завтра будете его выкидывать, — с высокой вероятностью так оно и случится. Договоритесь с собой о дате запуска и держите её, даже если внутри всё ещё стыдно за кривой интерфейс. И не считайте отсутствие денег главной проблемой: на старте деньги нужны не для разработки, а чтобы проверить, что кто-то действительно ждёт ваш продукт.
А теперь вопрос к вам, коллеги. Какой самый минимальный стек вы использовали для своего первого запуска и что помогало вам не утонуть в бесконечных доработках?