Ви зібрали MVP за допомогою ШІ. Залишити, доопрацювати чи переписати?

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

КОРОТКО

Залишити, доопрацювати чи переписати

Якщо ви зібрали MVP за допомогою ШІ і ним уже користуються люди, у вас уже є найцінніше: дані про те, що користувачі роблять і за що готові платити. Чи виживе сам код, залежить від того, що продукту доведеться витримати далі. Вузький внутрішній інструмент із невеликою кількістю користувачів і без чутливих даних часто може залишитися як є. Продукт, який починає приймати платежі, зберігати персональні дані чи обслуговувати клієнтів, зазвичай потрібно зміцнити, а часом і перебудувати на новій основі. Перший крок у будь-якому разі однаковий: з'ясувати, що можна зберегти, перш ніж хтось запропонує переписати все.

Термін vibe coding з'явився на початку 2025 року: так Андрій Карпати назвав розробку, за якої ви описуєте ШІ-моделі, що хочете отримати, і приймаєте написаний нею код. Через півтора року платформи, що генерують, тестують і розгортають застосунок за текстовим описом, стали звичайним інструментом. Якщо завдання достатньо вузьке, власник може зібрати робочу версію за вихідні, дати її клієнтам або співробітникам і подивитися, що станеться.

Цей зсув здешевив радше спробу, ніж сам софт. А для власника, який збирається витратити на наступний етап від $50,000 до $100,000, він змінює й запитання, які варто поставити до того, як гроші буде вкладено.

НОВА РОЗМОВА

Розмова стала іншою

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

Тепер розмова дедалі частіше починається в іншому місці. Власник відкриває ноутбук і каже: «Я зібрав першу версію. Ось як нею користуються люди, ось де вони йдуть, а ось за що готові платити. Допоможіть розвинути». Порядок тут інший: менше припущень і більше поведінки, яку видно. До того ж процес набагато точніше пояснюється через робочий приклад, ніж через довге технічне завдання, бо приклад показує те, чого не сказано словами.

Частина таких експериментів закінчиться взагалі без агенції. Гіпотеза може не підтвердитися, а інструмент може виявитися достатньо добрим для свого невеликого завдання. Це нормальний результат, і власник заощадив гроші, які підрядник узяв би за те, щоб з'ясувати те саме. Про ранішу версію цього рішення ми писали в статті «Чи потрібен мені розробник, чи вистачить ШІ?», і відтоді відповідь ще більше змістилася в бік «спершу спробуйте».

ЩО ДОВЕДЕНО

Що ваш MVP уже зробив

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

Що зазвичай переживає наступний етап, навіть коли код його не переживає:

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

ШІ зробив софт дешевшим у розробці й набагато дешевшим у спробі.

Команда, яка отримує такий матеріал, починає з фактів, а не з брифу, і це має зробити наступний етап дешевшим і менш ризикованим.

ДЕ ЛАМАЄТЬСЯ

Де ламаються MVP, зібрані на ШІ

Обмеження продукту, зібраного через vibe coding, рідко видно на демо. Тест з обмеженим доступом і безпечними даними сильно відрізняється від публічної системи з платежами, персональними даними та зобов'язаннями перед клієнтами. Перевірки безпеки й коректності мають відповідати цим ризикам із моменту приходу реальних клієнтів, а не лише після того, як попит підтвердився.

Дослідження тут сходяться. У звіті GenAI Code Security Report за 2025 рік компанія Veracode протестувала понад 100 мовних моделей на 80 завданнях і виявила, що 45% згенерованого коду містили вразливості зі списку OWASP Top 10, а захист від міжсайтового скриптингу не спрацьовував у 86% відповідних випадків. Того ж 2025 року дослідник виявив, що понад 170 проєктів, зібраних на платформі Lovable, відкривали дані назовні, бо в базі не було правил доступу: email, телефони, статус оплати та API-ключі були доступні будь-кому, хто знав, де шукати. Вразливість зареєстровано як CVE-2025-48757.

Жодна з цих знахідок не означає, що код від ШІ поганий за своєю природою. Вони означають, що модель пише те, що в неї попросили, а про правила доступу її ніхто не запитав.

Слабкі місця, які ми перевіряємо першими, майже завжди однакові:

