Як я б збирала MVP і як насправді обираю стек

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

Більшість провалених MVP не занадто малі. Вони удавано великі: напівзібрана «платформа» з авторизацією, дашбордами, сповіщеннями й трьома середовищами - і ніхто так і не виконав ту одну роботу, яка мала довести ідею. Технології часто стають алібі. Ця стаття - як я б справді віддала це в прод.

1. Що таке MVP - і чим я відмовляюся його називати

MVP - це не «версія 1 з меншою кількістю екранів». Це найдешевший експеримент, який може вбити або підсилити найризикованіше припущення. Якщо припущення - «люди заплатять, щоб записатися онлайн», MVP - це запис плюс оплата плюс людина з того боку. Не CRM, не програма лояльності, не нативний застосунок.

• Viable означає: живий користувач може закінчити живу роботу. Клікабельний прототип у Figma - це дослідження, не MVP.
• Minimum означає: усе, що не служить цій роботі, - тікет на потім, навіть якщо «легко додати».
• Product означає: наступного тижня ви це повторите без героїзму. Google Form плюс таблиця можуть бути MVP. Перепис архітектури Netflix - ні.

2. П’ять питань, доки репозиторію ще немає

Сперечатися про стек дешево. Незакриті продуктові питання - дорого. Я не обираю Postgres проти Mongo, поки не можу відповісти на це вголос - із засновником, не зі статтею.

• Хто перші десять користувачів, бажано на ім’я - не «всі з телефоном».
• Яку одну роботу вони «наймають» продукт виконати цього місяця? Одну. Не платформу.
• Звідки гроші або сигнал - списання з картки, підписаний договір, зайнятий слот, кваліфікований лід?
• Яке обмеження справжнє: чотири тижні, один розробник, регульована ніша, наявна CRM, аудиторія в Telegram?
• Що змусить зупинитися? Якщо немає критерію «вбити ідею» - це хобі, не експеримент.

3. П’ять фільтрів, якими я обираю технології

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

• Час до першого живого користувача. Якщо стек додає тиждень до першого кліка - це неправильний стек для MVP. Нудні інструменти, які я вже віддаю в прод, виграють у модного, який я вчитиму під дедлайном.
• Експлуатація однією людиною. Я маю вміти задеплоїти, прочитати логи, відновити копію і змінити ключ без platform-команди. Kubernetes цей тест на ранньому продукті майже завжди провалює.
• Можна найняти й замінити. TypeScript, Postgres і React не захоплюють. Ними вже розмовляють інші нормальні люди. MVP, який можу розвивати лише я, - заручник, не актив.
• Де лежать дані. Джерело правди - у нормальній базі з міграціями з першого дня, якщо є користувачі й гроші. Таблиці ок для експерименту поруч із продуктом - не всередині checkout.
• Люк евакуації. Візьму managed auth, хостований Postgres, платіжного провайдера. Не підпишу п’ятирічний lock-in, з якого боляче виходити. Постачальник - нормально. Пастка - ні.

4. Типовий вебстек, з якого я б почала у 2026

Для типового B2B чи сервісного MVP - запис, збір лідів, невеликий кабінет, калькулятор, що стає комерційною пропозицією - я б почала звідси. Не тому, що модно. Тому що можу віддати в прод, зробити SEO і за пів року найняти когось іншого.

• Next.js + TypeScript + Tailwind: один застосунок для маркетингових сторінок (SEO, серверний рендер) і продуктового UI. Менше репозиторіїв, один деплой, спільні типи. App Router ок, якщо команда його вже знає; робочий Pages-застосунок «заради чистоти» не переписуватиму.
• Postgres (часто через Supabase, Neon або невеликий VPS): реляційні дані, транзакції і SQL, який я прочитаю о другій ночі. Документну базу беру лише коли форма справді документна - не тому, що «NoSQL швидший».
• Auth: managed-провайдер (Clerk, Auth.js + відомий IdP, або Supabase Auth), якщо продукт - не сама авторизація. Власні сесії в перший тиждень - це як злити токени й зупинити справжню можливість.
• Платежі: Stripe (або локальний еквівалент, яким реально платять перші користувачі). Жодного самописного білінгу. Рахунки-фактури можуть зачекати; робоче списання - ні.
• Хостинг: Vercel для Next.js, якщо трафік «веб» і команді потрібні прев’ю; Hetzner/VPS + Docker Compose - якщо потрібен довгий воркер, передбачувана ціна або розміщення даних. Про цей вибір я писала окремо. Правило MVP: одне середовище, яке ви розумієте, нічні копії, HTTPS і домен.
• Пошта й файли: Resend або схожий транзакційний API; S3-сумісне сховище. Не «збудуємо модуль вкладень».

