С Lovable на Cursor: как безопасно перенести работающий SaaS

Чтобы безопасно перенести приложение из Lovable в Cursor, откройте его репозиторий с исходным кодом в Cursor, воспроизведите текущую сборку и выкатите одно небольшое изменение, не трогая бэкенд. Оставьте аутентификацию, биллинг и данные пользователей там, где они уже работают. В этом руководстве описан процесс передачи проекта, бюджет по времени на 8-14 часов, готовый промпт для аудита и чек-лист релиза, который убережет от дорогих ошибок.

Что на самом деле меняется при переезде

Работающему SaaS-продукту не требуется масштабный переписанный код просто потому, что вам захотелось сменить редактор. На практике переход гораздо локальнее: Lovable помог создать первую версию, а Cursor становится местом, где вы изучаете, редактируете, тестируете и поддерживаете этот код.

Это миграция процесса разработки. Перенос хостинга - отдельная задача. Как и перенос базы данных.

Если свалить все три задачи в одну кучу, сбои будет в разы труднее диагностировать. Если после одновременной смены фронтенда, провайдера аутентификации и домена отвалится логин, у вас будет сразу три вероятные причины вместо одной.

Оставьте рабочие части на месте

| Уровень | Рекомендация для первого этапа | Причина | |---|---|---| | Исходный код | Работайте с подключенным или экспортированным репозиторием | Сохранить историю и создать базовую версию для правок | | Редактор | Откройте проект в Cursor | Сменить интерфейс разработки | | База данных | Оставьте текущий сервис | Избежать лишнего переноса пользовательских данных | | Аутентификация | Оставьте текущего провайдера и продакшен-URL | Снизить риски для логина и сессий | | Биллинг | Оставьте платежный аккаунт и рабочие эндпоинты вебхуков | Сохранить подписки и логику доступа к функциям | | Хостинг | Оставьте как есть, если он подходит под пайплайн релизов | Не смешивать правки кода с изменениями инфраструктуры |

Доступ к исходникам не гарантирует переносимость инфраструктуры. В репозитории может лежать фронтенд-код и определения функций, но там нет задеплоенных секретов, записей из базы данных или настроек сторонних сервисов.

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

Переходите только ради понятной цели

Веские причины для переезда: необходимость в удобной навигации по коду, воспроизводимых тестах, контролируемом рефакторинге или процессе код-ревью, подходящем для подрядчиков.

"Настоящие фаундеры пишут код в редакторах" - это не причина. Разочарование от одной неудачной генерации - тоже.

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

Проведите аудит приложения и создайте точку отката

Заложите 1-2 часа на этот этап для небольшого приложения со сносной документацией. Если вы не можете с ходу определить, где крутится аутентификация или биллинг, остановите миграцию и разберитесь.

1. Составьте карту рантайма, а не просто список файлов

Создайте файл `docs/runtime-map.md` и зафиксируйте:

• Где задеплоен фронтенд и как проходят релизы.
• Какая база данных используется и на кого оформлен аккаунт.
• Какой сервис отвечает за аутентификацию.
• Где выполняются серверные функции.
• Куда приходят платежные вебхуки и где крутятся задачи по расписанию.
• К каким почтовым сервисам, хранилищам и AI-провайдерам обращается приложение.
• Где настраиваются переменные окружения.

Записывайте имена переменных и места их хранения, а не сами секретные значения. Не вставляйте креды в чат с AI.

Отделяйте безопасные для браузера параметры от серверных секретов. Публичный идентификатор клиента во фронтенд-коде - это нормально; данные администратора базы или секретный ключ платежки - нет. Само по себе название переменной еще не доказывает ее безопасность.

2. Опишите поведение, которое нужно сохранить

Используйте два тестовых аккаунта с разными организациями или воркспейсами. Минимальный сценарий проверки:

1. Создать аккаунт и войти в систему.
2. Создать основную сущность в приложении.
3. Перезагрузить страницу и убедиться, что запись сохранилась.
4. Проверить, что у второго аккаунта нет к ней доступа.
5. Прогнать сценарий оплаты подписки в тестовой среде.
6. Выйти из аккаунта и убедиться, что защищенные страницы недоступны.

Добавьте сценарий, за который пользователи реально платят деньги. Для SaaS с отчетами это может быть импорт тестового файла и генерация отчета. Идеально работающий экран логина еще не означает, что продукт функционирует.

Зафиксируйте существующие ошибки до того, как начнете что-то менять. Иначе потом потратите часы, обвиняя Cursor в баге, который был там изначально.

3. Подготовьте пути отката кода и инфраструктуры

Когда репозиторий приведен в порядок, а базовое состояние проверено, поставьте тег:

```bash git status git tag pre-cursor-handoff git push origin pre-cursor-handoff ```

Перед пушем убедитесь, что случайно не закоммитили секреты. Если нашли лишнее - ротируйте ключ; простое удаление файла не сотрет его из истории Git.

