Баги в Lovable-приложениях в 2026: как исправить, когда нанимать разработчиков и реальная цена

Почему ваше Lovable-приложение постоянно ломается в 2026

Вы быстро запустились. Демо прошло хорошо. Потом платящий клиент столкнулся с багом — оплата картой просто не прошла, а исследователь безопасности сообщил о незащищённой таблице. Вы не одиноки. Lovable дал возможность собрать и запустить продукт за выходные — и так же легко позволил выкатить код без row-level security, без проверки вебхуков и с секретным ключом Stripe прямо в клиентском бандле.

Есть три структурные причины, по которым такие приложения ломаются. Во-первых, базовые LLM обучались на устаревших паттернах: старый асинхронный код, примеры Supabase до RLS, устаревшие приёмы в React. Во-вторых, агент Lovable переписывает целые файлы вместо мелких правок — и одна исправление вызывает сразу пять новых ошибок. В-третьих, пока агент генерирует код, нет ни интеграционных тестов, ни отслеживания в продакшене — о баге вы узнаёте только тогда, когда в него натыкается пользователь. Отсюда и замкнутый круг «каждое исправление что-то ломает», о котором основатели жалуются на Reddit и в форуме Lovable.

Почему этот плейбук написала Фора Софт

Фора Софт с 2005 года выпустила более 600 продуктов в области видео, ИИ и обработки в реальном времени. В последнее время большинство наших заявок — это проекты одного типа: нетехнический основатель собрал MVP на Lovable, Bolt или v0, столкнулся с трудностями в продакшене и теперь нуждается в старших инженерах, чтобы навести порядок — не теряя при этом скорости, ради которой он и выбрал эти инструменты. У нас есть отдельная услуга специально для таких случаев: интеграция ИИ, исправление багов в Lovable-приложениях и приведение «вибрового» кода в порядок.

Рекомендации ниже основаны на трёх кейсах. V.A.L.T. — платформа видеодоказательств, которую используют более 770 организаций США (полиция, центры защиты детей, медицинские учреждения); в ней мы внедрили те же паттерны, что и в Stripe-подобных вебхуках, аналоги RLS для контроля доступа и аудит-логирование — то, чего обычно не хватает в Lovable-приложениях. BrainCert вырос из прототипа до выручки 225 млн ₽ и более 100 000 клиентов на real-time-стеке, который мы разрабатывали вместе с командой. Scholarly масштабировался от MVP уровня Lovable до 15 000 пользователей и 2 000 одновременных студентов на стеке Go + React + LiveKit + Kubernetes — стал финалистом премии AWS Most Innovative EdTech. В каждый такой проект мы привносим спецификационно-ориентированную агентную разработку (spec-Driven agent engineering), благодаря которой выпускаем код быстрее, чем традиционная аутсорс-команда.

Краткий ответ за 60 секунд: захардкодить, перенести или переписать

Когда Lovable-приложение начинает причинять боль, есть три честных варианта. Захарднить на месте — оставить кодовую базу Lovable и привлечь старших инженеров, чтобы добавить RLS, серверную валидацию, проверку вебхуков, мониторинг и тесты. Подходит прототипам, которые ещё ищут product-market fit. Перенести на Next.js + Supabase — сохранить данные и общий UX, но перевести рантайм на code-first-стек, который вы можете развивать без разрешения LLM. Подходит SaaS, упёршимся в потолок «Lovable больше так не умеет». Полная пересборка — выкинуть кодовую базу, оставив знания о продукте. Подходит командам с финансированием, которым нужен мультиарендный, соответствующий регуляторике, масштабируемый продукт.

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

Пять типичных багов, с которыми вы столкнётесь

По нашим аудитам 2026 года основная часть проблем сводится к пяти типовым случаям. У каждой из них есть характерная Lovable-форма и проверенное решение.

1. Отсутствует или неправильно настроен Supabase Row-Level Security

Lovable создаёт таблицы, но оставляет RLS выключенным — и анонимный ключ может читать или писать что угодно. CVE-2025-48757 затронула около 170 приложений именно по этому шаблону. Включайте RLS на каждой таблице с пользовательскими данными и пишите политики, привязывающие строки к аутентифицированному пользователю.

ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users see their own posts"
  ON posts FOR SELECT USING (auth.uid() = user_id);

