23 проверки перед первым платежом в вайб-кодинг приложении
23 проверки перед первым платежом в вайб-кодинг приложении Вайб-кодинг позволяет собрать приложение быстро, но первый реальный платеж — это момент, когда всплывают все недоделки. Перед запуском стоит прогнать проект по чек-листу из 23 пунктов. Начнем с внешнего вида и удобства: • Единая дизайн-система, которой подчиняются все цвета, шрифты и отступы. • Отдельные экраны для загрузки, пустых данных и ошибок. • Картинки в WebP или AVIF, а контент ниже экрана подгружается по мере прокрутки. Безопасность — отдельная головная боль. Приватные ключи должны жить только на сервере, а фронтенд и история Git — проверены на утечки. Все когда-либо засветившиеся ключи меняются. Каждый API-эндпоинт обязан проверять авторизацию и права на сервере, а в базе включается RLS. Для сервисов с оплатой по факту использования — ИИ, SMS, почты — нужны лимиты расходов или хотя бы уведомления. Платежи требуют особой аккуратности: • Вебхуки проверяют подпись, а повторное уведомление об одном платеже не создает второй. • Возвраты, отмены и неудачные списания тестируются в тестовом режиме и завершаются правильным статусом. • После окончания пробного периода доступ отзывается вовремя. • При переходе из тестового режима в рабочий заново настраиваются ключи и секрет подписи вебхуков. • Суммы хранятся целыми числами в минимальных единицах валюты, как в Stripe. В JavaScript 0.1 + 0.2 не равно 0.3 — с плавающей точкой шутить нельзя. • Двойное нажатие кнопки отправки создает только один заказ. • Налог с продаж или НДС настроен для стран продаж. С данными тоже есть о чем подумать. Нужно ежедневное автоматическое резервное копирование: на бесплатном тарифе Supabase его нет, так что придется перейти на Pro или настроить свои дампы. Восстановление проверяется один раз в новой базе. Для каждой миграции схемы готовится SQL для отката, а сама миграция и откат проверяются на копии продакшен-данных. Списки длиннее 1000 записей не должны незаметно обрезаться — Supabase по умолчанию отдает максимум 1000 строк. Время хранится в timestamptz, а часовой пояс пользователя — в отдельном столбце, чтобы напоминания приходили по местному времени. Сначала используется мягкое удаление, причем RLS скрывает и удаленные записи, а при удалении аккаунта данные стираются окончательно. Пользователи должны уметь экспортировать свои данные. Имена с апострофами, эмодзи или текстом справа налево не должны ломать поля ввода. Для полей, по которым чаще всего фильтруют, нужны индексы: на десятках тестовых записей все летает, а на реальных объемах начинаются замедления. И последнее — мониторинг ошибок, чтобы о проблемах вы узнавали первыми. Весь список можно отправить агенту вместе с промптом: он распределит проверку между пятью субагентами по направлениям — дизайн и производительность, безопасность, платежи, данные и работа после запуска. По каждому пункту агент укажет, пройдена проверка или нет, и файл с проблемой. Если что-то проверяется только через панель управления сервиса, агент поставит статус "Требуется мое подтверждение" и даст пошаговую инструкцию. Резервное копирование и восстановление тестируются только на тестовой базе, платежи — исключительно в тестовом режиме. Продакшен-данные трогать нельзя. Сначала агент показывает таблицу с результатами и ничего не исправляет до подтверждения.