Вайбкодинг для фаундера: MVP без команды и без тупика

Вайбкодинг для фаундера без технической команды — это способ проверить идею до того, как тратить деньги на разработку. Раньше между «придумал» и «показал людям» стояли месяцы и подрядчик. Теперь — выходные и браузер. Риск в другом: легко принять быстрый прототип за продукт и застрять в нём на полгода.

Ниже — как построить MVP самому так, чтобы он сделал свою работу, и как понять, когда пора передавать его людям, которые читают код.

Зачем фаундеру MVP

MVP нужен не для того, чтобы запустить продукт, а чтобы ответить на один вопрос: будут ли люди этим пользоваться и платить. Всё, что не помогает на него ответить, — лишнее.

Отсюда первое правило: прежде чем открывать Lovable или Bolt, запиши, что именно ты проверяешь. «Владельцы салонов будут вести запись через наше приложение вместо тетрадки» — это гипотеза. «Сделать приложение для салонов» — нет. Гипотеза подскажет, какие экраны нужны, а какие подождут.

Что делать самому

Вайбкодинг отлично справляется с тем, что нужно для проверки идеи:

Интерфейс и основной сценарий. Один путь пользователя от входа до результата, ради которого он пришёл.
Простые данные. Пара таблиц: пользователи и то главное, с чем они работают.
Вход через готовый сервис. Не изобретай свою авторизацию, используй ту, что предлагает платформа.
Лендинг и форма заявки. Чтобы было куда вести первых людей.
Ручные процессы за кнопкой. Если что-то сложно автоматизировать, пусть кнопка отправляет письмо тебе, а ты сделаешь руками. Первым двадцати клиентам всё равно.

Держи в голове простое ограничение: одна роль пользователя, один основной сценарий, минимум интеграций. Каждая роль и каждая внешняя система множат сложность, а с ней и вероятность застрять.

Чего не делать в одиночку

Есть вещи, где ошибка стоит дороже, чем сэкономленное время:

Свои платежи и подписки. Используй готовые страницы оплаты платёжной системы, а не собирай форму с картой сам. Логику подписок с пробным периодом, возвратами и сменой тарифа ИИ почти всегда делает с дырами.
Чувствительные данные. Медицина, финансы, документы, данные детей. Здесь ошибка в доступе — это не баг, а юридическая проблема.
Несколько ролей с разными правами. Клиент, мастер, администратор салона, администратор платформы — каждая пара ролей это место, где кто-то увидит чужое.
Интеграции с деньгами и складом. Всё, где расхождение данных означает потерянные деньги.

Если без этого MVP не проверяет гипотезу — делай, но сразу закладывай, что эту часть посмотрит инженер до запуска.

Как не застрять

Застревают обычно не на первой версии, а на десятой. Несколько привычек, которые помогают:

Код в GitHub с первого дня. Даже если ты его не читаешь. Это история изменений, возможность откатиться и то, что ты отдашь инженеру.
Маленькие шаги. Одна просьба — одно изменение, которое можно проверить руками.
Записывай решения. Короткий файл: на чём сделан проект, какие сервисы подключены, где лежат ключи. Через три месяца ты не вспомнишь.
Отдельные тестовые и боевые настройки. Хотя бы разные ключи оплаты.
Не добавляй фичи, пока не проверил гипотезу. Каждая новая функция делает следующую правку дороже.

Когда звать инженеров

Не «когда будут деньги» и не «когда сломается». Хорошие моменты такие:

Перед запуском на реальных пользователях, особенно если берёшь деньги или хранишь личные данные. Хватит проверки на несколько дней.
Когда гипотеза подтвердилась. Люди пользуются, просят ещё. Теперь код должен выдерживать рост, а не просто работать.
Когда упёрся в стену. Правки ломают соседнее, ошибки возвращаются, ты боишься трогать часть приложения.
Перед разговором с инвестором. Техническую проверку лучше пройти самому, чем узнать о проблемах на чужой.

Инженеры при этом не обязательно всё перепишут. Чаще задача — закрыть дыры, навести порядок в ключевых местах и оставить тебе основу, на которой можно продолжать вайбкодить без страха.

Коротко

Вайбкодинг для фаундера — способ проверить гипотезу за дни, а не построить продукт навсегда.
Сам делай интерфейс, основной сценарий, простые данные и лендинг; сложное заменяй ручной работой.
Платежи, чувствительные данные, сложные роли и денежные интеграции не стоит делать в одиночку.
Код в GitHub, маленькие шаги и записанные решения — то, что не даст застрять.
Инженеров стоит звать перед запуском на реальных людях и когда гипотеза подтвердилась.

Если твой MVP подходит к этой точке, SUBXCAT поможет проверить его и подготовить к первым настоящим пользователям.