Тег сохраняет код, но не данные пользователей. Отдельно проверьте настройки бэкапов базы данных, процедуру восстановления и дату последней успешной копии. Бэкап, который нельзя восстановить, - это просто файл с успокаивающим названием.

Запишите идентификатор текущего продакшен-деплоя и алгоритм его отката или повторного деплоя. Если хостинг не умеет делать простой откат в один клик, отработайте процедуру гарантированного редеплоя рабочей версии до первой правки.

Не меняйте схему базы данных во время этого перехода. Так откатить код в случае чего будет намного проще.

Переносим разработку в Cursor за пять шагов

Цель - воспроизводимый проект и один крошечный проверенный патч. А не идеальная архитектура к вечеру воскресенья.

Шаг 1: Откройте репозиторий и настройте окружение

Используйте имеющуюся интеграцию с GitHub или стандартный экспорт, чтобы получить исходники, склонируйте репозиторий локально и откройте папку в Cursor.

Изучите `README`, `package.json`, локфайлы и конфиги деплоя перед запуском любых команд. Не думайте, что во всех проектах Lovable одинаковые скрипты или одинаковая инфраструктура.

Создайте рабочую ветку:

```bash git switch -c cursor-handoff ```

Выберите один основной инструмент для редактирования на время перехода. Не вносите изменения одновременно через Lovable и через Cursor в одну и ту же ветку.

Проверьте, как связка Lovable и GitHub в вашем проекте обрабатывает ветки и входящие изменения, прежде чем рассчитывать на бесшовное двустороннее редактирование. Сам по себе доступ к репозиторию не гарантирует, что локальные правки корректно подтянутся в визуальный конструктор.

Шаг 2: Воспроизведите текущую сборку

Используйте именно ту версию рантайма и пакетный менеджер, которые указаны в проекте. Не обновляйте зависимости во время переезда.

Для проекта на npm с закоммиченным `package-lock.json` начните со следующих команд:

```bash npm ci npm run ```

Вторая команда выведет список доступных скриптов. Запустите те команды для разработки, сборки, линтинга и тестов, которые реально описаны в проекте. Не выдумывайте успешные результаты тестов, если скрипта для их запуска вообще нет.

Если нетронутый проект не собирается, скопируйте точный текст ошибки и разберитесь с исходной проблемой отдельно. Несовпадение пакетных менеджеров - не повод генерировать приложение с нуля.

Шаг 3: Изолируйте разработку от продакшена

Если есть возможность, используйте отдельное бэкенд-окружение. Если нет - ограничьтесь фейковыми данными и жестко урезанным доступом. Не проводите разрушительных экспериментов на живых данных пользователей.

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

Особое внимание уделите аутентификации. Добавьте нужные редиректы для локальной разработки или превью в настройках провайдера, но не трогайте рабочие продакшен-URL. Проверьте сброс паролей и magic links, если приложение их использует.

Для биллинга используйте тестовые ключи и отдельный эндпоинт для вебхуков. Ни в коем случае не направляйте продакшен-вебхуки подписок на свой ноутбук.

Часть бессерверных или облачных функций может не запускаться локально. Зафиксируйте, какие вызовы уходят во внешние сервисы, на какое окружение они попадают и приводят ли эти запросы к списаниям или необратимым изменениям данных.

Шаг 4: Запросите у Cursor аудит перед внесением правок

Используйте этот промпт, как только откроете репозиторий:

```text Действуй как мейнтейнер, принимающий существующий SaaS-репозиторий. Начни в режиме только для чтения. Не редактируй файлы и не запускай команды деплоя, установки, миграций или разрушительные действия.

Изучи код и предоставь отчет:

1. Фреймворк, рантайм, пакетный менеджер и доступные скрипты.
2. Входные точки фронтенда и защищенные роуты.
3. Границы базы данных, аутентификации, биллинга и серверных функций.
4. Имена переменных окружения и места их вызова.

Никогда не выводи значения секретов и не читай локальные файлы с секретами.

1. Существующие тесты и недостающие проверки для ключевого пути пользователя.
2. Код или конфигурацию, явно привязанные к хостинг-провайдеру.

Четко разделяй проверенные факты и предположения. Указывай пути к файлам. Не утверждай, что проверка пройдена, если она не запускалась на самом деле.

Предложи одно небольшое, обратимое улучшение без правок схемы БД, без обновления зависимостей и без изменений в аутентификации или биллинге. Укажи критерии приемки и план отката. Жди подтверждения. ```

Полезный результат здесь - это проверяемая карта проекта, а не красивое сочинение. Откройте упомянутые файлы и перепроверьте ключевые выводы. Готовые шаблоны под конкретные задачи можно найти в нашей библиотеке промптов.

Шаг 5: Выкатите подчеркнуто скучный патч

Выберите максимально простое изменение: улучшите пустое состояние (empty state), уточните текст ошибки валидации или поправьте верстку.

