Чтобы довести продукт, собранный с помощью ИИ, до реальных клиентов, сначала нужно проверить один полный сценарий: от входа пользователя до сохранённого результата и его последующей обработки. Затем устранить проблемы в данных, доступе и интеграциях, подготовить выпуск и способ восстановления. Сам факт использования ИИ не означает, что продукт нужно переписывать.
Lovable, другой конструктор или агент в редакторе могли помочь вам уточнить предложение и собрать полезную основу. Теперь вопрос меняется: какие части уже можно использовать, что известно только по демонстрации и какие ошибки недопустимы при работе с клиентами. Это разбор существующего продукта — общий вопрос о создании продукта полностью с ИИ решается на более раннем этапе.
Сохраните то, что уже решает задачу
До новых запросов агенту зафиксируйте текущую версию: исходный код, структуру данных, настройки окружения и список подключённых сервисов. Отдельно запишите, какие экраны работают с настоящими данными, где используются примеры и какие действия пока имитируются. Это позволяет оценить объём доработки без потери уже сделанного.
Интерфейс, формулировки предложения и понятный маршрут пользователя могут быть пригодны для первой версии. Проблема в доступе к одной таблице не доказывает, что нужно заменить весь стек. Решение о переработке должно опираться на конкретное препятствие: например, текущая модель данных не позволяет разделить клиентов разных организаций. Критерии такого выбора разобраны в статье об улучшении продукта и переписывании с нуля.
Пройдите ключевой сценарий за пределами демонстрации
Предположим, вы собрали сервис записи на консультацию: посетитель выбирает время, оставляет контакты и видит подтверждение, а сотрудник получает новую запись. Это условный пример. Рабочим результатом здесь является сохранённая запись в доступное время, которую сотрудник может обработать, а клиент — найти при следующем входе.
Проверять его полезно с новой учётной записью и в условиях, близких к клиентским. Повторите путь после обновления страницы и выхода из аккаунта. Затем пройдите варианты, которых обычно нет в демонстрации:
- Два клиента одновременно выбирают одно и то же время.
- Пользователь нажимает подтверждение несколько раз.
- Соединение пропадает во время сохранения записи.
- Клиент возвращается после перерыва с истёкшей сессией.
- Сотрудник переносит или отменяет уже созданную запись.
Для каждого варианта заранее определите правильный результат. Например, повторное нажатие не должно создавать вторую запись, а отсутствие свободного времени должно давать понятный ответ. Если желаемое поведение ещё не выбрано, это вопрос к владельцу продукта, который нельзя закрыть одним исправлением кода.
Проверьте правила данных и доступа
Проверка в интерфейсе должна подкрепляться правилами системы
Отключённая кнопка и проверка поля в браузере помогают пользователю. Критичные условия — доступное время, допустимое действие и право его выполнить — должны проверяться там, где сохраняются данные. Иначе изменённый запрос может обойти интерфейс. В рекомендациях Lovable отдельно описаны серверная проверка входных данных и разделение обязанностей между браузером, сервером и базой.
В примере с записью проверка свободного времени и его занятие должны быть согласованы: два одновременных запроса не должны оба получить один слот. Как именно это реализовать, зависит от хранения данных. На приёмке важен воспроизводимый результат, а не название выбранного технического механизма.
Проверьте доступ с разных учётных записей
В тестовом окружении создайте двух клиентов и сотрудника. Клиент должен видеть свои записи и не получать чужие при обращении к данным напрямую. Сотруднику нужны только права, соответствующие его работе. Скрытие раздела меню не заменяет ограничение доступа к данным.
Если используется Supabase, правила доступа к отдельным строкам задаются через RLS. Привилегированный серверный доступ может обходить эти правила, поэтому серверным операциям тоже нужна проверка полномочий. Документация Supabase объясняет это различие. Готовая авторизация не подтверждает правильность всех правил доступа вашего продукта.
Отделите секретные ключи от публичного приложения
Секретные ключи платёжного провайдера, почты или ИИ-сервиса должны храниться в защищённой конфигурации и использоваться серверной частью. Проверяют также ответы API и журналы: секрет не должен попадать туда случайно. Не всякий ключ является секретным — назначение публичных идентификаторов и ключей определяют по документации провайдера.
Серверное разделение можно увидеть в нашем кейсе интеграции генерации изображений OpenAI: работа с провайдером, проверками и ограничениями вынесена за пределы браузера. Для доработки вашего продукта нужен такой же разбор границ, с учётом его конкретных интеграций.
Подтвердите оплату и обработку внешних событий
Успешная оплата должна отражаться в состоянии заказа
Если консультация требует предоплаты, одного экрана «Оплачено» недостаточно для учёта. Нужно связать заказ, подтверждённый платёж и доступное клиенту действие. Посетитель может оплатить и закрыть вкладку до возвращения на сайт. Например, Stripe рекомендует подтверждать выполнение заказа через серверные уведомления, а не полагаться только на страницу после оплаты.
Проверьте успешную оплату, отказ, отмену и задержку подтверждения для выбранного способа оплаты. Условие изменения статуса должно быть явным. Если онлайн-оплаты в первой версии нет, этот участок не нужно разрабатывать заранее: достаточно определить, как сотрудник отмечает расчёт и что видит клиент.
Повторное уведомление не должно повторять действие
Внешний сервис может доставить одно событие несколько раз. Обработчик должен проверять подлинность сообщения и учитывать уже выполненное действие. В документации Stripe о webhook описаны проверка подписи и повторная доставка. Правило применяют так, чтобы повтор не создавал новую запись и не выдавал доступ второй раз.
Отдельно решите, что происходит при недоступной почте или CRM. Сохранённая запись должна оставаться видимой сотруднику, а сбой уведомления — обнаруживаться. Там, где повтор может создать дубль во внешней системе, перед ним нужно выяснить результат первого запроса. Безусловный повтор всей операции способен увеличить проблему.
Подготовьте выпуск, наблюдение и восстановление
Тестовое приложение и клиентская версия должны иметь понятные границы: адреса, настройки, данные и доступы. Перед выпуском проверяют регистрацию, письма, интеграции и основной сценарий именно в целевом окружении. Возможности резервного копирования и ограничения выбранного тарифа также требуют проверки; например, они входят в список готовности Supabase к эксплуатации.
Зафиксируйте порядок повторного выпуска и восстановления. Возврат предыдущего кода не обязательно возвращает прежнюю структуру базы: изменения данных нужно учитывать отдельно. Для важного хранения проверьте восстановление резервной копии в отдельном окружении. Наличие файла копии ещё не показывает, что из него удастся вернуть рабочий сервис.
После запуска нужен человек, который узнает о пропавших записях или сбое оплаты. Определите наблюдаемые события, уведомления об ошибках и способ связать проблему с конкретной операцией. Полные сообщения клиента и секретные значения не нужно копировать в журналы ради диагностики.
Используйте встроенные проверки выбранной платформы. В Lovable есть Quick scan, запускаемый при публикации, и более подробный Deep scan. Эти инструменты помогают находить проблемы, но сама документация не считает их заменой полной проверки безопасности. Прохождение сканирования также не подтверждает, что два клиента не получат одно время или сотрудник увидит пропущенное обращение.
Соберите результаты в понятную таблицу готовности
Отметка «готово» требует результата проверки. «Требует проверки» означает, что доказательства пока нет, а «блокирует запуск» — обнаруженную проблему, недопустимую для выбранного сценария. Ниже — шаблон для сервиса записи, а не отчёт о конкретном клиентском приложении. Состав проверок нужно адаптировать к вашему продукту.
| Что проверить | Готово | Требует проверки | Блокирует запуск |
|---|---|---|---|
| Основной сценарий | Клиент и сотрудник получают нужный результат. | Проверена только демонстрация владельца. | Запись теряется или не доходит до обработки. |
| Сохранение данных | Результат сохраняется после повторного входа. | Неизвестно, где находятся реальные данные. | Основной результат существует только в браузере. |
| Доступ | Роли видят и меняют только разрешённое. | Разные роли отдельно не проверялись. | Клиент получает чужие приватные данные. |
| Повторы и одновременность | Один слот и одно действие обрабатываются согласованно. | Был только одиночный успешный запрос. | Возникают двойные записи или повторная выдача. |
| Оплата, если нужна | Статус связан с подтверждением провайдера. | Проверена только тестовая кнопка. | Доступ выдаётся без подтверждения оплаты. |
| Внешние сервисы | Сбои обнаруживаются, повторы контролируются. | Проверялся только доступный сервис. | Сбой незаметно уничтожает результат клиента. |
| Выпуск и восстановление | Есть проверенный порядок выпуска и восстановления. | Копии и процедура есть, но не проверены. | Нужные данные нельзя восстановить выбранным способом. |
Неизвестность в критичной строке тоже требует решения до запуска. Можно завершить проверку, убрать непроверенную функцию из первого выпуска или ограничить запуск сценарием, который уже подтверждён. Пометка «доработаем потом» не объясняет, что произойдёт с клиентом при ошибке.
Закажите первый этап доработки с проверяемым результатом
Полезное задание специалисту начинается с адреса прототипа, кода, описания ролей и одного главного сценария. Доступы передают защищённым способом; секреты не вставляют в публичное описание задачи. Добавьте известные сбои, используемые сервисы и критерий готовности первого выпуска.
Для условного сервиса первым этапом может стать надёжная запись: сохранение, защита от двойного занятия времени, разграничение доступа и видимый сотруднику результат. Платежи включают в этот этап, если без них клиентский сценарий не завершён. Редизайн, новые разделы и дополнительные каналы выбирают после устранения препятствий к основному результату.
До начала изменений согласуйте границы работ, способ приёмки и порядок выпуска. Если фактическая бизнес-логика ещё отсутствует и есть только демонстрация экранов, объём может соответствовать разработке первой версии продукта. Если основа уже работает, услуга улучшения продукта позволяет выбрать и реализовать ограниченный этап доработки. Такой порядок соответствует разработке с ИИ под ответственностью специалиста.
Перед первыми клиентами нужен подтверждённый путь от их действия до устойчивого результата. Таблица готовности помогает отделить работающую основу от неизвестного и заказать ровно те изменения, без которых этот путь пока не завершён.
Практический порядок решения
- Сохраните текущую версию и отметьте имитируемое поведение.
- Проверьте один клиентский сценарий при успехе и сбоях.
- Зафиксируйте доказательства, неизвестное и препятствия к запуску.
- Согласуйте и проверьте один завершённый этап до выпуска.
Источники и методология
Для проверки фактов и технических деталей использованы следующие материалы:
- Lovable: серверная проверка, доступ и защита секретов
- Lovable: встроенные проверки безопасности и их границы
- Supabase: правила доступа к строкам и привилегированные ключи
- Stripe: подтверждение оплаты и выполнение заказа
- Stripe: подлинность уведомлений и повторная доставка
- Supabase: подготовка к эксплуатации
Подготовьте собранный продукт к реальным клиентам
Разберём ключевой сценарий, определим приоритеты и согласуем первый этап доработки с проверяемым результатом.
Обсудить доработку прототипа