MVP на моках ≠ продукт: три разных «готово» (лендинг, прототип, прод)
Две недели вайб-кода, демо для клиента — и нет ни CSV, ни ролей. Разбираем три уровня готовности и шесть вопросов на ретро, чтобы не повторять чужой срыв.
Меня зовут Andrey, я веду дайджест про vibe coding и AI-кодинг в AI Vibe News. За Q1–Q2 2026 у меня в разборах прошло минимум три истории с одним сюжетом: две недели быстрого кода, демо для первого платящего клиента - а в демо нет ни экспорта в CSV, ни ролей доступа. B2B-сценарий не закрывается, срок «MVP» сорван на десять дней. История не про выбор IDE. Она про то, что «готово» на витрине и «готово» к последствиям - разные вещи.
Ниже - три уровня артефакта, три эпизода из моей практики разборов (B2B SaaS, внутренний RAG по Confluence, общий репозиторий витрины и приложения) и вопросы, по которым команда может честно отметить, где она сейчас. Имена клиентов скрыты по NDA.
§ Зачем разделять лендинг, прототип и продукт
Лендинг отвечает на вопрос: понятно ли, что мы предлагаем и кому. Критерии — ясность ценности, доверие к формулировкам, конверсия, скорость страницы. Он может жить на моках и обещаниях roadmap, потому что не выполняет опасных действий от имени пользователя.
Прототип отвечает: работает ли гипотеза в узком контуре. Задача — снять неопределённость интерфейса, потока данных или поведения агента в контролируемой среде. Пиковую нагрузку и полное покрытие тестами он может не переживать.
Продукт отвечает: можем ли мы нести ответственность, когда что-то пойдёт не так. Здесь появляются роли, данные, аудит, наблюдаемость и договорённости об уровне сервиса. Без этого вы остаётесь в зоне демо, даже если код уже в продакшене.
Путаница возникает, когда одно слово — например MVP — используется для всех трёх уровней сразу. Тогда планирование и приёмка говорят на разных языках.
Сводка «три контракта» (можно вставить в описание задачи в Jira или в начало брифа):
Лендинг. Главный вопрос: понятно ли обещание? Типичный артефакт: страницы, тизер, презентация. Статус в трекере: marketing / content. Когда хватает: перед кампанией.
Прототип. Главный вопрос: снята ли ключевая неопределённость? Типичный артефакт: ветка в репо, демо-стенд, скрипт. Статус: spike / experiment. Когда хватает: перед решением, строим ли дальше.
Продукт. Главный вопрос: кто отвечает за сбой и данные? Типичный артефакт: сервис с ролями, бэкапами, мониторингом. Статус: production с владельцем on-call. Когда нужен: перед деньгами и регуляторикой.
Если в тикете написано production, а по факту сделан только лендинг, конфликт неизбежен.
§ Лендинг: обещание, а не нагрузка
Лендинг готов, когда читатель получает правдивую картину: что уже в руках у пользователя, что в бете, что только в планах. Витрина с кабинетом «как будет» на моках — нормально для маркетинга, если это явно помечено. Проблема — когда продажи или клиент воспринимают экран как рабочий контур с данными и правами.
Первый эпизод я разбирал в январе 2026 (B2B SaaS): витрина и демо выглядели как продукт, не было ни экспорта, ни ролей. Срыв демо на десять дней — цена за отсутствие общего определения «готово».
Фиксируйте формулировки вроде «демо-данные», «ожидается в релизе N», «не входит в текущую версию». Для продукта те же фразы должны стать пунктами бэклога с владельцем и критерием приёмки.
§ Прототип: учиться, а не отчитываться перед аудитором
Второй эпизод мы смотрели в марте 2026 (внутренний инструмент на стороне клиента): RAG по Confluence, агент отвечал на вопросы, демо впечатляло. Для compliance нужно было показать, почему модель выдала ответ и какие шаги сделала цепочка инструментов. Аудит-лог был пуст: ноль записей. Прототип проверил «удобно ли читать базу», но не «можно ли подписать под регуляторику».
Прототипу достаточно одной-двух гипотез. Полная ролевая модель и SLO не обязательны, если честно называете это прототипом. Проблема — когда тот же артефакт выдают за продукт без наблюдаемости и воспроизводимости.
В книге Google SRE мониторинг определяют как сбор, обработку и отображение количественных данных о системе в реальном времени; оповещение — как сигнал, что что-то сломано или вот-вот сломается и это нужно чинить. Для прототипа можно жить с минимальным «белым ящиком»; перед compliance или платежом без лога это уже блокер, а не техдолг.
§ Продукт: последствия
Третий эпизод — апрельская история, которую я разбирал уже по горячим следам: витрина и приложение в одном репозитории с общими зависимостями. Маркетинг менял тексты и ломал сборку приложения; за спринт — четыре инцидента. Симптом: нет границы между обещанием и исполнением.
Продуктовый минимум — не максимум фич, а минимум, который вы готовы сопровождать: кто дежурит, какие метрики смотреть, как откатываться. OWASP ASVS — стандарт верификации безопасности веб-приложений: требования для разработки и основа для проверки технических контролей. Это не чеклист на лендинг, а ориентир, когда приложение обрабатывает чужие данные и права.
Называя артефакт продуктом, вы смешиваете анализ трендов, оповещения о поломках и отладку по истории — без сигналов и владельца «прод» становится чёрным ящиком.
Договоритесь о словаре: слова «релиз», «прод», «кабинет клиента» у маркетинга, разработки и продаж часто значат разное. Ярлыки вроде «витрина v1», «пилот для сегмента X», «контур с SLO Y%» экономят недели.
Мост из прототипа в продукт обычно из трёх пачек работ: учётные записи и права, контур наблюдаемости (что логируем, куда смотрит дежурный), сценарии отката релиза. ASVS даёт язык для контролей безопасности в веб-приложении — внешний якорь для чеклиста, не замена продуктовой спеки.
§ Шесть вопросов перед тем как снова сказать «готово»
Задайте на ретро; если на вопрос нет ответа, вы, скорее всего, на уровень ниже, чем думаете.
1. Можем ли показать тот же сценарий платящему клиенту без ручной подгрузки данных разработчиком? 2. Есть ли роли и разграничение доступа под реальный B2B или внутреннего тенанта? 3. Фиксируется ли цепочка решений агента или критичных операций в логе для аудитора? 4. Может ли правка маркетинговой страницы сломать сборку или деплой приложения? Если да — где граница модулей? 5. Какие три метрики говорят, что сервис живой, и кто реагирует на деградацию вне рабочего дня? 6. Какие формулировки на лендинге мы готовы подписать как правдивые сегодня?
§ Как использовать в спринте
На планировании — одна минута на задачу: назвать уровень из таблицы и следующий порог. Задача как продукт, но в описании только UI без модели прав — либо переименовать в прототип, либо добавить подзадачи на доступ и данные. Для лендинга заранее согласовать с продажами, что можно обещать устно на демо и что должно быть в тексте на сайте.
§ Заключение
Лендинг продаёт ясность обещания. Прототип снимает риск «не узнаем без кода». Продукт подписывает под последствия. Вайб-кодинг ускоряет второй и частично первый уровень, но не отменяет третий: безопасность, данные и эксплуатацию проектируют отдельно — иначе повторятся срывы демо, пустой audit log и серия инцидентов из-за связки витрины и приложения.
Честная подпись уровня — витрина, эксперимент, эксплуатация — дешевле несостыковки ожиданий между командами и клиентом.
§ Источники
§ Если интересны такие разборы
Мы в AI Vibe News каждый день отбираем материалы по vibe coding с десятков источников и публикуем выжимку на русском — без лишнего шума.
Я веду MAX-канал AI Vibe News — короткие выжимки по vibe coding и AI-кодингу каждый день.
Архив и остальные материал
Вопросы по чеклисту и применению в команде — пишите в комменты, разберу на примерах.