MVP на вайб-кодинге: что можно показывать инвестору, а что придётся переписать
Дальше начинается интересное. Прототип показывают инвестору, инвестор говорит «а покажите нагрузку и безопасность», и выясняется, что показывать особо нечего.
Дальше начинается интересное. Прототип показывают инвестору, инвестор говорит «а покажите нагрузку и безопасность», и выясняется, что показывать особо нечего.
Речь не о том, что вайб-кодинг это плохо. Речь о том, что у него есть граница, и её лучше знать заранее, чем узнавать на due diligence.
Что вайб-кодинг делает хорошо
Проверку гипотезы. Это его настоящая работа, и здесь он не имеет конкурентов по скорости.
Лендинг с формой и оплатой, чтобы понять, платят ли вообще. Интерфейс, который можно показать десяти потенциальным пользователям и посмотреть, куда они тыкают. Внутренний инструмент для команды из трёх человек. Демонстрация механики продукта, где важна идея, а не устойчивость.
Во всех этих случаях код одноразовый по своей природе. Он должен дожить до ответа на вопрос, а дальше его судьба никого не волнует. Тратить на такое разработку по всем правилам действительно бессмысленно.
Основателю без технического бэкграунда вайб-кодинг дал то, чего раньше не было совсем: возможность проверить идею, не отдавая долю техническому сооснователю и не собирая раунд под непроверенную гипотезу.
Где проходит граница
Граница проходит там, где появляются чужие данные, деньги и нагрузка.
Отчёт Veracode за июль 2025 года, построенный на анализе более чем ста моделей, показал: 45% сгенерированных фрагментов кода не прошли тест безопасности и содержали уязвимости из списка OWASP Top 10. Это вендорское исследование, и относиться к нему нужно как к ориентиру, а не как к точной метрике. Но направление оно показывает ясно, и оно совпадает с тем, что видно на практике.
Работающий интерфейс и безопасное приложение это разные вещи. Модель оптимизирует результат под запрос «сделай, чтобы работало», а не под запрос «сделай, чтобы это нельзя было сломать». Пока пользователей десять, разница незаметна. Когда появляются регистрация, персональные данные и платежи, она становится единственным, что имеет значение.
Отдельно: персональные данные пользователей в прототипе это уже не прототип. Требования закона не делают скидку на стадию проекта.
Что инвестор действительно смотрит
Прототип на демонстрации почти никого не пугает. Пугает другое.
Первое: понимаете ли вы, что у вас в коде. Основатель, который говорит «там всё сгенерировано, я не знаю как», выглядит хуже, чем основатель, который говорит «прототип одноразовый, вот план переписывания и его стоимость».
Второе: сколько стоит довести это до продукта. Ответ «почти ничего, мы же быстро сделали» читается как отсутствие оценки.
Третье: что будет, когда придут первые тысяча пользователей. Не обязательно иметь готовое решение. Обязательно иметь понимание, где сломается.
Инвестор покупает не код. Он покупает способность команды превратить проверенную гипотезу в продукт, а прототип это доказательство того, что гипотеза проверена.
Что почти всегда переписывают
По опыту проектов, куда команда приходит после прототипа, список повторяется.
Авторизация и права доступа. В сгенерированном виде они обычно есть, но проверяются только на клиенте, то есть не проверяются вообще.
Работа с базой данных. Схема, собранная под демонстрацию, не переживает роста количества записей: запросы без индексов, дублирование сущностей, отсутствие миграций.
Обработка ошибок. В прототипе её нет, потому что сценарий демонстрации всегда успешный.
Интеграции с внешними сервисами. Ключи в открытом виде, отсутствие повторных попыток, никакой обработки отказов.
Развёртывание. Проект, который запускается только с ноутбука основателя, не является продуктом ни в каком смысле.
Что при этом обычно выживает: логика продукта, структура экранов, сценарии пользователя. То есть самое ценное. Прототип не выбрасывается, он становится подробным техническим заданием, написанным на языке работающего кода, и это честно экономит деньги на следующем этапе.
Как построить переход от прототипа к продукту
Разумная последовательность выглядит так.
- Зафиксировать, что именно проверено. Гипотеза подтвердилась или нет, какими цифрами.
- Отделить продуктовые решения от кода. Экраны, сценарии и логика переезжают, реализация нет.
- Провести аудит прототипа: что можно оставить, что переписать, где риски безопасности.
- Определить нагрузку на ближайший год. Тысяча пользователей и сто тысяч это разные архитектуры.
- Заложить время на данные и безопасность отдельной строкой, а не пунктом внутри разработки.
- Только после этого считать бюджет и сроки.
Пропуск третьего пункта стоит дороже всех остальных вместе: без аудита команда переписывает либо слишком много, либо слишком мало, и выясняется это уже в продакшене.
Кто это делает
Вариантов три. Нанять технического сооснователя, что решает вопрос надолго, но требует доли и времени на поиск. Собрать штатную команду, что имеет смысл при подтверждённом финансировании. Отдать этап аутсорс-разработки под ключ внешней команде, что чаще всего выбирают между раундами, когда продукт уже нужен, а постоянная команда ещё не окупается.
Ни один из вариантов не универсален, и выбор зависит от того, сколько у вас денег и сколько времени. Общее в них одно: разговор начинается с аудита прототипа, а не с оценки «сделайте нам то же самое, только нормально».
Итог
Вайб-кодинг закрыл этап, который раньше стоил стартапу первых денег: проверку гипотезы. Он не закрыл этап, на котором продукт становится продуктом.
Показывайте инвестору прототип и план его переписывания. Это выглядит сильнее, чем прототип, выданный за продукт, и намного сильнее, чем продукт, которого пока нет.