# Чеклист перед запуском приложения, написанного с ИИ

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

Published: 2025-02-06 · Source: https://subxcat.com/ru/articles/vibe-code-launch-checklist · Author: SUBXCAT

Приложение, собранное в Lovable, Bolt, Replit или Cursor, на демо обычно выглядит готовым. Кнопки нажимаются, данные сохраняются, оплата проходит. Проблемы начинаются, когда приходят люди, которые не знают, как «правильно» им пользоваться, и пара человек, которые знают, как неправильно.

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

## Секреты в клиентском бандле

ИИ охотно кладёт ключ туда, где он сработает быстрее всего, — то есть в код, который уезжает в браузер. Всё, что попало в бандл, публично: открыть DevTools умеет любой.

Как проверить: собери продакшн-сборку и поищи по ней строки вроде `sk_`, `secret`, `service_role`, `api_key`. Посмотри вкладку Network: не ходит ли браузер напрямую в OpenAI, Stripe или в базу с ключом в заголовке.

Признак поломки: в клиенте есть хоть один ключ, который даёт больше, чем доступ на чтение публичных данных. Публичный ключ Supabase (`anon`) в клиенте — норма. Ключ `service_role` — нет, он обходит все правила доступа.

## Проверки доступа на сервере

Самая частая дыра — данные защищены только интерфейсом. Кнопки «чужой заказ» нет, но запрос на `/orders/123` с чужим номером отдаёт заказ. В Supabase это выглядит как таблица без Row Level Security или с политикой `using (true)`.

Как проверить: заведи два аккаунта. Из-под первого создай запись, скопируй её идентификатор, войди вторым и запроси её напрямую — через curl или консоль браузера. Попробуй не только прочитать, но и изменить и удалить.

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

## Валидация входных данных

Форма не даёт ввести отрицательное количество, а API принимает. Поле «имя» ограничено 50 символами в интерфейсе и мегабайтом на сервере. Цена товара приходит из браузера, и сервер ей верит.

Как проверить: отправь запрос в обход формы — с пустыми полями, лишними полями, огромными строками, отрицательными числами, чужим `user_id` в теле.

Признак поломки: сервер сохраняет то, что форма бы не пропустила, или берёт из запроса то, что должен считать сам (цену, роль, владельца записи).

## Лимиты частоты запросов

Без лимитов один скрипт может отправить тысячу писем со сброса пароля, перебрать коды из SMS или сжечь месячный бюджет на ИИ за ночь.

Как проверить: отправь сотню одинаковых запросов на вход, регистрацию, отправку кода и любой эндпоинт, который вызывает платный API.

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

## Бэкапы и учения по восстановлению

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

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

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

## Логи и алерты об ошибках

Если об ошибках ты узнаёшь от пользователей, ты узнаёшь о малой их части: большинство просто уходит.

Как проверить: специально сломай что-нибудь на стейджинге — брось исключение в обработчике — и посмотри, придёт ли уведомление и сколько времени это займёт.

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

## Идемпотентность вебхуков оплаты

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

Как проверить: отправь один и тот же вебхук дважды (у Stripe и подобных есть тестовые инструменты для этого). Проверь подпись: прими вебхук с неверной подписью — должен быть отказ.

Признак поломки: двойное начисление или успешная обработка без проверки подписи. Минимальная защита — хранить идентификатор события и не обрабатывать его повторно:

```sql
create unique index on payment_events (provider_event_id);
```

## Разделение окружений

Тестовые заказы в боевой базе, письма реальным людям со стейджинга, один ключ API на всё — классика проекта, выросшего из одного окружения.

Как проверить: у разработки, стейджинга и продакшна должны быть разные базы, разные ключи платёжной системы (тестовые и боевые), разные почтовые настройки. Посмотри, откуда приложение берёт конфигурацию и что будет, если запустить его локально.

Признак поломки: локальный запуск пишет в боевую базу или может отправить настоящее письмо и провести настоящий платёж.

## Что дальше

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

SUBXCAT проходит этот список вместе с командой, чинит найденное и оставляет проверки, которые не дают ему сломаться снова.