Більшість MVP промахуються повз дату запуску не тому, що розробник був повільний. Вони промахуються тому, що обсяг робіт так і не був зафіксований. Робота розширювалася так, як завжди розширюється розмита робота — по фічі за розмову, по інтеграції за зустріч, по «заодно зробимо» на тиждень.
Це процес опису MVP, який я використовую з клієнтами, щоб вийти за 12 тижнів або менше. Нічого особливого. Письмовий, нудний, робочий.
Єдине правило, від якого все залежить
Усе, що ви хочете в MVP, вміщується на одну сторінку тексту до того, як написаний перший рядок коду. Якщо не вміщується — у вас не MVP, а продукт.
Це не гарне формулювання. Це обмеження. Десять фіч вміщуються на сторінку. Пʼятнадцять — ні. Вправа зі скорочення до десяти і є тим місцем, де приймаються найважливіші рішення.
Односторінковий бриф — що в ньому
Пʼять розділів. Саме в такому порядку.
1. Одне речення.
«Платформа, де [хто] може [робити що] щоб [який результат отримати]».
Заповніть три пропуски — і решта брифу складеться сама собою. Не можете заповнити — продукт ще недостатньо ясний. Витратьте тиждень на це речення, перш ніж витрачати щось інше.
2. Три користувацьких сценарії. Не більше.
Оберіть три сценарії, без яких продукт марний. Усе інше — друга фаза.
Приклади з реальної платформи продажу квитків:
- Організатор створює подію і призначає ціни
- Покупець обирає місце, оплачує
- Організатор сканує квитки на вході
Три сценарії. Це MVP. Відновлення пароля, повернення, інвойсинг, права для кількох організаторів — усе важливе, усе в другу фазу.
3. Єдина метрика успіху.
Одне число. Не три. Не дашборд.
«Ми зрозуміємо, що вийшло, якщо в перші 90 днів будуть 50 платних заходів».
Цінність єдиної метрики не у вимірюванні — вона у прийнятті рішень по ходу розробки. Кожен компроміс («додати X?») вимірюється проти цього одного числа. Якщо X не рухає метрику — X не робимо.
4. Інтеграції, які мають працювати в день 1.
Stripe. Resend. Supabase. Sentry. Яким би не був ваш список.
Дисципліна тут: кожна інтеграція в списку коштує 3–8 днів реальної роботи, включно з граничними випадками, вебхуками та виробничими збоями, про які ніхто не попереджає (я писав про шість таких для Stripe). «Маленьких» інтеграцій не існує. Кожен рядок у списку інтеграцій рухає запуск на тиждень.
5. Дедлайн і причина.
«Запуск до 15 вересня, бо демо на конференції X». «Запуск до 1 жовтня, бо закривається раунд і ми хочемо показати траєкцію».
Причина важлива. Якщо в дедлайну немає причини — це побажання, а побажання зсуваються. Якщо причина справжня (конференція, раунд, сезон) — дедлайн справжній, і обсяг робіт уріжеться під нього.
Одна сторінка. Пишеться за вечір. Якщо потрібно два вечори — нормально, але не стартуйте розробку, поки її немає.
Скорочення обсягу, які боляче, але працюють
Засновники приходять із десятьма «обовʼязковими» фічами. Робота розробника — знайти ті пʼять, що важливі, і ввічливо вирізати решту. Якісь скорочення засновники потім шкодують, більшість — ні. Ось ті, що надійно не болять:
- Ролі і права більше 1–2 рівнів. Відвантажуйте з «власником» і «користувачем». Адмінів — у другу фазу.
- Гарні шаблони листів. Відвантажуйте plain-text транзакційні листи. Дизайн — у другу фазу.
- Сценарії онбордингу і туторіали. Відвантажуйте з 3-крочною реєстрацією. Підказки у стилі Intercom — коли зрозумієте, де люди спотикаються.
- Адмінські дашборди. Відвантажуйте з прямим доступом до бази для вас. Нормальну адмінку — у другу фазу.
- Аналітика понад ключову метрику. Базове налаштування PostHog — 20 хвилин. Кастомний дашборд аналітики — два тижні. Відвантажуйте базовий.
- Мобільний застосунок. Відвантажуйте адаптивний веб. Нативну оболонку — коли буде 1K користувачів, не раніше.
- Багатомовність. Якщо ринок не вимагає кількох мов (мої E7-проєкти тримовні, бо інакше не можна), відвантажуйте однією.
Скорочення, які засновники не хочуть приймати, але не варто сперечатися:
- Кастомна дизайн-система. Tailwind + shadcn/ui дають 80% полірування за 5% роботи. Дизайн-систему можна робити, коли ваш бренд уже бренд.
- Multi-tenancy понад те, що Stripe дає безкоштовно. Справжня multi-tenant архітектура — це 4 тижні інфраструктурної роботи. Більшості MVP це не потрібно.
Артефакти, які утримують обсяг після старту
Бриф є. Тепер: як не допустити, щоб він розповз на третьому тижні непомітно?
Артефакт 1: письмовий запит на зміну, по кожній зміні.
Будь-яка фіча не з початкового брифу йде через документ на 5 рядків: що, навіщо, яку віху замінює чи зсуває, нова ціна якщо є, підписано обома сторонами. Пʼять рядків. Не роман. Але письмово.
Більшість повзучості обсягу трапляється, коли засновник каже «а ще давайте…» на Zoom-дзвінку, а розробник киває. Нічого не підписано, нічого не оцінено, і до сьомого тижня «а ще» більше, ніж початковий MVP.
Артефакт 2: демо щопʼятниці. Не обговорюється.
Щопʼятниці є staging-посилання, яке можна відкрити. Поклацати, спробувати, знайти зламане, поговорити, що відвантажуємо наступного тижня.
Це робить дві речі:
- Змушує роботу бути відвантажуваною щотижня — а не колись-завершеною одним великим викидом.
- Дає засновнику момент, щоб побачити реальне vs уявне. Ніщо не лікує повзучість фіч так, як використання власного продукту.
Артефакт 3: рахунки за віхами, привʼязані до демонстрованої роботи.
Кожна двотижнева віха закінчується демо і рахунком. Не платите — якщо демо немає. Розробник не працює вперед — якщо демо не затверджене. В обох сторін є шкіра в грі.
Структура на 12 тижнів, яка зазвичай працює
Грубий шаблон, підлаштовується під проєкт:
Тижні 1–2: Фундамент. Репозиторій, CI, вхід і реєстрація, заглушка Stripe, структура бази, staging-деплої. Ви клікаєте по каркасу. Нічого «фічевого» ще немає, але всі рейки прокладені.
Тижні 3–4: Сценарій 1 (найважливіший) — наскрізний. Страшний, але робочий. Можна користуватися на staging.
Тижні 5–6: Сценарій 2 — наскрізний. Сценарій 1 полірується.
Тижні 7–8: Сценарій 3 — наскрізний. Інтеграції (Stripe-вебхуки, Resend, що завгодно) — зміцнюються.
Тижні 9–10: Полірування. Тексти. Стани помилок. Стани завантаження. Усе, що перетворює прототип на продукт. Базовий SEO. Прохід по Lighthouse.
Тижні 11–12: Продакшн-деплої, Sentry, чек-лист запуску, контент, останній прохід по багах. Мʼякий запуск.
Форма гнеться. Якщо ваш сценарій 1 складний (Stripe Connect з розділенням платежів, кастомний календар) — він зʼїсть більше тижнів, і щось інше скорочується. Але форма — фундамент → сценарії → полірування → запуск — стабільна.
Що реально зриває 12-тижневі плани
За частотою з моїх власних проєктів і того, що чув від колег:
- Пізній дизайн. Дизайн, який приходить на 5-му тижні замість 1-го, убиває перші два спринти продуктивності. Отримайте Figma (або аналог) до старту розробки. Хоча б чорновий.
- «Ще одна фіча» на 9-му тижні. Класика. Обсяг урізаний, розробка йде за планом, запуск уже видно, засновник запалюється: «давайте ще X». Кожна фіча, додана в останній третині проєкту, коштує в 2–3 рази дорожче, ніж у перший місяць. Кажіть ні.
- Затримка погоджень з боку засновника. Ви надіслали демо в пʼятницю. Зворотний звʼязок прийшов у четвер. Це 6 днів неявного затвердження, що губить половину наступного спринту. Засновник має реагувати протягом 48 годин, інакше ритм ламається. Пропишіть це в договорі.
- Сюрпризи з інтеграціями від третіх осіб. Stripe не пройшов KYC. Apple 11 днів ревʼюїть. Google відключив ваш OAuth-застосунок. Таке буває. Закладіть 2-тижневий буфер у 12 тижнів і припускайте, що як мінімум одне з цього трапиться.
- «Треба б переписати вхід по-нормальному» посеред проєкту. Не треба. Відвантажте нудний вхід. Переписуйте, коли будуть платячі користувачі.
Пункти договору, які захищають обсяг
Якщо ви пишете (або підписуєте) договір із фіксованою ціною на 12-тижневий проєкт, ці пункти рятують:
- Бриф — це техзавдання. «Бриф від [дата], доданий як Додаток A, — повний обсяг робіт. Усе, чого в брифі немає, — запит на зміну».
- Запити на зміну — письмові. «Зміни обсягу вимагають письмового запиту на зміну, підписаного обома сторонами, із зазначенням зміни ціни та термінів».
- Ритм погоджень демо. «Результати етапів розглядаються протягом 48 годин з моменту здачі. Відсутність реакції протягом 5 робочих днів — неявне затвердження».
- Чистий вихід. «У разі розірвання будь-якою стороною весь код, зданий до цього моменту, належить клієнту, а розробнику оплачуються тільки завершені віхи».
Жоден із цих пунктів не ворожий. Це пункти, які дозволяють обом сторонам розслабитися і зосередитися на відвантаженні.
Найкоротше правило опису MVP, яке я знаю
Якщо ви не можете описати свій MVP трьома користувацькими сценаріями, однією метрикою успіху і пʼятьма інтеграціями — це ще не MVP. Це мрія. Робота до розробки — це перетворення мрії на бриф.
Більшість засновників опираються цій роботі. Провести вечір за написанням брифу здається менш продуктивним, ніж швидше посадити когось писати код. Це не так. Вечір на бриф вартий 3 тижнів зекономленої розробки. Кожен проєкт, який я здав вчасно, мав бриф до першого комміту. Кожен зсунутий — не мав.
Я пропоную фіксований discovery-етап (1 тиждень, €2.5K), де ми разом пишемо цей бриф. На виході — одна сторінка, документ з обсягом робіт, фіксована ціна на розробку. Якщо розробка не почнеться — бриф лишається у вас, з ним можна йти до кого завгодно. Записатися на discovery-дзвінок.