Lovable AI: как собрать приложение и не застрять на красивом прототипе

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

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

Плохое первое задание:

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

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

В текущем интерфейсе Lovable можно начать с Plan mode, обсудить устройство приложения и только затем перейти к реализации. На этом этапе проверьте:

· какие страницы будут созданы;

· какие таблицы и поля нужны;

· кто может читать и менять каждую запись;

· какие состояния есть у заявки;

· где нужна серверная логика;

· какие действия остаются вне первой версии.

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

Прототип часто использует тестовые массивы в коде. Они подходят для макета, но не подтверждают, что приложение умеет сохранять данные и разделять доступ.

Lovable предлагает собственный облачный backend и интеграцию с Supabase. При любом варианте отдельно проверьте:

1. где физически хранятся записи;

2. как создаются пользователи;

3. какие правила запрещают менеджеру видеть чужие заявки;

4. где находится административный секрет;

5. как сделать резервную копию;

6. как забрать данные при переезде.

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

Надпись «Admin» в интерфейсе не является защитой. Если кнопка скрыта, пользователь все равно может попытаться отправить запрос напрямую.

Создайте два отдельных тестовых аккаунта и пройдите сценарии:

· менеджер A открывает свою заявку;

· менеджер A пытается открыть ссылку заявки менеджера B;

· обычный пользователь пытается вызвать административное действие;

· неавторизованный посетитель обращается к защищенной странице;

· администратор меняет назначение и видит обновленный результат.

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

Официальная интеграция Lovable с GitHub синхронизирует код между проектом и репозиторием. Это дает историю, независимый просмотр diff и возможность продолжить разработку вне платформы.

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

· проверьте, что репозиторий принадлежит нужной организации;

· настройте видимость и доступы;

· прочитайте первый коммит;

· убедитесь, что секреты не попали в файлы;

· создавайте небольшие изменения с понятными сообщениями;

· не редактируйте один и тот же участок одновременно в Lovable и локально.

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

Фраза «приложение работает» слишком размыта. Для кабинета заявок критерии могут быть такими:

· новая заявка сохраняется после обновления страницы;

· обязательные поля проверяются на сервере;

· менеджер видит только назначенные записи;

· администратор может переназначить заявку;

· повторная отправка не создает случайный дубль;

· ошибка backend отображается понятным сообщением;

· мобильный экран позволяет выполнить основной путь;

· секреты отсутствуют в репозитории и браузере;

· исходный код синхронизирован с GitHub;

· есть проверенный способ экспорта данных.

Передавайте Lovable один или два критерия за итерацию. После каждой правки смотрите, какие файлы изменились, и повторяйте старые проверки. Так исправление роли не сломает создание заявки.

Проведите отдельные проверки интерфейса и системы.

Для интерфейса:

· понятен ли следующий шаг без объяснения;

· видны ли загрузка, пустое состояние и ошибка;

· работает ли клавиатура;

· читается ли текст на мобильном экране;

· не маскирует ли анимация медленную операцию.

Для системы:

· сохранились ли данные после перезагрузки;

· что произойдет при двойном клике;

· можно ли открыть чужой объект по прямой ссылке;

· как ведет себя приложение при отключенной базе;

· появляется ли наблюдаемая ошибка в журнале;

· можно ли восстановить предыдущую рабочую версию.

Красивый dashboard обычно проверяет счастливый путь. Рабочее приложение отличается поведением на ошибках и границах.

В документации Lovable публикация выполняется через кнопку Publish. Перед ней платформа предлагает security review. Пройдите найденные замечания, но не считайте автоматическую проверку полной гарантией.

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

Если подключаете собственный домен, проверьте активный тариф, DNS и HTTPS по текущей документации. Сначала добейтесь стабильной работы на стандартном адресе Lovable, чтобы не смешивать ошибку приложения и настройку домена.

Назначьте владельцев трех частей:

· продукта: решает, какие состояния и роли правильные;

· кода: принимает изменения и разбирает технические ошибки;

· данных: отвечает за доступ, резервные копии и удаление.

Собирайте не общие пожелания, а наблюдаемые сбои: «менеджер не увидел назначенную заявку», «двойной клик создал две записи», «на телефоне кнопка перекрыта клавиатурой». Каждый такой случай добавляйте в регрессионную проверку.

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

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

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

Такой порядок помогает Lovable сохранять контекст задачи. Формулировка «добавь всю CRM» заставляет инструмент принять десятки связанных решений одновременно и усложняет review.

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

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

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

Определите, где увидеть ошибку формы, backend-функции и базы. Лог должен содержать request ID, время и безопасный контекст, но не пароль, токен или полный текст чувствительной заявки.

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

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

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

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

Один раз клонируйте GitHub-репозиторий и попробуйте запустить проект по README. Отдельно экспортируйте данные. Запишите, какие части требуют Lovable Cloud, Supabase или другого сервиса.

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

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

После исправлений попросите коллегу повторить маршрут без подсказок и сохранить результат отдельным коммитом.

Практику перехода от задания к проверяемому приложению можно пройти на курсе «Вайб-кодинг: быстрый старт». Lovable в этом маршруте остается инструментом, а не заменой решениям о данных и доступе.

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