От прототипа до продакшена: чек-лист
Прототип отвечает на вопрос «нужно ли это кому-то». Продакшен отвечает на другие: что будет, когда пользователей станет сто, когда кто-то попробует прочитать чужие данные, когда упадёт оплата и когда сломается то, что работало вчера.
Кратко
Пятнадцать пунктов разбиты на три группы. До первого настоящего пользователя: код в вашем репозитории, секреты на сервере, доступ к данным проверяет сервер, рабочая база отделена от тестовой, резервная копия восстанавливается. В первый месяц: ошибки видны раньше, чем о них напишет клиент, изменения схемы базы версионируются, у платёжных уведомлений проверяется подпись, расходы на AI ограничены. По мере роста: нагрузка, зависимости, документация и человек, который знает систему. Всё, что в первой группе не сделано, лучше закрыть до запуска, а не после.
До первого настоящего пользователя
| # | Пункт | Как проверить |
|---|
| 1 | Код лежит в вашем репозитории, а не только внутри платформы | Есть GitHub или другой репозиторий на ваше имя, и из него собирается та же версия, что работает на сайте |
| 2 | Секретов нет в коде браузера | F12, поиск по key, secret, token. Найденное, кроме публичного ключа Supabase, перенести на сервер и отозвать |
| 3 | Доступ к данным проверяет сервер | Второй пользователь пытается открыть чужую запись, подменив номер в адресе. В Supabase для каждой таблицы включён RLS. |
| 4 | Рабочая база отдельно от тестовой | Эксперименты и тестовые данные не попадают в базу, где живут клиенты |
| 5 | Резервная копия восстанавливается | Не «копии делаются», а копию один раз реально восстановили и проверили данные |
Пункт 5 проверяют реже всего. Резервная копия, которую ни разу не восстанавливали, это предположение, а не копия.
В первый месяц
| # | Пункт | Как проверить |
|---|
| 6 | Об ошибках вы узнаёте раньше клиента | Подключён сбор ошибок, например Sentry, и уведомления приходят живому человеку |
| 7 | Изменения схемы базы версионируются | Каждое изменение таблиц хранится в репозитории как файл миграции, а не вносится руками через консоль рабочей базы |
| 8 | Платёжные уведомления проверены | У webhook проверяется подпись платёжной системы, повторное уведомление не создаёт второй платёж |
| 9 | Расходы на AI ограничены | Если приложение вызывает модели: лимит на пользователя, общий бюджет и уведомление при его превышении |
| 10 | Почта доходит | У домена настроены SPF и DKIM, письма о регистрации и сбросе пароля не уходят в спам |
По мере роста
| # | Пункт | Как проверить |
|---|
| 11 | Защита от злоупотреблений | Ограничение частоты на регистрацию, вход и дорогие операции |
| 12 | Нагрузка | Самые частые запросы к базе используют индексы, список не загружает всю таблицу |
| 13 | Зависимости | Каждый пакет существует и поддерживается, файл блокировки версий лежит в репозитории, известные уязвимости закрыты |
| 14 | Закон и приватность | Политика приватности соответствует тому, что система реально собирает; для Израиля это требования Тиккуна 13 |
| 15 | Человек, который знает систему | Кто-то, кроме AI-ассистента, может объяснить, как устроена система и как ночью выкатить исправление |
Почему именно в таком порядке
Первая группа отличается тем, что ошибку в ней нельзя исправить задним числом. Утёкший ключ уже утёк. Прочитанные чужие данные уже прочитаны. Потерянную базу без проверенной копии не вернуть. Всё остальное неприятно, но исправимо после запуска.
Вторая группа становится срочной вместе с деньгами и пользователями: пока платежей нет, пункт 8 не горит, но первый двойной платёж обходится дороже, чем его проверка.
Третья группа о том, чтобы система пережила своего автора. Пункт 15 в AI-проектах самый недооценённый: код написан быстро, и часто никто, включая владельца, не может объяснить, почему он устроен именно так.
Если пунктов не хватает
Это нормально: прототип и не должен был всё это иметь. Вопрос в том, что делать дальше. Обычно ответ один из трёх: закрыть пробелы в существующем коде, переписать отдельные части или, реже, переписать систему на той же модели данных. Какой из трёх, становится видно после проверки, а не до неё.
Частые вопросы
Можно ли запускать в продакшен приложение из Lovable или Bolt?
Да, если выполнены пункты первой группы: код в вашем репозитории, секреты на сервере, доступ проверяет сервер, рабочая база отделена, резервная копия проверена. Платформа не мешает продакшену, но и не делает его за вас.
Что самое опасное в AI-прототипе перед запуском?
Проверка прав только на уровне интерфейса. Приложение выглядит правильно, но сервер выполняет запросы любого пользователя к любым данным. В демо этого не видно, это проявляется только при целенаправленной попытке.
Нужно ли переписывать прототип с нуля?
Чаще всего нет. Большинство пунктов чек-листа закрываются в существующем коде. Переписывание оправдано, когда модель данных не подходит задаче или когда исправления обходятся дороже новой версии.
Сколько времени занимает подготовка к продакшену?
Зависит от того, сколько пунктов не выполнено и сколько таблиц и мест, где сервер доверяет интерфейсу. После проверки по этому списку срок известен по пунктам.
Что делать, если приложение уже работает с клиентами?
Начать с пунктов 2, 3 и 5, именно в этом порядке: секреты, доступ, резервная копия. Они закрывают то, что нельзя исправить задним числом.
SLAtech LTD