Від ідеї до робочого MVP за вихідні: мій процес вайбкодингу для підприємця

Я зробив це достатньо разів, щоб перестати романтизувати. «MVP за вихідні» звучить як гасло з конференції, але за ним є цілком приземлений, повторюваний процес. Я будую продукти з AI сам — для Dronehub, для Oswin AI, для власних внутрішніх інструментів — і навчаю цьому підприємців через VADYM.AI і KIERUNEK.AI. Тож нижче — не мотивація, а плейбук. Що ти реально встигнеш за два дні, що ні, де зриваються 90% спроб і як виглядає мій чек-лист на суботу й неділю.

Одразу домовимося про головне. «Робочий MVP за вихідні» — це не маленька версія складного продукту. Це повна версія дуже маленького продукту. Різниця між цими двома фразами і є вся ця стаття.

Крок 0: чесно про межі вихідних

Перш ніж щось будувати, треба знати, у що ти граєш. Карпати, який і ввів термін «вайбкодинг» у лютому 2025-го, чесно описав його як режим саме для «викидних проєктів на вихідні» — швидких, безтурботних, де ти не вичитуєш кожен рядок коду. Це ідеальний опис того, що ми робимо в суботу-неділю, і водночас попередження.

Ось чесний кордон, який я тримаю в голові:

Якщо тримати цей кордон, вихідні закінчуються робочим продуктом. Якщо його ігнорувати — закінчуються наполовину зібраною системою, якої соромно і яку шкода викинути.

Крок 1: звузити ідею до одного болю (субота, ранок)

Найдорожча помилка трапляється ще до першого рядка коду — на рівні формулювання. Підприємець приходить з ідеєю масштабу «платформа для X». За вихідні платформу не зробиш, тож або ти звужуєш сам, або реальність звузить за тебе, але вже о другій ночі неділі й боляче.

Моє правило: поки ти не можеш сформулювати біль одним реченням про одну людину, будувати рано. Не «застосунок для ресторанів», а «офіціант за десять секунд бачить, яких страв сьогодні немає в наявності». Не «CRM для коучів», а «коуч одним натиском надсилає клієнту нагадування про завтрашню сесію».

Я ставлю собі три питання й вимагаю одне-реченнєвих відповідей:

• Хто конкретна людина? (не «бізнеси», а «Марія, адміністратор салону»)
• Який один момент у її дні зараз болить? (не «неефективність», а «вона вручну переписує записи з трьох месенджерів у зошит»)
• Як виглядає полегшення? (не «оптимізація», а «усі записи в одному списку, який оновлюється сам»)

Якщо на ці три питання немає коротких відповідей — це не задача для вихідних, це задача для ще одного дня роздумів. Пів години тут економлять півдня плутанини потім. Я ніколи про цю пів години не шкодував.

Крок 2: визначити найменший корисний зріз (субота, ранок)

Тепер з одного болю треба вирізати найменший зріз, який уже дає користь. Англійською це називають MVP — minimum viable product, — і ключове слово тут не «minimum», а «viable»: життєздатний. Зріз має бути не просто малим, а самодостатнім — щоб людина пройшла його до кінця й отримала обіцяну вигоду.

Я роблю це через один прийом: описую єдиний головний сценарій одним абзацом, від першої дії користувача до моменту, коли він отримав користь. Для прикладу з офіціантом це звучить так: «Менеджер зранку відкриває застосунок, відмічає галочками страви, яких сьогодні нема, натискає "Зберегти" — і будь-який офіціант зі свого телефона бачить актуальний список стоп-листа».

Усе, що не входить у цей один абзац, на вихідних не існує. Реєстрація через Google? Нема, один спільний доступ. Історія змін? Нема. Аналітика? Нема. Налаштування профілю? Нема. Кожне «а ще було б добре» — це година, якої в тебе немає. Дисципліна різання тут важливіша за будь-яку технологію.

