На прошлой неделе я разбирал заявку от команды, которая хотела сразу оценку на платформу за 4,8 млн ₽ и 5 месяцев работы. У них уже был roadmap, роли, интеграции и стек - Node.js 20 + NestJS, PostgreSQL 16. Не было главного: кто купит это решение в первые 90 дней и почему именно сейчас.
Если упростить, ранний стартап - это не история про скорость написания кода. Это история про скорость опровержения слабых гипотез. На этом месте большинство команд теряет 6-12 месяцев, хотя проблему можно было поймать за пару недель.
Стартап начинается там, где еще нет ясного ответа
Новое приложение само по себе еще ничего не означает. Когда клиент понятен, канал продаж уже работает, а экономика сходится хотя бы на уровне пилота, это новый продукт или цифровое направление внутри бизнеса. Когда все три пункта еще под вопросом, вы в стартап-режиме.
У нас был проект для сети клиник: внутренний сервис записи врачей на Laravel 11. Там все было прозрачно - пользователи известны, сценарии понятны, эффект считался через сокращение ручной работы на 38%. Идея vertical SaaS для независимых стоматологий с подпиской 15-20 тыс. ₽ в месяц была уже совсем другой задачей. Спрос, цену и сегмент нужно было еще доказать.
Быстрый фильтр простой. Если у вас совпадают хотя бы 3 пункта, вы пока не запускаете продукт, а ищете рабочую модель:
- спрос еще не подтвержден
- неясно, кто первый целевой клиент
- цена не проверена переговорами или пилотом
- канал привлечения не дает стабильных заявок
- есть риск, что проблема придумана внутри команды
Чаще всего ломается не код, а логика проверки спроса
Команды любят обсуждать стек, архитектуру и найм. На ранней стадии это полезно, но вторично. На практике продукт чаще закрывается не потому, что бэкенд слабый, а потому что рынок не считает проблему важной.
У нас был кейс в закупках под NDA. Команда строила B2B-сервис для корпоративных закупок: личные кабинеты, роли, платежи, аналитика, API для 1С. Стек был крепкий - React 19, NestJS, PostgreSQL 16, Redis 7. Потратили 5 месяцев и больше 3,2 млн ₽, после релиза получили 0 платящих клиентов.
После 20 интервью всплыло неприятное: закупщикам не нужен был новый поиск поставщика. Их реальная боль была во внутреннем согласовании бюджета. Команда все это время улучшала решение для чужой, не самой острой задачи.
Если проблема не повторяется у рынка, скорость разработки только ускоряет потерю денег.
У нас была и своя ошибка такого типа. Для сервиса записи в салоны мы сделали аккуратный MVP, а потом поняли, что владельцам важнее снижение пустых окон у мастеров, чем красивый интерфейс для клиента. Первую версию пришлось пересобирать почти с нуля.
Прототип выгоднее кода, когда нужно проверить поведение
В B2B длинный цикл сделки, и фраза «это интересно» почти никогда не означает «готов купить». Поэтому на старте я смотрю не на реакцию в созвоне, а на действие: заявка, бронь демо, согласие на пилот, предоплата.
В прошлом году мы тестировали сервис онлайн-записи для узкой ниши. За 9 дней собрали связку из Figma, Framer, Яндекс Метрики и Telegram-бота для заявок. Запустили 2 оффера на две аудитории и получили разницу, которую на интервью никто бы не показал: сегмент А дал CR 7,8%, сегмент B - 1,9%.
Цена проверки была около 120 тыс. ₽. Если бы сразу пошли в кастомную разработку на Laravel 11 и PostgreSQL 16, ошибка стоила бы примерно в 10 раз дороже.
До теста / после теста
- До: «платформа для всех», 2 сегмента, список из 27 функций
- После: 1 приоритетный сегмент, 11 целевых заявок, первая версия урезана до повторной записи и напоминаний
Системно это выглядит так: дешевый тест убирает лишние функции еще до того, как они попали в оценку и календарный план.
У каждого формата проверки свой вопрос
Одна из типовых ошибок - считать MVP обязательной первой ступенью. На деле MVP - уже заметная инвестиция. До него есть несколько форматов, которые отвечают на разные вопросы быстрее и дешевле.
| Формат | Что проверяет | Срок |
|---|---|---|
| Схема сценария в Miro | Логику пути пользователя | 1-2 дня |
| Clickable prototype в Figma | Понимание интерфейса | 3-5 дней |
| Fake door на Framer | Интерес к офферу | 3-7 дней |
| No-code MVP на Bubble | Реальное использование | 2-4 недели |
| Concierge MVP | Готовность платить за результат вручную | 1-3 недели |
Я обычно смотрю на это как на лестницу доказательств. Пока вы не получили сигнал на уровне оффера, идти в разработку рано. Пока не увидели реальное использование, рано строить сложную архитектуру и нанимать команду под длинный цикл.
Когда уже можно идти в разработку
У нас есть простой допуск, которым я пользуюсь сам. Он скучный, но хорошо экономит деньги.
- проведено 15-20 интервью с одним сегментом, а не со всеми подряд
- повторяются хотя бы 2-3 боли, за которые люди цепляются без подсказок
- есть тест оффера с понятной конверсией
- пришло 5-10 целевых заявок или договоренностей на демо
- первая версия сведена к одному главному сценарию, все остальное отправлено в стоп-лист
Когда этого набора нет, команда обычно покупает себе не продукт, а надежду в форме спринтов, макетов и оценок. Выглядит солидно, но не дает ответа на вопрос, нужен ли рынок.
Прежде чем заказывать MVP за пару миллионов, проверьте одну вещь: клиент готов расстаться хотя бы с временем, вниманием или деньгами ради вашей идеи? Если нет, вы строите не компанию, а дорогой способ не задавать себе неприятный вопрос.