CREATE POLICY "Users insert as themselves"
  ON posts FOR INSERT WITH CHECK (auth.uid() = user_id);

2. Захардкоженные секреты в клиентском бандле

Live-ключи Stripe, токены OpenAI и service-role-ключи Supabase часто попадают в скомпилированный JavaScript. Поищите в репозитории `sk_live`, `OPENAI_API_KEY` и `SERVICE_ROLE` — если что-то найдёте, срочно смените ключи и перенесите вызовы в Supabase Edge Function или API-роут Next.js.

3. Бесконечные циклы в useEffect

Lovable любит класть только что собранный объект в массив зависимостей — и эффект срабатывает на каждом рендере. Страница долбит ваш API, квота Supabase сгорает, а UI мигает. Выносите литерал из эффекта или передавайте примитивы.

// BROKEN
useEffect(() => {
  const filter = { status: 'active', userId };
  fetch('/api/items', { body: JSON.stringify(filter) }).then(...);
}, [filter, userId]); // filter is new every render

// FIXED
useEffect(() => {
  fetch(`/api/items?status=active&userId=${userId}`).then(...);
}, [userId]);

4. Непроверенные вебхуки Stripe (и любые другие)

Сгенерированный Lovable обработчик вебхуков обычно слепо доверяет телу запроса. Это означает, что любой, кто знает URL, может подделать событие `payment_intent.succeeded` и начислить пользователю баланс. Проверяйте подпись на каждом вебхуке, дедуплицируйте по event id и логируйте каждое решение.

5. Сломанная авторизация на уровне объектов

В апрельском инциденте 2026 года исходный код, учётные данные и истории чатов были доступны 48 дней, потому что эндпоинты `/projects/{id}/*` в Lovable проверяли аутентификацию, но не проверяли, принадлежит ли ресурс пользователю. Тот же паттерн встречается и в пользовательском коде: `/api/orders/{id}` возвращает заказ любому авторизованному пользователю. Всегда проверяйте `record.user_id === auth.uid()` перед тем, как отдавать ресурс.

4-часовой чек-лист перед наймом сотрудника

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

1. Экспортируйте код в GitHub и соберите проект. `npm run build` должен выполняться без ошибок и почти без предупреждений. Пожалуйста, включите strict-режим в TypeScript.

2. Прогон статического анализа. ESLint с `eslint-plugin-security`, Semgrep с правилами `p/security-audit`. Оба инструмента бесплатны и за пять минут находят реальные проблемы.

3. Аудит Supabase RLS. Откройте дашборд, посмотрите все таблицы, проверьте, что RLS включён и политики настроены. Для каждой таблицы с пользовательскими данными выполните SELECT под анонимной ролью — результат должен быть пустым.

4. Ревью потока аутентификации. Где хранятся токены? Есть ли механизм обновления? Залогиньтесь, подождите час, обновите страницу — вас разлогинило? Должно было.

5. Проверка секретов. `grep -r "sk_live\|sk_test\|SERVICE_ROLE_KEY\|OPENAI_API_KEY" .` и проверьте собранный JavaScript в DevTools браузера.

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

7. Нагрузочный тест. Запустите k6 с 50 одновременными виртуальными пользователями на 5 минут. Следите за гонками, дублированием и ошибками 5xx в логах.

Когда нанимать разработчиков, а когда продолжать итерации

Реальные цены 2026 года: аудит, хардфоркинг, перенос, пересборка

Цифры ниже — реальные диапазоны из проектов начала 2026 года. Они рассчитаны на один небольшой или средний продукт (5–15 функций, 1–3 интеграции). Регион влияет на стоимость: команды с агентной разработкой обычно находятся в нижней части диапазона, потому что они тратят меньше часов на ту же работу.

Почему это консервативные оценки. Команды из США обычно называют цены в 1,5–2 раза выше верхней границы каждой строки. Мы работаем по модели агентской разработки и опираемся на более доступную базу специалистов, поэтому почти всегда оказываемся на нижнем уровне или даже ниже. Если кто-то предлагает аудит существенно дешевле 225 тыс. ₽ — скорее всего, будет проверка по чек-листу, а не полноценный разбор.

Три пути миграции, бок о бок

