Как сделать MVP за выходные — не написав ни строчки кода

Если ты когда-нибудь гуглил «как сделать MVP за выходные», то знаешь это ощущение: идея горит, руки чешутся, а в понедельник уже на работу. Два дня — это и не так много, и не так мало. За них реально дойти от «а прикольно бы» до ссылки, которую кидаешь друзьям в чат со словами «зашло бы?». Но только если не пытаться построить всё сразу.

Я не обещаю продукт мечты за выходные. Обещаю другое: к вечеру воскресенья у тебя будет что-то живое, что открывается в браузере, делает одну понятную штуку и позволяет получить первую честную реакцию от реальных людей. Дальше — по обстоятельствам. Ниже — как я сам это делаю, где стелю соломку и почему «не написав ни строчки кода» перестало быть маркетинговым лозунгом.

Что вообще считать «MVP за выходные»

Слово MVP затаскали до дыр. Для выходного забега держи в голове максимально скромное определение: минимальная версия, которая делает ОДНУ вещь, и её можно потрогать. Не «платформа», не «экосистема», не «маркетплейс». Одно действие, один экран, один сценарий.

Хороший тест на масштаб: если не можешь описать продукт одним предложением без слова «и» — ты замахнулся слишком широко. «Сервис, который превращает голосовую заметку в структурированный список задач» — норм. «Сервис для заметок, и таск-менеджер, и календарь, и шаринг» — это уже не выходные, это квартал.

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

План на два дня: суббота и воскресенье

Разобьём выходные по-крупному. Суббота — про то, чтобы вообще что-то заработало. Воскресенье — про то, чтобы это увидели люди. Не наоборот: очень легко весь второй день полировать кнопки и так никому продукт и не показать.

Времена ниже — грубый ориентир, порядок величин, а не расписание по минутам. У кого-то суббота уйдёт за пять часов, у кого-то за десять — зависит от сложности идеи и от того, сколько раз ты передумаешь по ходу.

Заметь: во второй половине воскресенья ты уже не строишь, а слушаешь. Это самая ценная часть выходных, и её почти все проматывают.

Что включить в MVP, а что безжалостно отложить

Главный навык выходного забега — резать. Не «что бы ещё добавить», а «без чего точно нельзя». Вот моя рабочая линия отреза.

Логика простая: всё, что не участвует в проверке гипотезы, — отложить. Пользователю на выходной версии не нужен профиль, ему нужно один раз пройти твой сценарий и понять, полезно ему это или нет. Регистрацию, оплату и админку добавляют, когда стало ясно, что продукт вообще кому-то нужен, — а не до.

Отдельно про деньги. Соблазн сразу прикрутить приём платежей огромен, но на выходных это ловушка. Если кто-то реально хочет заплатить — прими перевод вручную и обними этого человека, это лучший сигнал в мире. Настоящую экономику продукта — сколько ты тратишь и сколько зарабатываешь — считать имеет смысл, когда есть хотя бы горстка пользователей; про это отдельно в деньгах проекта простым языком.

«Не написав ни строчки кода» — как это работает на практике

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

На практике выходной цикл выглядит так:

• Ты пишешь задачу человеческим языком: «сделай экран, куда можно вставить текст, и по кнопке он превращается в список пунктов».
• AI-воркер берёт задачу и доводит её до готового — не подсказку выдаёт, а делает.
• Ты смотришь результат, говоришь «вот тут не так» — и следующей задачей правишь.

Это ближе к делегированию, чем к программированию. Ты — тот, кто решает что и зачем; исполнение уходит воркерам. И тут важна встроенная подписка на модель: не нужно доставать свои API-ключи, поднимать VPN и разбираться с чужим биллингом — это отдельный день возни, которого на выходных просто нет. Про то, зачем модель живёт прямо внутри платформы, — в Claude внутри платформы.

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

Типичные ошибки выходного забега

Я собрал их не из «исследований», а из собственных граблей и наблюдений за другими инди-мейкерами. Они повторяются с удивительной регулярностью.

• Строить фундамент на десять этажей под одноэтажный дом. Аутентификация, роли, база «на вырост» — в субботу, когда ещё неясно, нужен ли дом вообще. Отложи. Захардкодь. Проверь гипотезу.
• Полировать то, что никто не увидит. Идеальные отступы на экране настроек, до которого пользователь не дойдёт. Красота важна, но в порядке приоритета — после «работает» и «понятно».
• Не показать продукт до понедельника. Классика. «Ещё чуть-чуть допилю и покажу» — и выходные кончились, а фидбека ноль. Публикуй в состоянии, за которое чуть стыдно. Именно чуть.
• Спросить друзей „нравится?“ вместо „ты бы этим пользовался?“. Друзья добрые, они скажут «класс». Это бесполезно. Нужны вопросы, на которые нельзя ответить из вежливости.
• Добавлять фичи в ответ на первую же жалобу. Один человек сказал «а вот бы ещё…» — и ты бежишь делать. Собери 5 реакций, найди общее, потом решай.
• Считать запуск концом. Ссылка — это не финиш, а старт наблюдения. Дальше самое интересное.

Из всех этих грабель самая дорогая — третья. Непоказанный продукт нельзя проверить, а непроверенный продукт — это просто красиво оформленная догадка.

Как проверить на живых людях (а не на своём эго)

Ссылка есть. Теперь нужны люди и правильные вопросы. Пять-десять человек — этого на выходных достаточно, чтобы увидеть паттерны. Не гонись за сотнями: на старте важнее глубина одной реакции, чем ширина охвата.

Где взять первых людей за час:

• Личные чаты и один-два тематических сообщества, где ты уже свой (не спамь незнакомым).
• Знакомые, у которых есть та самая проблема, которую ты решаешь, — они дадут самый честный ответ.
• Если совсем тихо — просто сядь рядом с одним человеком и попроси пройти сценарий вслух. Одна такая сессия стоит десяти «ну норм» в переписке.

Что спрашивать — и, что важнее, чего НЕ спрашивать:

Самое ценное наблюдение — не слова, а места, где человек замирает, щурится или спрашивает «а куда тут нажать». Это и есть твой список задач на следующие выходные. Кстати, то, как человек проходит продукт в первый раз, — отдельная большая тема; если дойдёт до потока новых пользователей, глянь онбординг первых пользователей.

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

Что делать в понедельник утром

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

• Выпиши три главные проблемы из фидбека и почини их первыми — до всяких новых идей.
• Отметь, какая одна фича встречалась в запросах чаще всего. Не делай сразу — просто пометь.
• Реши честно: гипотеза жива или нет. Если люди пожали плечами — это тоже результат, и хороший: ты потратил выходные, а не квартал.

Право сказать «не пошло» и заняться следующей идеей — недооценённая суперсила инди-мейкера. Дешёвый эксперимент затем и нужен, чтобы дёшево ошибаться.

Короткий вывод

MVP за выходные — это не про скорость печати и не про магию. Это про дисциплину резать лишнее и смелость показать сырое. Суббота — чтобы заработало, воскресенье — чтобы увидели люди, понедельник — чтобы решить, стоит ли продолжать.

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