5. Коли я відходжу від типового стеку

Типовий стек - стартова ставка, не релігія. Я його міняю, коли обмеження і є продукт.

• Аудиторія вже живе в Telegram: бот або Mini App може бути всім MVP. Сайт, який ніхто не відкриє, - не «солідніше». Це друга порожня кімната.
• Робота в полі зі слабким сигналом: дивлюсь на local-first або PWA, не на нативний перепис у перший тиждень. Натив - рішення про дистрибуцію, не відзнака.
• Ядро - мова (підтримка, комерційні, витяг з документів): додаю LLM API за строгою схемою і кроком людської перевірки. Не обгортаю чат-віджет і не називаю це продуктом.
• Засновник - оператор, а контент - продукт: швидкий сайт плюс CMS, якою реально користуватимуться, може виграти в кастомної адмінки. WordPress досі ок, якщо робота - публікувати, а не будувати застосунок.
• Двосторонній майданчик: усе одно віддаю в прод один бік першим. Пропозицію або попит - що важче зібрати. «Платформа» з порожніми стільцями з обох боків - лендинг із зайвими таблицями.

6. Що я відмовляюся додавати до перших користувачів

Найшвидший спосіб провалити експеримент - збудувати компанію навколо експерименту. Цей список я тримаю поруч із беклогом.

• Мікросервіси, шина повідомлень і Kubernetes. Один процес, одна база, один деплой. Ділити, коли з’явиться справжнє вузьке місце або справжня межа команди - не коли діаграма виглядає «сеньйорно».
• Дизайн-система на 80 токенів без екранів. Віддайте в прод три екрани, які збирають гроші. Витягайте компоненти, коли третій copy-paste уже болить.
• Ролі, права, журнал аудиту і SSO - якщо платний B2B-покупець не заблокував угоду через них. Тоді це і є MVP, не побічний квест.
• Другий мобільний застосунок. Адаптивний веб або Mini App закриває першу сотню користувачів у більшості сервісних бізнесів, які я бачу.
• Ідеальне покриття тестів на клейовому коді. Тести на гроші, auth і ключову роботу - так. Тиждень моків на форму лендингу - ні.

7. Як насправді виглядали б перші чотири тижні

Календар - це продуктове рішення. Якщо тижні не можна описати, плану немає - є бажання.

• Тиждень 0 (два дні, не два тижні): односторінковий опис. Користувач, робота, критерій зупинки, що не робимо. Три екрани начерком. Домовитися, що таке «готово»: стороння людина проходить сценарій без нашого Zoom.
• Тиждень 1: вертикальний зріз. Домен, деплой, база, порожній макет, один щасливий шлях у продакшені (навіть якщо страшний). Якщо на третій день немає деплою - стек уже бреше.
• Тиждень 2: робота. Запис, прорахунок, завантаження, оплата - що записали в тиждень 0. Ручні операції за інтерфейсом дозволені: пінґ у Telegram власнику - можливість, якщо вона закриває цикл.
• Тиждень 3: бридкі краї. Порожні стани, помилки, мобільний, листи, базова аналітика (де відвалились). Не сховище даних. Воронка, яку можна прочитати.
• Тиждень 4: показати тим десяти на ім’я. Дивитися. Не додавати можливості під час дзвінків. Записати, що вони зробили, а не що хотіли б.

8. Після запуску: лишити, витягти чи переписати

Хороший MVP має право бути трохи ніяковим. Він не має права бути пасткою. Стек вище нудний навмисно: у нього можна вирости. Рідко треба з нього виростати в перший рік.

• Лишити: мову, базу, імена домену в коді. З цим дешево жити і дорого викидати.
• Витягти: воркер, другий сервіс, чергу - коли завдання повільне, небезпечне або належить іншій команді. Не раніше.
• Переписувати лише ту частину, яка засвоїла неправильний урок. Checkout кривий - переписуйте checkout. Увесь застосунок - вайб-лабіринт: спочатку проблема людей. Хтось має вміти пояснити систему о другій ночі.

Висновок: обирайте стек, який переживе перше «ні»

Я б збирала MVP непретензійно: одна робота, одна база, один деплой, інструменти, які можу крутити сама, і дата, коли вирішуємо йти далі чи зупинитися. «Найкраща» технологія - та, що не відволікає від цього рішення. Next.js, TypeScript, Postgres, managed auth і платіжний провайдер - не особистість. Це спосіб витратити дефіцитні тижні на продукт, а не на платформу.

Якщо є ідея, дедлайн і страх обрати «не той» стек - напишіть через блок контактів. Можемо зафіксувати одну роботу, назвати, що не робимо, і віддати в прод зріз, який можна показати живим людям, не зводячи спочатку фейкову платформу.