На практике часто используется гибридный подход. Мы обычно фиксируем Lovable-сборку на ближайшие 60 дней, параллельно перенося данные и критичные потоки на Next.js + Supabase, а затем переключаемся, когда новая платформа достигнет паритета. Так вы остаётесь на рынке без простоев.

Мини-кейс: Scholarly — от прототипа до AWS Most Innovative EdTech

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

Что мы сделали. Перепроектировали рантайм на Go, React, LiveKit для стримов живых уроков и Kubernetes для оркестрации. Добавили интеграционные тесты вокруг платёжного потока, мониторинг пайплайна лайв-классов и полноценные аналоги RLS-контроля доступа на уровне пользователей и данных. Работали короткими спринтами с основателем в режиме обратной связи, применяя спецификационную агентную разработку, чтобы сократить сроки.

Результат. Более 15 000 пользователей, 2 000 одновременных студентов на сессии, признание AWS Most Innovative EdTech. Тот же подход мы применяем к любому клиенту, который вышел за рамки возможностей Lovable: сохраняем знания о продукте, меняем рантайм, фиксируем интеграции, добавляем телеметрию по всему стеку. Если столкнулись с похожей проблемой — звоните или пишите, обсудим ваш случай.

Каркас решения — выберите путь за пять вопросов

1. Идут ли реальные деньги? Любой платёж в продакшене, подписка или возврат. Если да — нанимайте инженеров и в этом же месяце настраивайте надёжную обработку вебхуков и идемпотентность.

2. Есть ли регулируемые данные? PHI по HIPAA, данные жителей ЕС по GDPR, данные банковских карт по PCI. Если да — простого заявления недостаточно, потребуется аудит и, скорее всего, переработка системы.

3. Вы мультиарендны? Двое и более клиентов используют одни и те же таблицы. Если да — нужен правильно настроенный RLS с политиками, протестированными в условиях атаки, а не просто «включённый».

4. Где вы в цикле починки? Первый раз ловите регрессию — итерируйтесь. В третий раз та же проблема возвращается — зовите настоящих инженеров: в коде накопился технический долг, который никакой агент в чате не устранит.

5. Сколько стоит простой? Демо, упавшее на час, — неприятно. B2B SaaS, лежащий день, — стоит вам клиента. Чем выше цена простоя, тем выше планка для выбора между «харднинг, перенос или пересборка».

Пять ловушек, в которые попадают основатели Lovable-проектов

1. Нанять самого дешёвого фрилансера в момент появления первого бага. Джуниор без опыта работы с Supabase и Next.js принесёт больше багов, чем исправит. Лучше взять одного старшего разработчика или вообще не нанимать никого.

2. Доверить агенту Lovable «починить» проблемы безопасности. Тот же агент, который написал баг, вряд ли проверит исправление. Любые правки, связанные с безопасностью, должны проходить ручную проверку или статический анализ.

3. Верить виджету «security scan». Встроенный сканер Lovable отмечает отсутствующий RLS, но не проверяет правильность политик. Относитесь к нему как к пожарной сигнализации — он предупреждает, но не гарантирует безопасность.

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

5. Относиться к пересборке как к побочному проекту. Спасение кода без чётких границ и контрольных точек по неделям легко выходит за бюджет — в два раза и больше. Зафиксируйте план миграции, выделите время и реализуйте за 6–10 недель.

Что Lovable выпустил в 2026 — и чего так и не сделал

Lovable отреагировал на критику по поводу безопасности рядом полезных улучшений: двухфакторная аутентификация для аккаунтов, корпоративный аудит-лог, контроль политик аутентификации на уровне рабочего пространства и встроенный сканер безопасности при публикации, который выявляет отсутствие RLS. Режим «Chat Mode» позволяет агенту отвечать на вопросы и просматривать логи, не изменяя код — это удобно для первичного анализа инцидентов.

Чего платформа так и не решила: интеграционное тестирование сгенерированного кода, структурированную наблюдаемость между запусками и замкнутый круг «каждое исправление что-то ломает», который порождают агентные переписыватели файлов. Эти задачи нельзя закрыть фича-флагом — в петле нужны живые инженеры. Сканер при публикации — пожарная сигнализация, а не доказательство безопасности; так его и воспринимайте.

Данные о сбоях в 2026 году в простых цифрах