• хто може бачити й змінювати які дані, і чи стежить за цим база даних, чи лише інтерфейс;
• паролі, API-ключі та платіжні дані, що зберігаються в коді, який працює в браузері;
• резервні копії та те, чи пробував хтось хоч раз їх відновити;
• історія версій: багато проєктів, які ми бачимо, не лежать у жодному репозиторії, тож ніде не записано, що й коли змінювалося;
• тести або хоча б повторюваний спосіб перевірити, що зміна не зламала оплату;
• єдина людина, часто сам власник, яка знає, які промпти породили яку частину системи.

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

ПРИХОДЬТЕ РАНІШЕ

Коли приносити MVP

Власники часто не поспішають показувати продукт команді розробки, поки він не здасться завершеним, ніби за сиру версію треба вибачатися. Нам зручніше побачити його раніше. Сира перша версія, навіть зібрана на простій логіці, вже каже нам більше за будь-який бриф: чим люди користуються, де зупиняються і про що просять. Що раніше ми її побачимо, то дешевша будь-яка зміна, зокрема зміни в логіці продукту, які часом підказують дані MVP.

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

Готовність зазвичай означає три речі: продуктом користуються люди, ви розумієте, що має витримати наступний етап, і на нього відкладено бюджет. Коли все це є, першим кроком стає оцінка MVP, про яку ми докладно розповідаємо наприкінці статті.

Це ще й цікавий час, бо ШІ водночас дає полегшення і створює напругу. Він посилює добрі ідеї та добрі продукти й швидше, ніж раніше, обнуляє слабкі. Чого він не дає, то це самої ідеї та того аналітичного й продуктового мислення, яке перетворює ідею на те, за що люди платять. Ця частина й далі будується разом: власник приносить знання ринку та клієнтів, а команда приносить досвід того, як ростуть продукти.

РІШЕННЯ

Залишити, доопрацювати чи переписати

Рішення залежить не від смаку і не від того, що підрядникові зручніше будувати. Воно випливає з того, що продукту доведеться робити далі.

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

Робочий MVP слугує доказом. Його код є окремим питанням.

МЕНШІ КОМАНДИ

Команди менші, пропозиції інші

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

Тут часто змішують два різні виграші. «У п'ять разів менше людей» і «у п'ять разів швидше» означають різні речі, і їх не можна просто перемножити. Коли одночасно скорочуються і команда, і термін, чесно порівнювати можна лише однаковий обсяг, якість, інтеграції та відповідальність після запуску. Навіть ретельні вимірювання неоднорідні: на початку 2025 року METR виявила, що досвідчені розробники з ШІ-інструментами розв'язували реальні завдання на 19% повільніше, хоча вважали, що працюють швидше, а в оновленні за лютий 2026 року сама назвала нові, позитивніші дані дуже слабким доказом.

Наші власні цифри скромні, і тому ми їм довіряємо. Внутрішню систему продажів Peretz з лідами, проєктами й рахунками приблизно за місяць зробили один senior-розробник, тестувальник і Claude, а роботу перевіряв архітектор. Перехід цього сайту з Laravel 7 на Laravel 13 зайняв три дні. В обох випадках швидкість дали люди, які знали, що будувати, і могли перевірити те, що написав ШІ, а саме там і міститься справжня ціна ШІ.

Менше людей і швидше здавання проєкту дають два різні виграші.

Цей зсув має людську ціну. Скорочення б'ють насамперед по джуніорах і мідлах, чия робота якраз і полягала в реалізації зрозумілих функцій, яку ШІ тепер робить найшвидше. Stanford Digital Economy Lab за даними платіжних відомостей ADP з'ясувала, що зайнятість фахівців від 22 до 25 років у професіях, яких ШІ торкнувся найбільше, зокрема в розробці, до жовтня 2025 року знизилася приблизно на 16% порівняно з менш зачепленими професіями, а в старших колег на тих самих посадах лишилася стабільною. Автори застерігають, що ШІ не єдина причина. Частина цих людей перекваліфікується, бо ринок тепер платить за судження більше, ніж за набір коду. Інші почнуть робити власні продукти в нішах, які добре знають, а отже, власників, що приходять із готовою першою версією, побільшає.

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

ДО ОПЛАТИ

Запитання до оплати

Перш ніж вкладати наступний бюджет, нам чи комусь іншому, ці запитання варто поставити вголос:

