Мы выбрали команду для стартапа. А потом началась настоящая боль: пришлось выкинуть половину «обязательных» функций

Меня зовут Иван. Я делаю Bloom - приложение для привычек, геймификации и ИИ-коучинга. Я думал, что самое сложное - выбрать разработчиков. Оказалось, это была разминка. Настоящая работа началась, когда мы с Paladin Engineering сели резать идею до MVP.

После подписания договора у меня было странное чувство облегчения.

Команда выбрана. Бюджет понятен. Сроки на бумаге есть. Можно наконец «делать приложение».

Наивно, конечно.

Через неделю я понял, что приложение в моей голове и приложение, которое реально можно выпустить за адекватные деньги, - это два разных продукта.

Bloom начинался красиво: трекер привычек, социальные механики, внутренняя валюта, уровни, ИИ-ассистент, чаты, персональные рекомендации, Health API, анимации, витрина наград. Если рассказывать друзьям за кофе, звучит убедительно. Если отдавать в разработку, звучит как способ сжечь бюджет до первой беты.

На первом рабочем этапе ребята из Paladin предложили не бежать сразу в код. Сначала разложить продукт на сценарии.

И вот это было неприятно.

Потому что сценарии быстро показывают, где у тебя продукт, а где фантазия.

Например, я был уверен, что социальная часть нужна сразу. Ну как без неё? Пользователь должен видеть друзей, сравнивать прогресс, отправлять реакции, поддерживать друг друга. Красиво же.

Потом мы разложили первый месяц жизни пользователя.

День первый: человек ставит привычку.

День второй: забывает.

День третий: возвращается или удаляет приложение.

День седьмой: если ничего не зацепило, всё, мы его потеряли.

И тут стало видно: социальная лента не спасает, если человек не понял, зачем возвращаться завтра. Значит, в MVP важнее не друзья, а петля возврата: напоминание, маленькая награда, понятный прогресс, нормальная реакция на срыв.

Это звучит очевидно, когда уже написано. Но до этого я реально защищал социальные функции как «основу продукта».

Не основу. Украшение на потом.

Второй болезненный момент - ИИ-коуч.

Я хотел умного ассистента, который понимает настроение, привычки, прогресс и говорит почти как человек. На созвонах это выглядело главным отличием Bloom.

Потом мы посчитали.

Чтобы сделать такого ассистента нормально, нужно продумать контекст, безопасность ответов, память, ограничения, сценарии срыва, стоимость запросов, fallback, модерацию. Иначе получится болтливый виджет, который иногда говорит банальности, а иногда советует странное.

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

Мне было обидно. Честно.

Но это был правильный срез. Лучше один полезный сценарий, чем имитация умного продукта на каждом экране.

Третий урок - экранов всегда больше, чем кажется.

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

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

Каждая «простая» функция тянет хвост.

Вот зачем нужен нормальный дизайн-спринт. Не чтобы сделать красивые картинки для инвестора. А чтобы увидеть продукт до того, как разработчики уже потратили две недели на не тот сценарий.

Мы с Paladin Engineering в итоге завели простое правило: если функцию нельзя объяснить через поведение пользователя в первые 14 дней, она не попадает в первый релиз.

Жестко? Да.

Но иначе MVP превращается в маленький enterprise.

Еще одно правило: у каждой функции должен быть критерий приемки. Не «сделать красиво», а что именно должно работать.

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

Разница огромная. В первом случае каждый представляет своё. Во втором можно проверить.

Самое полезное, что я вынес из первых недель разработки: основатель должен не просто придумывать продукт. Он должен принимать решения о том, чего не будет.

И это сложнее, чем кажется.

Потому что каждая выкинутая функция болит. Ты уже представлял её в презентации. Уже рассказывал друзьям. Может быть, даже инвестору. А потом сидишь и говоришь: «Нет, это после MVP».

Сейчас наш первый релиз Bloom стал меньше, чем моя исходная идея. Но он стал честнее.

В нем есть onboarding, привычки, прогресс, базовая геймификация, мягкая работа со срывами и ограниченный ИИ-помощник. Без социальной ленты. Без магазина наград на 40 предметов. Без сложной аналитики здоровья.

Зато это можно довести до состояния, где человек реально пройдет путь от установки до первой недели использования.

И вот это уже MVP.

Не презентация о будущем продукте. Не набор фичей, чтобы не стыдно было перед знакомыми. А первая версия, которая проверяет главный вопрос: возвращается ли пользователь?

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

P.S. Ведём открытый дневник разработки Bloom на vc.ru — с цифрами, решениями, ошибками и тем, что реально работает. Первый пост уже в процессе. Если интересно, как стартап делается не в презентациях, а вживую — залетайте.