Пришел к нам проект с формулировкой: «нужен MVP маркетплейса». За 40 минут разговора стало ясно, что маркетплейс им пока вообще не нужен. Проверять надо было одну вещь: готовы ли 20 поставщиков платить за поток целевых заявок.
Вместо оценки на 8 месяцев мы собрали закрытый пилот за 5 недель. Без витрины, без личных кабинетов на все случаи жизни, без красивой ролевой модели. Короче, полезный MVP чаще всего выглядит как самый короткий путь к первой оплате, а не как маленькая копия будущей платформы.
MVP нужен, чтобы проверить спрос
Самая частая ошибка простая: команда берет будущий продукт, отрезает от него кусок и называет это MVP. Я такое видел много раз в B2B-проектах: тащат роли, аналитику, настройки, мобильное приложение, хотя вопрос на старте один - клиент вообще готов за это платить или нет.
Вот смотри, граница тут довольно понятная:
| Формат | Что проверяет | Сигнал |
|---|---|---|
| Прототип | Понимание сценария | Комментарии, интервью |
| MVP | Спрос на ценность | Оплата, пилот, LOI (письмо о намерениях) |
| Продукт | Повторяемость бизнеса | Удержание, экономика |
У нас был сервис для логистики. Клиент хотел 14 ролей, мобильное приложение для водителей и аналитику. Мы собрали только кабинет диспетчера на Laravel 11 + PostgreSQL 16, автопостроение маршрута и экспорт в Excel. Запуск занял 8 недель вместо 7 месяцев, а до полной платформы дошли уже с 3 платными клиентами.
MVP ограничен специально и вокруг одной гипотезы.
Чем MVP отличается от сырого релиза?
У сырого релиза ограничения случайные: тут не доделали, там не успели. У MVP они осознанные - команда заранее понимает, какую гипотезу проверяет и какое действие считает сигналом.
Формат проверки выбирают по главному риску
Если риск в том, что люди не понимают оффер, код вообще не первый инструмент. Если риск в данных, интеграциях или реальной логике процесса, без разработки уже никуда. Мы обычно от этого и пляшем.
- Figma - когда надо проверить сценарий и порядок шагов
- Webflow или Framer - когда тестируем спрос на обещание
- Bubble, Glide, FlutterFlow - когда нужен быстрый пилот с формами и кабинетами
- Next.js + Supabase или Firebase - когда гипотеза держится на логике, оплате и данных клиента
Хороший пример - HR-проект, который собирался строить AI-платформу под найм. Вместо этого мы сделали ручной MVP: вакансии собирал менеджер, скоринг делали вручную, клиент получал PDF за 24 часа. За 1 месяц команда получила 9 тестовых продаж и только потом стало понятно, что автоматизировать первым.
Был и обратный случай, где мы сами сначала пошли не туда. Попробовали уместить B2B-процесс согласований в no-code, потому что хотелось быстрее. Через 3 недели стало ясно, что права доступа и история изменений там ломают саму проверку. Перешли на Node.js 20 + NestJS и PostgreSQL 16, и проект поехал быстрее, хотя на старте казалось, что это дороже.
В первом релизе нужны три слоя
Когда начинаешь раскладывать продукт по полкам, обычно остается не так много. Я бы собрал первый релиз из трех слоев:
- ядро ценности - что человек получает на выходе
- минимальный сценарий - как он доходит до результата
- способ сделки - оплата, заявка на пилот или LOI
У SaaS для салонов изначально были CRM, склад, финансы и аналитика. После декомпозиции остались онлайн-запись, напоминания и календарь администратора. Первые 20 платящих точек подключились вообще без отчетов - владельцу было важнее, что запись перестала теряться.
Тут нагляднее всего работает формат «до/после»:
- До - 27 экранов, 4 роли, оценка 5 месяцев
- После - 6 экранов, один сценарий, первый пилот через 4 недели
- Результат - команда раньше поняла, за что клиент готов платить
Отдельно почти всегда стоит отложить платформенность. Пока нет узкого кейса, она превращается в дорогую догадку.
Иногда руками проверить лучше, чем автоматизировать
Самая дорогая ошибка на старте - автоматизировать то, что сначала надо было просто сделать вручную. Для B2B ручная доставка ценности часто дает сигнал сильнее любой регистрации.
У нас был сервис документооборота. Лендинг собрал 120 регистраций, команда решила, что спрос есть, и пошла строить полуплатформу. В продукт дошли только 2 компании - идея людям нравилась, но менять процесс они не спешили.
Потом мы пересобрали предложение вокруг одного кейса: согласование договора за 1 день вместо 5 дней. Убрали общие разговоры, сделали узкий пилот на реальных документах клиента. Конверсия из демо во внедрение выросла с 6% до 22%.
Если люди хвалят идею, это уже сигнал?
Нет. Идею часто хвалят из вежливости или потому, что она звучит разумно. Сигнал появляется, когда дают деньги, данные, время команды или подписывают пилот.
В 2026 собирать быстрее, думать все равно самому
Сейчас MVP запускать правда проще. Для проверки гипотезы можно за 4-6 недель собрать рабочий пилот на готовом стеке, не строя свою «большую систему». Но скорость сборки не лечит слабую гипотезу.
Для замеров у нас обычно очень земной набор: PostHog или Mixpanel для событий, Hotjar или Clarity для записи сессий, Airtable или Notion для учета пилотов и обратной связи. Этого хватает, чтобы понять, где человек застрял, дошел ли до первой ценности и готов ли платить повторно.
Перед стартом я бы задал себе пять вопросов: какую боль решаем, какой сигнал ждем, что можно сделать вручную, где появляются деньги, что сознательно откладываем до второго релиза. Если на один из этих вопросов нет жесткого ответа, код я бы пока не писал.
В том маркетплейсе из начала статьи в итоге так и не появилось ни каталога, ни корзины. И это было хорошее решение, потому что платить начали за лиды, а не за слово «маркетплейс» в презентации.
