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

Просто зараз чимало засновників створюють мобільні застосунки, витрачаючи кілька тисяч доларів на ШІ-токени.

Застосунки виглядають чудово. Код під ними — катастрофа, яка тільки чекає свого моменту.

99% таких продуктів помруть протягом 12 місяців. Не тому, що ідея була погана. Тому, що фундамент від початку був приречений завалитися.

Ось чесний розбір: що насправді дає вайбкодинг, хто його переживає і чому зробити правильно з 1-го дня коштує у 1,5 раза дорожче, а заощаджує у 10 разів більше згодом.

Що насправді дає вайбкодинг

Вайбкодинг — генерація цілого застосунку ШІ-інструментами на кшталт Claude, ChatGPT чи Cursor із мінімальним інженерним наглядом — дає щось, що виглядає як продукт.

Екрани. Кнопки. Анімації. Демо перед інвесторами не змусить вас червоніти.

Але всередині:

• Немає цілісної архітектури. Файли й логіка розкидані без жодного шаблону.
• Немає моделі безпеки. API-ключі у фронтенді. Жодної валідації вводу.
• Немає обробки помилок. Лише щасливий сценарій. Граничні випадки тихо валять застосунок.
• Немає розділення відповідальностей. Бізнес-логіка заплутана всередині UI-коду.
• Немає придатності до підтримки. Додаєте одну функцію — ламаються три інші.

Це прототип у костюмі продукту. Демо працює. Продукт — ні.

Ті 99%, що помирають, — і чому

Застосунки, зібрані вайбкодингом, убивають три речі.

Спагеті-код, який не масштабується. Працює для 10 користувачів. Ламається на 500. Розсипається на 2 000. На цьому етапі ви вже не латаєте — ви переписуєте з нуля. І платите за одне й те саме вдруге.

Діри в безпеці, якими рано чи пізно скористаються. Більшість таких застосунків погано працює з автентифікацією. Облікові дані зберігаються абияк, ендпоїнти відкриті, нормальної валідації немає. Один злам ставить крапку на споживчому продукті. Подивіться наш посібник із безпеки iOS-застосунків, щоб побачити, який вигляд має справжній базовий рівень захисту — нічого складного там немає, але кожен пункт потребує рішень, яких ШІ сам не ухвалить.

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

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

Щасливий 1% — що вони зробили інакше

Невелика частина продуктів на вайбкодингу виживає. Усі вони зробили одне: залучили справжніх інженерів, поки не стало пізно.

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

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

Засновники, які вціліли, ставилися до вайбкодингу як до інструмента дослідження, а не інструмента розробки. Саме цієї різниці більшість не бачить.

Математика 1,5x, якої ніхто не рахує

Ось справжні цифри для iPhone-застосунку середньої складності.

Шлях вайбкодингу:

• ШІ-токени + no-code інструменти + латання фрилансерами: 6K–10K €
• Переписування, коли все зламається (а воно зламається): 35K–50K €
• Затриманий запуск, втрачені користувачі, удар по репутації: не порахувати
• Разом: 41K–60K € і 9–14 втрачених місяців

Справжні інженери з 1-го дня:

• Команда досвідчених iOS-інженерів із тими самими ШІ-інструментами: 14K–18K €
• Підтримка протягом 3 років: невисока, бо архітектура це витримує
• Разом: 14K–18K €, запуск за 8–12 тижнів

Різниця не в тому, чи задіяний ШІ. Наші інженери в Applefy щодня працюють із Xcode, Cursor, Copilot і Claude. Різниця в тому, хто ухвалює рішення, яких ШІ ухвалити не може.

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

Що роблять справжні інженери і чого не може ШІ

ШІ чудово пише код. І погано вирішує, який код писати.

Справжні інженери з тими самими ШІ-інструментами ухвалюють рішення, яких немає в жодному промпті:

Архітектура. Що є сервісом, що моделлю, а що поданням (View). Як рухаються дані. Де живе стан. Ці рішення визначають, чи можна буде підтримувати застосунок 3 роки — чи лише 3 місяці.

Підхід до безпеки. Keychain замість UserDefaults. Пінінг сертифікатів для чутливих сценаріїв. OAuth 2.0 з PKCE. Нічого з цього не з’являється за замовчуванням у коді, який згенерував ШІ.

Знання платформи. Різниця між нативним iOS і React Native. Коли доречна Core Data, а коли SwiftData. Як рев’ю Apple реагує на ваші запити дозволів. Що ламається на iOS 17, а що — на iOS 18.

Сценарії відмов. Що станеться, коли мережа зникне посеред транзакції. Коли користувач закриє застосунок під час синхронізації. Коли Apple випустить нову OS і ваш застарілий API перестане працювати.

