- «Нам нужен MVP маркетплейса. Бюджет - 8 млн ₽, срок - 7 месяцев».
- «Кто ваши первые пользователи и за что они заплатят в первую неделю?»
- «Поймем после релиза».
Я слышал этот диалог много раз. Обычно с него начинается лишняя разработка: команда обсуждает Laravel 11, Node.js 20, роли и личные кабинеты, хотя еще не проверила самую дорогую гипотезу - нужен ли кому-то этот продукт. Если и читать дальше, то ради одной задачи: сократить путь от идеи до первых живых сигналов рынка и не тратить месяцы на код, который никто не просил.
На старте нужен не продукт, а ясная боль
Стартап на ранней стадии - это временная конструкция для поиска работающего продукта, аудитории и канала продаж. В таком режиме важна не полнота идеи, а скорость снятия неопределенности. Я обычно смотрю на три вещи: проблема повторяется, сегмент понятен, ценность можно объяснить одним предложением.
У нас был проект для сети салонов красоты. Основатель хотел «систему управления всем»: запись, CRM, склад, бонусы, отчеты. После 12 интервью стало ясно, что деньги теряются в двух местах: пропущенные записи и пустые окна мастеров.
Мы убрали почти все и оставили один сценарий: запись, подтверждение, напоминание, быстрая перепродажа освободившегося слота. Срок первой версии сократился с 16 до 6 недель. Это и был первый нормальный сигнал: проблема есть, за решение готовы платить.
CTO логистической платформы однажды точно сформулировал это в разговоре со мной: «Ранний продукт чаще ломается не об код, а об неверно выбранную боль».
До кода хватает прототипа и нескольких разговоров
Прототип и MVP до сих пор часто путают. Прототип нужен, чтобы проверить, понял ли человек сценарий и ценность. MVP проверяет поведение на реальном рынке: вернулся ли пользователь, оставил ли заявку, согласился ли на пилот, заплатил ли.
Мы обычно собираем кликабельный прототип в Figma за 5-10 дней и проводим 5-8 тестов. На практике этого хватает, чтобы увидеть, где оффер остается мутным, где экраны лишние и где логика понятна только команде.
| Формат | Срок | Бюджет | Что проверяем | На что смотреть |
|---|---|---|---|---|
| Прототип | 1-2 недели | 150-400 тыс ₽ | сценарий и понятность | проходит ли путь без помощи |
| MVP | 4-10 недель | 800 тыс - 3 млн ₽ | спрос и поведение | заявки, активация, пилоты |
| Production | от 3 месяцев | выше | масштабирование | удержание, экономика |
На одном B2B SaaS для закупок пользователи неверно трактовали около 40% элементов интерфейса. Если бы команда сразу пошла в код на Laravel 11 и PostgreSQL 16, она бы потеряла 6-8 недель на переделки.
Формат проверки выбирают по вопросу, а не по красоте
Если нужно понять структуру, хватает упрощённой схемы. Если нужно проверить, считывается ли ценность, нужен кликабельный прототип. Если вопрос в готовности платить, интерфейс иногда вообще не нужен.
Рабочая связка для раннего теста у нас простая:
- лендинг на Webflow
- форма на Tally или Typeform
- база в Airtable или Notion
- ручная обработка заявок
- созвон или пилот вместо личного кабинета
В проекте для B2B-логистики клиент хотел платформу подбора перевозчиков на Node.js 20 + NestJS, с рейтингами, чатом и биллингом. Мы сначала собрали лендинг, форму и ручной подбор исполнителей. За 2 недели получили 40 заявок, 8 целевых созвонов и 3 пилота. Спрос подтвердился еще до бэкенда.
До/после проверки
- До: идея «сделаем платформу для всех участников рынка», план на 5 месяцев, бюджет 3,4 млн ₽
- После: один сегмент, один сценарий, ручная операционка, тест за 2 недели и 120 тыс ₽
После такой проверки уже есть опора на факты, а не только на веру в идею.
Первые пользователи должны появиться еще до релиза
Если команда не может привести первых людей заранее, проблема часто в формулировке ценности. Люди не понимают, что именно улучшится после заявки: время, деньги, риск или выручка. До MVP я смотрю на сильные сигналы, а не на охваты.
Мне обычно хватает такого набора:
- 10-20 интервью с повторяющейся болью
- конверсия лендинга в заявку от 5% на теплом трафике
- 3-5 компаний, готовых на пилот
- письма уровня «когда можно подключиться?»
Если этого нет, я не спорю о стеке и не обсуждаю архитектуру. Сначала нужно получить внятное «да» от рынка.
Когда MVP уже нужен, а когда лучше притормозить
MVP имеет смысл делать, когда сегмент понятен, проблема повторяется, а главный сценарий можно измерить. Например: сократить обработку заявки с 20 до 5 минут или уменьшить пропуски записи на 30%. Пока такой гипотезы нет, разработка идет вслепую.
Один раз мы сами пошли слишком быстро. В wellness-продукте сразу сделали мобильное приложение: трекинг, рекомендации, кабинет, подписка. За 4 месяца собрали релиз, запустили трафик, получили установки - и слабое возвращение пользователей. Ошибка была не во Flutter и не в аналитике. Мы проверяли интерес к теме здоровья, хотя нужно было проверять конкретную повторяющуюся задачу.
Самый опасный бюджет в стартапе - тот, который тратят, чтобы не проверять реальность. Перед тем как писать первую строку кода, задайте себе один неприятный вопрос: если убрать интерфейс, бренд и презентацию, останется ли у вас что-то, за что человек действительно готов заплатить?