Маленький тест на життєздатність зрізу: уяви, що показуєш результат тій самій Марії, і вона каже «о, це я б використовувала вже завтра». Якщо твій зріз такої реакції не викликає — він замалий або не про те. Ріж далі, але в правильному місці.

Крок 3: накидати екрани й потік (субота, день)

Перш ніж відкривати будь-який інструмент, я малюю. Буквально — на папері або в нотатках — послідовність екранів того одного сценарію. Зазвичай їх виходить два-три: екран вводу, екран результату, інколи екран підтвердження. Якщо екранів більше п'яти — я повертаюся на крок 2, бо щось не дорізав.

Цей ескіз — і є моє технічне завдання для AI. Чим конкретніше я опишу екрани й переходи між ними, тим менше ітерацій згаю. «Зроби застосунок для ресторану» дає кашу. «Екран зі списком страв, біля кожної перемикач "є / нема", кнопка "Зберегти" внизу; після збереження — екран з тими стравами, що позначені як "нема", великим шрифтом» — дає те, що я уявляв.

Намір — це новий вихідний код. Я витрачаю двадцять хвилин на чіткий опис потоку саме тому, що ці двадцять хвилин потім економлять годину переробок.

Крок 4: зібрати з AI ітераціями (субота, день — вечір)

Аж тепер відкриваємо інструмент. У 2026-му стек вайбкодингу поділився на чотири доріжки, і вибір залежить від тебе, а не від моди:

• AI-редактори (Cursor, Windsurf) — для тих, кому комфортно бачити й чіпати код.
• Термінальні агенти (Claude Code) — для довших багатофайлових задач, коли модель сама ходить по проєкту.
• Браузерні білдери (Lovable, Bolt, Replit, v0) — «з підказки в задеплоєний застосунок», найнижчий бар'єр входу для нетехнічного засновника.

Популярний у 2026-му підхід — гібрид: прототипуєш у браузерному білдері, а коли продукт починає мати значення, переходиш у редактор коду. Для вихідних я раджу почати там, де тобі найменше тертя. Нетехнічному підприємцю — браузерний білдер, бо він дає працюючий екран за хвилини. Одна важлива деталь: білдери на кшталт Lovable і Bolt експортують переносний код, який можна задеплоїти будь-де, тоді як платформи з усім «під ключем» прив'язують базу, авторизацію й хостинг до себе — і пізніша міграція означає переписувати інфраструктуру з нуля. Якщо є шанс, що проєкт виживе, я обираю інструмент, з якого можна забрати код.

Сам процес збірки — це цикл, а не один великий запит:

1. Дай AI весь сценарій і опис екранів одним повідомленням.
2. Подивись, що вийшло, у застосунку, не в коді.
3. Назви одну конкретну проблему («кнопка не зберігає», «список порожній після оновлення») і кинь її назад.
4. Повтори.

Дрібний прийом, який економить найбільше часу: проси одну зміну за раз. Велике повідомлення на десять правок дає десять нових місць, де щось могло зламатися, і ти не знаєш, яке саме. Маленькі кроки — швидші, хай це й здається повільнішим.

Крок 5: дані й одна-дві інтеграції (субота, вечір)

Двоє найбільших пожирачів часу на вихідних — це дані та інтеграції. До них треба підходити з тією самою жадібністю різання.

Дані. Бери найпростіше сховище, яке працює. На вихідних мета — щоб дані не зникали між сесіями, а не щоб архітектура пережила мільйон користувачів. Більшість браузерних білдерів дають вбудовану базу одним кліком — цього досить. Складні моделі даних, зв'язки між десятьма сутностями, оптимізація запитів — це не задача суботнього вечора.

