Lovable.dev делает возможным выпуск работающего приложения за выходные. Эта суперсила реальна, и поэтому мы рекомендуем Lovable для прототипов и ранней валидации. Но как только приложение начинает брать реальные деньги от реальных пользователей, тот же шаблон, который привёл вас к запуску, становится узким местом.
Это пособие проходит семь шагов миграции Lovable прототипа в продакшен Nuxt 3 или Next.js приложение. Это тот же процесс, который мы используем для клиентских проектов, сжатый в гид, которым вы можете следовать сами или использовать для брифинга команды разработчиков.
Зачем вообще мигрировать?
Три причины. Первая, безопасность: дефолтный Supabase RLS в Lovable открыт способами, не выдерживающими реальный security audit. Вторая, производительность: сгенерированный код использует Supabase с клиента способами, не масштабирующимися больше нескольких сотен одновременных пользователей. Третья, расширяемость: как только нужна кастомная интеграция, не-шаблонный платёжный флоу или функция, которую UI Lovable не может выразить, вы упираетесь в стену.
Если у вас этих проблем нет, мигрировать не нужно. Lovable нормален в том, что он есть. Триггер - обычно конкретное событие: security review, инцидент масштабирования, корпоративный клиент, требующий SOC 2, или запрос на функцию, которую AI не может надёжно сгенерировать.
Шаг 1: Аудит Lovable проекта
Прежде чем писать новый код, поймите, что у вас есть. Экспортируйте кодовую базу Lovable. Картируйте каждую Supabase таблицу, каждое правило Row Level Security, каждую env переменную и каждую внешнюю интеграцию. Перечислите пользовательские флоу, которые абсолютно должны продолжать работать через cutover - обычно регистрация, логин, платёж и основной флоу доставки ценности.
Это обычно упражнение на 2-3 дня. Пропустите его и найдёте недостающие данные или сломанные флоу во время cutover.
Шаг 2: Выберите целевой стек
Nuxt 3 на Cloudflare Pages или Next.js на Vercel - распространённые варианты для SaaS миграций. Оба хорошо работают, оба имеют отличные экосистемы Stripe и Supabase, оба быстро деплоятся. Выбор обычно сводится к тому, с каким фреймворком ваша команда более комфортна.
Сохраните Supabase как базу данных, если нет конкретной причины переключаться. Postgres от Supabase - тот же Postgres, который вы бы использовали где угодно ещё; проблемы с Lovable приложениями в конфигурации RLS и в том, как код приложения общается с Supabase, а не в самом Supabase.
Шаг 3: Пересоздайте схему и ужесточите RLS
Создайте новый Supabase проект (или новую схему в существующем). Повторите все определения таблиц из исходного проекта. Затем перепишите каждое RLS правило.
Принцип: anon роль никогда не должна иметь insert, update или delete на таблицах с пользовательскими данными. Аутентифицированные пользователи должны иметь доступ только к своим строкам. Всё, что должно пересекать границы строк - администраторские действия, cron jobs, customer support инструменты - должно работать через service-role с бэкенда, никогда с клиента.
Это единственное изменение обычно решает 70-80% security находок в Lovable аудите.
Шаг 4: Переимплементируйте UI
Большинство Lovable приложений используют Tailwind и shadcn/ui, оба переносимы на Nuxt и Next. Миграция - страница за страницей: переимплементируйте сначала самые посещаемые routes, потом менее посещаемые, потом админ-инструменты. Сохраняйте визуальный дизайн идентичным - ваши пользователи не должны замечать cutover.
Время на страницу сильно варьируется. Простой list-detail view может занять 2 часа. Сложный дашборд с графиками и фильтрами - день. Планируйте соответственно.
Шаг 5: Замените шаблонные платежи на реальный Stripe
Платёжная интеграция Lovable - это демо. Она работает для демонстрации инвесторам, что деньги двигаются, но ей не хватает продакшен-критичных эссенциалов: проверка подписи webhooks, idempotency keys на каждом payment intent, надёжные state machines подписок, доступ к customer portal, автоматическая обработка возвратов, dunning email логика для проваленных платежей.
Реализуйте Stripe правильно. Используйте Stripe webhook CLI для локального тестирования. Имейте чеклист сценариев сбоев (обрыв сети во время checkout, double-submit, истёкшая карта, оспариваемое списание) и проверьте каждый. Это единственный самый дорогой шаг, который потом сложно исправить.
Шаг 6: Добавьте observability и CI/CD
Sentry ловит ошибки в продакшене. Axiom или Logflare агрегируют логи запросным способом. Uptime monitor (Better Stack, Pingdom) сообщает, когда приложение падает. Эти три вещи вместе дают видимость, которой у Lovable нет.
CI/CD на GitHub Actions: каждый PR запускает lint, typecheck и тесты. Каждый PR получает preview deploy. Staging окружение зеркалит продакшен для QA. Деплой в продакшен становится скучным, а это то, что вы хотите.
Шаг 7: Cutover
DNS cutover - видимое событие, но наименьший шаг. Выберите окно низкого трафика. Держите Lovable версию живой и DNS-переключаемой 48 часов как опцию отката. Имейте открытый дашборд мониторинга с error rate, успехом платежей и метриками вашего основного user flow.
Сообщите пользователям, что идёт обслуживание. Сделайте само изменение невидимым - те же URL, тот же UI, те же данные, тот же логин. Хорошо сделанный cutover занимает менее 30 минут, и ваши пользователи не замечают.
Что это типично стоит
Типичная Lovable-to-production миграция для SaaS с 1-3 основными user flows стоит €9 000-€18 000 за 4-8 недель. Большие приложения идут выше. Фаза аудита и планирования - точка входа с фиксированной ценой (€600-€1 500) и говорит вам реальный объём, прежде чем вы коммититесь к бюджету.
Детали на странице Lovable в продакшен, или прочитайте связанный гид Что такое vibe coding и когда вашему AI-приложению нужно спасение? для контекста, когда эта миграция действительно стоит того.