Для основателя в этой развилке важны три набора данных. Первое: раскрытие CVE-2025-48757 — около 170 из 1 645 просканированных Lovable-приложений имели эксплуатируемые уязвимости в RLS, то есть примерно 10%. Второе: выборка AuditMyVibe за 2026 год по 62 проаудированным Lovable-приложениям — у 63% из них найдены проблемы уровня high или critical, в среднем по 10 уязвимостей на приложение. Третье: отчёт GitClear о качестве AI-генерируемого кода за 2025 год: количество дублирующего кода выросло примерно в 8 раз по сравнению с прошлым годом, доля рефакторинга снизилась с 25% до менее чем 10% изменённых строк, а «churn» (правки, отменённые в течение двух недель) заметно увеличился.

Что говорят эти цифры. Lovable-приложения ломаются не случайно: они ломаются предсказуемо и по схожим шаблонам, а проблемы качества AI-генерируемого кода в целом хорошо задокументированы. Это, кстати, хорошая новость. Предсказуемые сбои поддаются исправлению: связка «аудит + харднинг + мониторинг» закрывает большинство из них за недели, а не кварталы.

KPI, которые стоит измерять после расчистки

KPI качества. Цель — ноль открытых критических и высокоприоритетных ошибок. Покрытие тестами оплаты, аутентификации и вебхуков должно быть выше 80%. Количество ошибок в продакшене на 1000 запросов — ниже 5.

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

KPI надёжности. P95 времени ответа сервера. Доля упавших вебхуков Stripe. Количество алертов о нарушении RLS-политик в месяц — цель — ноль. Uptime должен соответствовать SLA, за который платят клиенты, а не просто «в основном работает».

Когда уходить с Lovable НЕ нужно

Не каждое Lovable-приложение стоит пересобирать. Внутренние инструменты, демо, прототипы, ищущие product-market fit, и любой продукт, не работающий с деньгами, идентификацией или подлежащий регулированию, могут спокойно оставаться на Lovable, пока не вырастут до другого стека. Ошибка — считать рантайм Lovable основой продукта: он больше похож на глину — отлично подходит для лепки, но не для несущей конструкции.

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

Как Фора Софт спасает Lovable-приложение

Неделя 1 — аудит. Один старший инженер изучает репозиторий, проект Supabase, живую сборку и конфигурацию Stripe (или другой платёжной системы). На выходе — ранжированный список из 10 главных проблем с указанием уровня критичности, сценария эксплуатации, способа устранения и оценки трудозатрат.

Неделя 2 — согласованный план. Харднинг, перенос или пересборка. Фиксированная цена и объём по выбранному пути с недельными вехами. Делимся публичным трекером в стиле Notion и проводим еженедельные демонстрации.

Недели 3–N — разработка через агентную петлю. При спецификация-ориентированной агентной разработке мы генерируем код строго по спецификации, запускаем интеграционные тесты при каждом изменении и отправляем на ревью PR, которые прошли проверку. Основатель просматривает демо раз в неделю.

Финальная неделя — переключение и наблюдаемость. Подключаем мониторинг на уровне Sentry/Logflare/Better Stack, передаём ранбуки и предлагаем поддержку на условиях part-time на первые 90 дней после релиза.

Сопутствующие материалы, если хотите глубже: как собирать приложения с AI в 2026, как мы используем AI для QA и предотвращения технического долга, и AI в проектировании архитектуры ПО.

Три ценовых сценария из реальных проектов

Сценарий A — B2C-минимальный продукт до получения выручки. 6 функций, оплата не реализована. Итог: аудит (300 тыс. ₽) + интенсивная разработка 3 недели (1,3 млн ₽) = 1,6 млн ₽, 4 календарные недели.

Сценарий B — SaaS с MRR 1,5 млн ₽. Stripe в продакшене, мультиарендность, RLS частично отсутствует. Итог: аудит (450 тыс. ₽) + перенос на Next.js и Supabase за 7 недель (3,3 млн ₽) = 3,8 млн ₽, 8 календарных недель.

Сценарий C — продукт рядом с здравоохранением. PHI хранится в базе данных, есть партнёрские интеграции в продакшене. Итог: аудит (600 тыс. ₽) + пересборка за 12 недель на Next.js и Postgres с контролем соответствия HIPAA (6,7 млн ₽) = 7,3 млн ₽, 13 календарных недель.

FAQ

Что почитать дальше

Готовы починить ваше Lovable-приложение?

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

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