«Скільки коштуватиме доопрацювати мій застосунок із Lovable?» — перше питання майже кожного засновника, і зазвичай далі звучить «там уже майже все готово, треба лише кілька речей». Іноді це правда. Іноді «кілька речей» означає, що база даних відкрита всьому інтернету.
Однієї чесної цифри немає, але є чесний спосіб про це думати. У статті — що впливає на ціну, якими бувають типові обсяги робіт і як не заплатити двічі.
Чому оцінки одного й того самого застосунку так різняться
Засновники часто отримують одну оцінку на $200 і іншу на $5 000 за, здавалося б, однаковий запит. Обидві можуть бути щирими. Різниця зазвичай у тому, що кожен розробник припускає під видимою проблемою.
Дешева оцінка зазвичай покриває рівно той баг, який ви описали. Дорога — враховує, що спершу доведеться зрозуміти всю кодову базу, бо AI-код часто повторює ту саму логіку в кількох місцях, і виправлення однієї копії ламає іншу. Жодна оцінка нічого не означає, поки хтось реально не подивився код.
П’ять речей, що визначають ціну
1. Розмір і структура коду
Застосунок на десять екранів із чіткими компонентами — зовсім інша робота, ніж п’ятдесят екранів, де кожна сторінка отримує дані по-своєму. Lovable-проєкти, що виросли із сотень промптів, часто містять дубльовані компоненти, непотрібні файли й кілька недороблених підходів до однієї функції.
2. Стан безпеки бази даних
Якщо Row Level Security налаштовано правильно, перевірка швидка. Якщо RLS вимкнено або політики дозволяють усе — доведеться перепроєктувати правила доступу таблиця за таблицею і протестувати їх. І це не опційно, якщо ви зберігаєте персональні дані.
3. Інтеграції
Кожен зовнішній сервіс додає роботи: підписки й вебхуки Stripe, поштові сервіси, вхід через Google чи Apple, карти, AI API, CRM. У кожного свої ключі, середовища й сценарії збоїв, які треба правильно налаштувати на продакшені.
4. Де застосунок має працювати
Деплой на домен Lovable — одне. Переїзд на Vercel чи Netlify з власним доменом, окремими staging і продакшн-середовищами, моніторингом і бекапами — інше.
5. Що ви хочете далі
Залишити застосунок у Lovable й виправити конкретні проблеми коштує менше, ніж переносити його на власний стек. Міграція ближча до перебудови фронтенду на міцнішому фундаменті зі збереженням даних, дизайну і логіки.
Три типові обсяги робіт
Точкові виправлення
Конкретний список проблем: помилки деплою, зламані редіректи авторизації, оплата, яка не оновлює акаунт, форма, що не працює на мобільному. Код загалом здоровий, і ви плануєте й далі працювати в Lovable. Найпоширеніший варіант, зазвичай кілька днів роботи.
Повна реанімація
Застосунок загалом працює, але довірити йому платних клієнтів ви б не наважились: аудит безпеки Supabase, виправлення критичних багів, наведення порядку в структурі настільки, щоб нові функції перестали ламати старі, і нормальний деплой на продакшн. Саме це потрібно більшості проєктів перед справжнім запуском.
Переїзд з Lovable
Проєкт переріс інструмент: потрібен серверний рендеринг для SEO, складна бізнес-логіка, фонові задачі або кодова база, яку довго підтримуватиме технічна команда. Обсяг дуже залежить від застосунку, тому оцінювати його варто лише після аудиту.
Як ми рахуємо
Ми працюємо за фіксованою ціною, яку погоджуємо до початку робіт, а не за безкінечною погодинною оплатою. Перший аудит коду безкоштовний: ви отримуєте письмовий список того, що ми знайшли, і фіксовану оцінку. Якщо вирішите не продовжувати — список залишається у вас.
Приховані витрати, на які варто зважати
Кредити, витрачені на промпти по колу
Якщо тиждень вставляєте ту саму помилку в Lovable, ці кредити — реальні витрати. А зміни, зроблені по дорозі, могли створити нові проблеми, які теж доведеться виправляти.
Двічі оплачені симптоми
Розробник, який виправляє лише видимий баг і не з’ясовує, чому він виник, часто залишає причину на місці. Наступного місяця ви платите знову, коли вона вилізе на іншій сторінці.
Переписати все, коли це не потрібно
Протилежна помилка: деякі агенції за замовчуванням радять перебудову з нуля. Багатьом Lovable-застосункам досить точкових виправлень і перевірки безпеки. Перебудова має бути рішенням на основі коду, а не дефолтом.
Безпека «потім»
Налаштувати RLS до запуску — кілька днів роботи. Розбиратися з витоком даних після запуску коштує значно дорожче — і грошима, і довірою.
Як швидко отримати точну оцінку
Процес пришвидшиться, а оцінка буде значно точнішою, якщо підготувати чотири речі:
- Доступ до репозиторію GitHub (підключіть синхронізацію Lovable з GitHub, якщо ще не зробили).
- Список того, що зламано чи бракує, простими словами, зі скриншотами або коротким записом екрана.
- Які інтеграції використовуються: Supabase, Stripe, пошта, інші.
- Що ви хочете далі: будувати в Lovable чи переходити на власний стек.
Тоді розробник дивиться на реальний код, а не вгадує.
Підсумок
Доопрацювати Lovable-застосунок зазвичай значно дешевше, ніж будувати той самий продукт з нуля — велику частину роботи AI вже зробив. Мета — заплатити лише за те, що справді потрібно вашому застосунку, і знати ціну до початку робіт.
Отримати безкоштовний аудит коду. Перед цим варто пройтися нашим чеклістом запуску Lovable-застосунку — дещо можна виправити самостійно вже сьогодні.
