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

У вас є дек, фінмодель і список функцій, а розмова з інвестором закінчується одним питанням: чи можна це клікнути. Без робочої версії — другої зустрічі не буде.
Список функцій ріс після кожної зустрічі, бо обсяг так і не закрили, а реліз зсувався щомісяця. Пів року роботи — і жодного користувача.
Ви надсилаєте один запит і отримуєте кошториси, які відрізняються в рази, бо кожен з них описує інший обсяг робіт. Бюджет у вас один — а вибір наосліп.
Гіпотеза для перевірки та закритий список функцій v1
Екрани, зʼєднані переходами, до першого рядка коду
Продакшн-екрани зі станами порожнього, помилки й завантаження
React, TypeScript, backend, база даних, API та інтеграції
Цілі сценарії користувача в браузерах і на пристроях
Продакшн, домен, моніторинг і події на ключових кроках
Розбираємо ідею на одну гіпотезу та сценарій користувача, який її перевіряє. Ділимо функції на v1 і відкладені, а біля кожної відкладеної записуємо причину, щоб після релізу було зрозуміло, до чого повертатися.
Збираємо клікабельний прототип основного сценарію й оцінюємо закритий обсяг. Термін 3–5 тижнів рахується від погодження цього кошторису — тому ми не називаємо його, доки не знаємо, що будуємо.
Проєктуємо екрани узгодженого сценарію разом із порожнім станом, помилкою та мобільною версією. Паралельно фіксуємо архітектуру, модель даних і точки інтеграцій, щоб розробка не спинилася на технічному рішенні.
Кодимо frontend, backend та інтеграції, а результат щотижня викладаємо на тестове середовище з окремим посиланням. Ви бачите робочий продукт під час робіт і встигаєте сказати своє, доки функція не розійшлася по інших екранах.
Тестуємо цілі сценарії за критеріями готовності, узгодженими разом з обсягом, у браузерах і на телефонах. Виправляємо помилки, готуємо стартові дані й тексти повідомлень, які користувач побачить першого дня.
Запускаємо продукт у продакшн: домен, сертифікат, моніторинг і аналітика. Передаємо доступи, документацію архітектури та список функцій, відкладених до наступної версії, разом із причиною кожного рішення.
Обидва шляхи мають сенс — у різних ситуаціях. Нижче те, що між ними реально змінюється.
| Повна версія одразу | MVP | |
|---|---|---|
| Обсяг функцій | Увесь список зі стратегічних сесій і розмов з інвестором, разом з тим, що ще ніхто не перевіряв | Один основний сценарій і функції, без яких його не пройти й не виміряти |
| Час до перших користувачів | Місяці — перші користувачі бачать продукт у самому кінці робіт | 3–5 тижнів від погодження обсягу та кошторису |
| Що зафіксовано до старту | Обсяг росте під час робіт, тому термін і витрати ви дізнаєтеся вже по дорозі | Закритий список функцій v1, термін і фіксована ціна — усе погоджено до першого рядка коду |
| Що ви перевіряєте | Усе одразу — після релізу важко сказати, яка саме функція спрацювала | Одну гіпотезу — зрозуміло, що перевіряєте і за чим побачите результат |
| Ціна зміни курсу | Висока: доводиться переписувати готові, протестовані модулі | Низька: змінюєте план і список функцій, а не місяці коду |
| Чим ризикуєте | Витрачаєте бюджет на функції, якими ніхто не скористається, і дізнаєтеся про це найпізніше | Частина функцій чекає; якщо гіпотеза підтвердиться, ви добудовуєте їх до наявного коду |
| Коли обирати | Процес відомий, є платні клієнти або жорсткі вимоги — наприклад регуляторні | Перевіряєте ідею, бюджет обмежений, продукт потрібен для розмови з інвестором |
Після воркшопу з обсягу, разом із клікабельним прототипом. На суму впливають кількість екранів і ролей, зовнішні інтеграції та те, чи є у v1 мобільний реліз. Після погодження ціна фіксована.
3–5 тижнів після узгодження обсягу — з моменту, коли ви погоджуєте список функцій v1 і кошторис. Воркшоп і прототип займають до цього близько тижня.
Один основний сценарій користувача й функції, без яких його не пройти та не виміряти. Відкладаємо ролі, крім перших двох, адмінпанель, платежі до першого покупця та нативні релізи.
Так. Будуємо тим самим стеком, що й повні продукти: React, TypeScript і backend під завдання проєкту. Відкладаємо функції, а не якість коду — нові ролі та інтеграції додаються до наявної бази.
Fixed price за закритий обсяг — саме тому стільки уваги приділяємо воркшопу до старту. Розвиток після запуску рахуємо помісячно або наступними етапами з фіксованою ціною.
Це нормальний результат першої версії — MVP має дати дані, а не підтвердити припущення. Повертаємося до списку гіпотез і оцінюємо новий обсяг окремо. Ви змінюєте план, а не місяці коду.
Так, із цього й починаємо. На воркшопі діє один критерій: функція лишається у v1, якщо без неї не пройти основний сценарій або не виміряти гіпотезу. Решта йде до відкладених.