Попросите Cursor изменить только нужные файлы. Внимательно проверьте diff на предмет обновления зависимостей, случайно удаленных проверок авторизации, неожиданных правок в конфигах или посторонней уборки кода.

Снова прогоните базовые проверки. Если мелкий фикс интерфейса затронул 40 файлов, остановитесь и разберитесь, почему так произошло.

Заложите 2-3 часа на локальную настройку и 3-5 часов на аудит, первый патч и его проверку. Отсутствие документации легко может увеличить эти сроки.

Безопасный релиз и ревизия инструментов

Оставьте еще 2-4 часа на тестирование на превью-стенде, деплой и финальные проверки после релиза. В итоге общий бюджет времени составит 8-14 часов - без учета переноса бэкенда, исправления критических багов или изучения незнакомого фреймворка с нуля.

Заложите бюджет на переход

Это ориентировочные резервы на планирование, а не официальные тарифы на октябрь 2026 года. Текущие подписки и счета за продакшен оплачиваются отдельно.

| Расходы на миграцию | Рекомендуемый резерв | Что может увеличить сумму | |---|---:|---| | Временная инфраструктура для тестов и превью | $0-$30 | Отдельная база данных или платная среда для превью | | Дополнительные токены AI | $0-$40 | Частые аудиты с большим контекстом и масштабные переписывания кода | | Тестовые письма, хранилище и API-вызовы | $0-$10 | Реальные внешние запросы вместо моков и фикстур | | Непредвиденные расходы | $20 | Внезапные сложности при тестировании или деплое | | Итоговый дополнительный резерв | $20-$100 | Не является жестким лимитом |

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

Время разработчика стоит дороже всего. Десять часов, потраченных на восстановление упавшей инфраструктуры, могут обойтись дороже, чем еще один месяц оплаты вполне удобного no-code конструктора.

Чек-лист перед релизом

• [ ] Исходное состояние проекта успешно собирается.
• [ ] Патч находится в отдельной ветке и прошел ревью.
• [ ] В diff и отслеживаемых локальных конфигах нет секретов.
• [ ] Продакшен-URL аутентификации остались без изменений.
• [ ] Доступ к чужим данным проверен и корректно заблокирован.
• [ ] Проверки биллинга проводились на отдельном тестовом стенде.
• [ ] Поведение на превью соответствует основному пути пользователя.
• [ ] Нет миграций базы данных и посторонних обновлений зависимостей.
• [ ] Предыдущую версию на продакшене можно быстро восстановить или задеплоить заново.
• [ ] Продакшен-деплой содержит именно нужный коммит.

Деплойте тогда, когда сможете следить за состоянием сервиса. Сразу после релиза повторите вход в систему, создание сущности, проверку ее сохранения и сценарий оплаты с тестового аккаунта. Проверьте логи приложения и системы мониторинга ошибок на появление новых сбоев.

Если нарушился контроль доступа или утекли данные пользователей, немедленно остановите релиз и локализуйте проблему. Если вылезла обычная регрессия, откатитесь через проверенную процедуру деплоя. Не позволяйте AI-агенту на лету чинить продакшен сразу в нескольких сервисах.

Разделяйте инструменты по зонам ответственности

После передачи проекта Cursor может отвечать за разработку и код-ревью, пока существующие сервисы поддерживают работу приложения. Оставьте Lovable, если визуальный режим по-прежнему экономит время, а синхронизация правок уже отлажена.

Отменяйте лишние подписки только после того, как убедитесь, что публикация, хостинг или другие сервисы не завязаны на этот аккаунт или тариф. Храните инструкции по эксплуатации вне истории чатов обоих редакторов.

Для последующих задач придерживайтесь той же тактики небольших изменений, которую мы описываем в наших руководствах для фаундеров и инженеров. Владеть кодовой базой - значит уметь объяснить, протестировать и восстановить ее. Просто открыть проект в другом редакторе для этого недостаточно.

Может ли Cursor редактировать приложение, созданное в Lovable?

Да, если у вас есть доступ к исходным файлам. Cursor спокойно работает с репозиторием, но не воссоздает автоматически внешние сервисы, секреты, настройки деплоя или пользовательские данные. Эти зависимости нужно проверять отдельно.

Нужно ли переносить базу данных из Lovable?

Обычно при смене редактора это не требуется. Оставьте текущую базу данных, если она доступна и закрывает ваши потребности. Перенос данных клиентов - это отдельный проект, требующий бэкапов, проверки миграций, тестирования прав доступа и собственного плана отката.

Можно ли отменить подписку на Lovable после перехода в Cursor?

Возможно, но простого открытия репозитория в Cursor для этого мало. Сначала убедитесь, что продакшен-хостинг, бэкенд, процесс деплоя и функции аккаунта продолжат работать без активной подписки. Перед отменой обязательно сверьтесь с текущими условиями сервиса.