Если вы собрали приложение в Lovable, Bolt, Claude Code или Cursor и оно работает в демо, на первый вопрос об идее вы уже ответили: её можно показать, прокликать и объяснить. Чего демо не доказывает, так это того, что приложение можно отдать незнакомым людям, которые будут хранить в нём настоящие данные и платить настоящие деньги. Между этими двумя состояниями почти всегда стоит один и тот же короткий список: кто видит какие данные, что происходит, когда платёж или письмо не прошли, где лежат данные и кто управляет аккаунтами. Одни прототипы можно довести до рабочего продукта. Другие дешевле переписать, а прототип оставить как техническое задание.

В чём эти инструменты действительно хороши

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

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

Где прототип обычно ломается

Кто может читать какие данные

Это проверяют первым. Многие приложения, собранные с помощью AI, используют Supabase как базу данных и обращаются к ней прямо из браузера. Такая схема безопасна, только если на каждой таблице включена Row Level Security (RLS, защита на уровне строк) и есть правила, какой пользователь какие строки может читать и менять. Документация Supabase сама говорит: включайте RLS на каждой таблице в открытой схеме.

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

Ключи из того же списка. Публичный ключ (publishable key) в браузере это нормально. Секретный нет: Supabase прямо пишет никогда не использовать секретный ключ в браузере, а Stripe просит не встраивать API-ключи и секреты вебхуков в исходный код и клиентские приложения.

Роли и аккаунты

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

Модель данных и миграции

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

Платежи

Принять тестовый платёж легко. Настоящий платёжный сценарий должен ещё справляться с отклонённой картой, с клиентом, который закрыл вкладку до страницы подтверждения, с возвратом и с продлением подписки. Со Stripe это значит обработчик на сервере, который проверяет подпись каждого события, прежде чем что-то пометить как оплаченное. Если прототип ставит поле «оплачено» прямо из браузера, платёжную часть придётся переделать.

Письма

Подтверждения регистрации, сброс пароля и счета должны доходить. С 1 февраля 2024 года Gmail требует от каждого отправителя аутентификации через SPF или DKIM, а тем, кто отправляет больше 5000 писем в день, нужны SPF, DKIM и DMARC. На практике это значит: отправлять со своего домена, через нормального почтового провайдера, с DNS-записями, которыми управляете вы.

GDPR и где хранятся данные

Как только вы храните персональные данные живых людей, GDPR (в Бельгии его называют AVG/RGPD) распространяется на вас, а не на инструмент. С каждым сервисом, который обрабатывает эти данные по вашему поручению (хостинг базы, почтовый провайдер, аналитика), нужен договор об обработке данных по статье 28, а об утечке персональных данных нужно по возможности сообщить надзорному органу в течение 72 часов с момента, когда вы о ней узнали (статья 33). Проверьте, в каком регионе работает ваша база: Supabase размещает каждый проект в одном основном регионе, и в его списке есть регионы ЕС, например Франкфурт, Париж и Ирландия, а рядом Лондон и Цюрих, которые находятся вне ЕС.

Ошибки, тесты и стоимость

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

Магазины приложений, если это мобильное приложение

Если план в том, чтобы обернуть веб-приложение и выложить в App Store, сначала прочитайте правило 4.2 Apple: приложение должно быть чем-то большим, чем переупакованный сайт. Оба магазина также требуют, чтобы приложение, в котором можно создать аккаунт, позволяло его и удалить: внутри приложения на iOS, а в Google Play в приложении и по веб-ссылке.

На кого оформлены аккаунты

Составьте список всех аккаунтов, от которых зависит продукт: конструктор, репозиторий на GitHub, база данных, домен, Stripe, почтовый провайдер, аккаунты разработчика в Apple и Google. Каждый должен быть оформлен на вашу компанию, а владельцем должен быть указан ваш e-mail. Код здесь только часть дела. В FAQ Lovable сказано, что экспорт базы не включает сохранённые файлы, код Edge Functions и секреты, а в руководстве по хостингу сказано, что перенос одной только базы не переносит аутентификацию, хранилище, realtime и Edge Functions. Если когда-нибудь будете переезжать, планируйте их отдельно. Подробнее о том, кому принадлежат код и доступы, мы писали в статье «Кому принадлежит ваш сайт».

Оставить или переписать?

Прототип, скорее всего, стоит оставить, если:

код лежит в Git-репозитории, которым управляете вы, и у него читаемая история;
RLS (или аналогичная проверка на сервере) включена на каждой таблице, и правила соответствуют тому, кто что должен видеть;
у базы есть файлы миграций и структура, которую вы можете объяснить;
в коде, который выполняется в браузере, нет секретных ключей;
в нём уже есть нужные роли, или их добавление затрагивает небольшую часть.

Переписать обычно дешевле, если:

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

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

Как проходит передача проекта студии

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

Мы делаем и то и другое. Наш MVP веб-приложения стоит 14 000 € без НДС (в Бельгии BTW/TVA), срок 8–10 недель: один основной сценарий, аккаунты и аутентификация, простая админка, одна интеграция или способ оплаты, тесты на критичных сценариях, запуск в продакшен, мониторинг и документация, а репозиторий и аккаунты оформлены на вас. Сначала веб: нативные приложения для iOS и Android, дополнительные интеграции, дополнительные языки и перенос данных идут отдельными опциями с фиксированной ценой, которую мы называем до начала работ. Полный список на странице MVP и на странице цен.

Мы также берём проекты, которые начинали другие разработчики. В Getizy мы приняли существующее приложение для iOS и Android от предыдущей компании-разработчика, исправили доставшиеся баги и технический долг и продолжали выпускать новые функции в оба магазина. Работа с чужим кодом начинается у нас с платного ревью, пакета Product Decision Sprint (2 500 €, 5 рабочих дней), стоимость которого полностью засчитывается в разработку, если она начинается в течение 30 дней. Фиксированная цена появляется после ревью, по тому, что на самом деле лежит в репозитории.