Інтеграції. Тут правило жорстке: одна, максимум дві. Кожна зовнішня інтеграція — це окремий світ ключів авторизації, форматів, помилок і крайніх випадків. Я обираю ту єдину інтеграцію, без якої продукт безглуздий — надіслати повідомлення в Telegram, прийняти один платіж, записати рядок у таблицю, — і роблю тільки її. Решту, якщо без них узагалі ніяк, імітую вручну: замість автоматичної розсилки — кнопка, яка показує текст, що його я скопіюю сам. Заглушка, яку видно живій людині, на тесті працює не гірше за справжню інтеграцію, а коштує в десять разів менше часу.

Якщо інтеграція починає опиратися дві години — це сигнал зупинитися й спитати себе, чи вона взагалі потрібна для тесту. Найчастіше — ні.

Крок 6: тест на реальному користувачі (неділя)

Неділя — не про код. Неділя про те, щоб посадити перед застосунком живу людину, яка не ти. Це найважливіший і найчастіше пропущений крок. Власноруч зібраний продукт завжди працює в руках автора — ти підсвідомо обходиш його слабкі місця. Сенс має лише чужий палець на чужому екрані.

Я даю людині одне завдання — пройти головний сценарій — і мовчу. Не підказую, не пояснюю, не виправдовуюся. Просто дивлюся, де вона зупиняється, що тисне не туди, де каже «а що тепер?». Кожна така затримка — це баг дизайну, навіть якщо код ідеальний.

Ось тут і народжується відповідь на питання, яке всіх мучить: коли MVP достатньо добрий? Мій критерій простий — коли стороння людина проходить головний сценарій від початку до кінця й отримує обіцяну користь без моїх підказок збоку. Не «коли гарно», не «коли немає жодного бага», а «коли він робить свою одну справу в чужих руках». Усе інше — наступні ітерації, не вихідні.

Якщо людина застрягла — я повертаюся в інструмент і правлю саме те місце, де вона застрягла. Один прохід тесту зазвичай дає три-чотири дрібні правки, кожна на десять хвилин. Це і є вся неділя.

Крок 7: що далі — і де чесна межа

Наприкінці вихідних у тебе є робоча штука, яка вирішує один біль однієї людини. Це перемога. Але тут вмикається найважливіша чесність, без якої вся ця методологія перетворюється на самообман.

Завайбкоджений за вихідні MVP — це прототип і внутрішній інструмент, а не продакшн-продукт. Межу ще в 2025-му точно окреслив Саймон Віллісон: якщо ти не прочитав і не перевірив згенерований код, покладатися на нього в проді не можна. Між «я завайбкодив за вихідні» і «це надійно тримає чужі дані й гроші» лежить окрема, неромантична робота: прочитати код, протестувати крайні випадки, закрити вразливості, налаштувати обробку помилок. Я завжди роблю цей крок свідомо — а не вдаю, що його немає.

Тому «що далі» залежить від результату тесту:

• Людина не зачепилася — чудово, ти за два дні й сто гривень дізнався, що ідея не та. Це найдешевший провал у твоєму житті. Викидай без жалю.
• Людина зачепилася — тепер є сенс інвестувати в перетворення прототипу на надійний продукт: прочитати код, додати ще кілька людей, поступово закрити те, що ти свідомо вирізав на вихідних.

Сила цього процесу не в тому, що ти за вихідні робиш бізнес. Сила в тому, що за вихідні й мізерні гроші ти отримуєш відповідь — чи варто будувати далі. Більшість ідей цю перевірку не проходять, і це найкорисніше, що з ними може статися.

Чек-лист вихідних

Щоб не тримати все в голові, ось мій згорнутий план на два дні.

Це не магія і не геройство. Це дисципліна різання, помножена на швидкість, яку AI нарешті дав підприємцю без команди розробників. Найважчим лишається не код — код тепер дешевий. Найважче — мати чесність звузити велику ідею до однієї маленької, яку реально перевірити за два дні. Хто опанує це звуження, той за кожні вихідні буде отримувати відповідь, на яку раніше йшли місяці й бюджети.