ШІ генерує код для щасливого сценарію. Інженери проєктують усе інше.

Реальний кейс: Kiolfast — з ШІ, але під керівництвом інженерів

Живий приклад того, що ми маємо на увазі під «справжніми інженерами з тими самими ШІ-інструментами».

Kiolfast — застосунок для обліку витрат на проєкти, який ми в Applefy зробили для Tarik Deljanin: сканування чеків, облік робочого часу, бюджети в реальному часі, спільна робота кількох користувачів, експорт в Excel. Уже в App Store.

Стек: Flutter + Claude Code. Ті самі ШІ-інструменти, що й у вайбкодерів. Інший результат.

Різниця — у тому, чого в застосунку не опинилося:

• Цілісна архітектура. Claude Code написав багато коду, але що саме будувати, де живе стан і як рухаються дані — вирішували наші інженери.
• Жодних компромісів у безпеці. Автентифікацію, зберігання даних і конвеєр експорту в Excel описали в специфікації до того, як згенерували.
• Ніякого «лише щасливого сценарію». Обробку помилок і граничні випадки заклали в обсяг робіт наперед, а не латали після запуску.
• Кодова база, придатна до підтримки. Після запуску її оновлюють, а не переписують.

Ті самі інструменти. Інша інженерна дисципліна. У цьому вся суть.

Деталі, які вайбкодинг пропускає

Їх не видно — рівно доти, доки не стане пізно:

• Облікові дані в Keychain, а не в UserDefaults
• HTTPS із TLS 1.2+ на кожному мережевому запиті
• Валідація вводу в кожному полі, яке бачить користувач
• Модульна архітектура, що дозволяє додавати функції без регресій
• Межі обробки помилок, які гасять збій, а не валять застосунок
• Достовірні мітки конфіденційності в App Store — за брехню тут застосунок видаляють
• Робота з фоновими завданнями, яка не з’їдає батарею
• Керування пам’яттю, яке не спричиняє збоїв на старіших пристроях

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

Вайбкодинг їх пропускає, бо ніхто не попросив про них прямо. ШІ не пропонує того, чого ви не просили.

Підтримувати справжній продукт значно дешевше

Саме цю частину більшість порівнянь вартості пропускає.

Вартість створення — одноразова подія. Вартість підтримки — постійна.

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

За три роки: добре зроблений застосунок потребує 2–3 днів інженерної роботи на місяць. Погано зроблений — 8–12 днів, і це за той самий набір функцій, лише щоб встигати за змінами в iOS і багами від користувачів.

Помножте цю різницю на свою інженерну ставку. Добре зроблений застосунок окупає свою вищу початкову ціну вже за перший рік самої лише підтримки.

Вирішуйте самі

ШІ ви використаєте в будь-якому разі. Ним користується кожна серйозна інженерна команда. Питання не в тому, ШІ чи не ШІ — а в тому, чи є в кімнаті справжній інженер, коли ухвалюють архітектурні рішення.

Зберіть MVP вайбкодингом, щоб швидко й дешево перевірити гіпотезу. У цьому немає нічого поганого.

Але перш ніж вкладатися в масштабування — до реклами, до найму, до пітчів інвесторам — дайте інженеру оцінити те, що ви зібрали.

Якщо це можна врятувати — чудово. Полагодьте фундамент зараз, а не потім.
Якщо ні — перепишіть як слід. 15K € зараз дешевше, ніж 50K € через пів року.

Деталі мають значення. Вирішуйте самі.

Будуєте продукт у Валенсії чи Барселоні? Зустрічаємося особисто. Перша розмова безкоштовна: applefy.tech

Часті запитання

Чи може ШІ справді створити мобільний застосунок, готовий до продакшену?

Він може створити щось, що виглядає готовим до продакшену. Чи буде воно продуктивним, чи масштабуватиметься і чи витримає реальних користувачів — питання вже інше. І без інженерного нагляду відповідь майже завжди «ні».

Яка справжня різниця у вартості між вайбкодингом і наймом справжніх інженерів?

Вайбкодинг дешевший на старті (6K–10K €), але майже завжди вимагає переписування (35K–50K €), коли кодова база не витримує масштабу чи тиску з боку безпеки. Справжні інженери коштують у 1.5–1,8 раза дорожче на старті — і значно дешевше за 3 роки.

Як зрозуміти, чи можна врятувати мій застосунок на вайбкодингу?

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

Що роблять справжні інженери і чого не можуть ШІ-інструменти?

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

Коли вайбкодинг справді доречний?

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