Lovable справді добре вміє одне: за кілька днів перетворити ідею на клікабельний робочий застосунок. Чого він не робить — не каже, які частини цього застосунку не готові до реальних клієнтів, реальних грошей і реальних персональних даних.
Це чекліст, який ми проходимо з кожним Lovable-проєктом перед запуском. Більшість пунктів можна перевірити самостійно. Де потрібен розробник — ми про це прямо кажемо.
1. Код має належати вам: спершу GitHub
Перед усім іншим підключіть проєкт до GitHub. Двостороння синхронізація Lovable дозволяє й далі будувати в Lovable, а код при цьому лежить у вашому репозиторії.
- Репозиторій у вашому акаунті чи організації GitHub, а не у фрилансера.
- Його можна склонувати й виконати npm install та npm run build без помилок.
- Хтось, крім вас, хоча б раз подивився на репозиторій.
Без цього у вас немає продукту, який можна передати розробнику, технічному раднику інвестора чи майбутньому CTO.
2. Безпека Supabase: пункт без компромісів
Більшість Lovable-застосунків використовують Supabase як базу даних і авторизацію. Браузер звертається до Supabase напряму з публічним anon key. Так задумано — але це означає, що правила бази даних єдине, що стоїть між відвідувачем і вашими даними.
- Row Level Security увімкнено на кожній таблиці з даними користувачів або бізнесу.
- Політики обмежують рядки власником (auth.uid()), а не «true» для всіх.
- Адмінські дії захищені не лише тим, що кнопку сховано в інтерфейсі.
- Service role key ніколи не потрапляє у фронтенд чи у VITE_-змінні.
- Сховища з файлами користувачів приватні, якщо їм справді не потрібно бути публічними.
Перевірте так, як перевіряв би зловмисник: увійдіть як користувач A і спробуйте через API прочитати або змінити записи користувача B. Якщо вдалося — запускатися рано.
3. Авторизація, яка працює поза прев’ю
- Site URL і Redirect URLs у Supabase вказують на продакшн-домен.
- Підтвердження email, magic link і скидання пароля перевірені від початку до кінця на справжньому домені.
- Листи авторизації надсилаються з вашого домену через нормального SMTP-провайдера. Вбудована пошта Supabase має ліміти і призначена для розробки.
- Для входу через Google чи інші соцмережі продакшн-домен налаштовано в консолі провайдера.
4. Оплати, що не залежать від браузера
Якщо ви приймаєте гроші, браузер ніколи не має бути джерелом правди.
- Статус підписки чи замовлення оновлює вебхук Stripe, а не редірект на сторінку «успіх».
- Вебхук перевіряє підпис Stripe.
- Бойові й тестові ключі розділені за середовищами.
- Ви перевірили невдалий платіж, скасування підписки й повернення коштів — не лише щасливий сценарій.
5. Помилки, про які ви справді дізнаєтесь
На продакшені користувачі рідко повідомляють про баги — вони просто йдуть. Треба дізнатися раніше за них.
- Встановлено відстеження помилок фронтенду (Sentry або аналог).
- Логи Edge Functions переглядаються, а збої когось сповіщають.
- Є моніторинг доступності головної сторінки і ключових API.
6. Швидкість на реальному телефоні
Прев’ю Lovable зазвичай відкривають на швидкому ноутбуці. Ваші клієнти відкривають застосунок на телефоні середнього класу з мобільним інтернетом.
- Зображення стиснуті й під розмір екрана, а не завантажені в роздільності камери.
- Списки підвантажують дані сторінками, а не тягнуть усю таблицю.
- Головна сторінка має пристойний мобільний результат у PageSpeed Insights.
- Формами й кнопками зручно користуватися великим пальцем, нічого не скролиться вбік.
7. SEO, якщо пошуковий трафік важливий
Lovable-застосунок малюється в браузері. Для кабінету за логіном це нормально, але це слабкий фундамент для сторінок, які мають знаходити в Google.
- Кожен публічний маршрут має власні title і meta description.
- Є sitemap.xml і robots.txt, сайт додано в Google Search Console.
- Прев’ю посилань (теги Open Graph) показують нормальний заголовок і зображення.
- Для маркетингового сайту чи контенту, який має ранжуватися, варто зробити пререндеринг або перенести публічні сторінки на Next.js, залишивши застосунок як є.
8. Юридичний і data-мінімум
- Політика конфіденційності й умови користування опубліковані та є посилання на них при реєстрації.
- Якщо використовуєте аналітику чи маркетингові cookie і працюєте з користувачами з ЄС або Великої Британії — є cookie-банер.
- Ви знаєте, де зберігаються дані (регіон Supabase), і можете на запит експортувати або видалити дані користувача.
9. Бекапи і середовища
- Бекапи бази увімкнено, і ви знаєте, як відновити дані.
- Є окремий staging- або dev-проєкт Supabase, щоб експерименти не зачіпали реальних клієнтів.
- Зміни бази фіксуються як міграції, а не накликуються вручну в панелі.
10. План на наступний етап
Останнє питання стратегічне: продовжувати в Lovable чи переходити на власний стек?
Залишайтесь у Lovable, якщо продукт ще швидко змінюється, команда нетехнічна, а застосунок переважно складається з CRUD-екранів поверх Supabase. Підключіть розробника для рев’ю і складних частин.
Переходьте на власний стек, якщо промпти дедалі частіше ламають інші функції, потрібна складна бізнес-логіка, фонові задачі чи інтеграції, пошук — канал зростання, або ви збираєтесь залучати інвестиції й потрібна кодова база, яку може взяти технічна команда.
Жодна відповідь не хибна. Дорога помилка — надто довго сидіти в інструменті, який проєкт уже переріс.
Як ми можемо допомогти
Ми проводимо Lovable-проєкти саме цим чеклістом: аудит коду й безпеки Supabase, виправлення, деплой на продакшн і, за потреби, поступовий переїзд на Next.js. Код залишається вашим, і в будь-який момент можна продовжити в Lovable.
Доопрацювання проєктів після AI-інструментів — перший аудит безкоштовний, фіксовану ціну ви знаєте до початку робіт. Якщо щось уже зламалося після деплою, почніть зі статті про те, чому Lovable-застосунок ламається після деплою.