1. Які частини мого MVP ви залишаєте і чому? Команда, що пропонує переписати все, ще не подивившись, продає розробку, а не рішення.

2. Що саме переписується і яку проблему розв'язує кожне переписування?

3. Хто перевіряє код, який пише ШІ, і як? Фраза «ми використовуємо ШІ» нічого не каже про перевірку.

4. Де лежатиме репозиторій і кому він належить, разом із доменом, хостингом і даними?

5. Що буде з моїми користувачами та їхніми даними під час переїзду? Добрий план залишає стару версію робочою, поки нова не доведе себе.

6. Що входить у ціну після запуску? Підтримка, виправлення та оновлення входять у те, що ви купуєте.

7. Якщо команда велика, чим зайнята кожна людина? У цьому запитанні немає ворожості, зараз його ставить увесь ринок.

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

ЯК МИ ПРАЦЮЄМО

Що ми робимо з MVP засновника

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

Як це виглядає на практиці, показує проєкт, над яким ми працюємо зараз. Клієнт прийшов до нас із дуже сирим MVP платформи, яка за допомогою ШІ цілодобово відстежує новини та події у світі й пов'язує їх із компаніями та галузями. Логіка була простою, але ідея в ній працювала. Платформа не торгує і ніяк не впливає на ціни та ринки: коли стається щось критичне, користувач отримує сповіщення і сам вирішує, чи реагувати і чи варто купувати або продавати певний тип активів. Назвати клієнта й описати, як влаштована система, ми не можемо, поки її не запущено. Сказати можемо інше: сира перша версія була цінною, бо дала наступному етапу конкретну точку відліку замість опису.

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

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

ОЦІНКА MVP

Чому спершу оцінка

Найдорожча помилка на цьому етапі рідко виявляється багом. Набагато дорожче вкласти від $50,000 до $100,000 у наступну версію продукту, який ринку в такому вигляді не потрібен, або будувати на основі, яку через рік доведеться замінити. Той, хто зібрав першу версію, найгірше може оцінити обидва питання, і це природно: він витратив на продукт тижні й уже бачить, яким той може стати. Зовнішня оцінка коштує малу частину наступного етапу й відповідає на обидва питання до того, як гроші вкладено.

Тому ми зробили оцінку MVP окремою послугою з власною командою. Вона дивиться на продукт із трьох боків:

• Технічний. Наші розробник та архітектор перевіряють код, безпеку й інфраструктуру: правила доступу, ключі та платіжні дані, резервні копії, репозиторій і те, чи витримає структура більше користувачів, функцій і ринків.
• Продуктовий. Продуктовий стратег розбирає, що показують дані про використання, які сценарії працюють, де люди зупиняються і чи варто змінювати логіку продукту або його інтерфейс.
• Ринок і бізнес. Валерія Чумаченко, наш радник із понад десятирічним досвідом у M&A технологічних компаній, оцінює, чи потрібен продукт ринку, хто і скільки за нього заплатить і як його побачить інвестор або покупець.

Третю частину більшість аудитів коду пропускають, хоча вона часто виявляється найціннішою. Продукт може бути технічно чистим і все одно не варти наступних вкладень, а може бути сирим у коді й явно варти доопрацювання, бо люди до нього повертаються. Розуміти, який із цих випадків ваш, цінніше за будь-який список багів.

На виході ви отримуєте письмовий звіт із вердиктом щодо кожної частини продукту (залишити, доопрацювати чи переписати), критичні ризики, які треба усунути до приходу реальних клієнтів і платежів, рекомендації щодо логіки продукту, оцінку обсягу та бюджету наступного етапу й дзвінок, на якому ми все це розбираємо. Оцінка коштує від $3,000, найчастіше від $3,000 до $5,000 залежно від обсягу коду, кількості інтеграцій і того, чи проходять через продукт гроші та персональні дані. Вона оплачується заздалегідь і не зараховується у вартість подальших робіт, бо над кожною оцінкою працюють кілька фахівців, а звіт корисний незалежно від того, чи продовжите ви роботу з нами. З ним можна прийти до будь-якої команди.

FAQ

Джерела

• Veracode: 2025 GenAI Code Security Report
• Superblocks: Lovable vulnerability explained (CVE-2025-48757)
• Stanford Digital Economy Lab: Canaries, interest rates and timing (February 2026)
• METR: Measuring the impact of early-2025 AI on experienced open-source developer productivity