Bolt.new помогает начать веб-проект через описание задачи и итерации с preview. Но опубликованная страница, работающий интерфейс и готовый production-сервис — разные состояния. Для формы, входа, хранения данных и платежа нужно выяснить, какие именно backend-механизмы настроены и подтвердить их отдельными проверками.
Собери минимальный вертикальный сценарий
Вместо запроса «сделай сервис бронирования» начни с одного маршрута: показать свободные временные интервалы, выбрать один и увидеть итоговое состояние. Укажи поля, состояния загрузки/ошибки, узкий viewport и то, какие данные пока тестовые. После генерации пройди маршрут в preview, включая пустое состояние и ошибку.
Раздели проект на четыре слоя: экран, поведение браузера, серверный API и хранилище. Для каждого спроси, где находится исходный код, какая среда хранит данные, как читаются секреты и куда уходит запрос формы. Не вставляй реальные ключи в prompt или клиентский код. Если включаешь интеграцию, проверь её официальный механизм и права доступа до передачи данных.
Что подтверждает кнопка Publish
Публикация означает, что платформа выполнила конкретное действие по развёртыванию. Она сама по себе не доказывает, что внешнее письмо доставлено, пользователь может войти с нужной ролью, платёж подтверждён провайдером или данные переживают повторное открытие. Открой production URL в новой сессии, пройди главный сценарий на синтетических данных и проверь фактические сетевые ответы/записи там, где у тебя есть безопасный доступ.
Для реального платёжного сценария нужен серверный checkout и подтверждение статуса от платёжного провайдера; возврат браузера на страницу «спасибо» не является подтверждением покупки. До этого показывай прототип как прототип и не собирай реальные платёжные реквизиты.
Сохрани путь назад
Проверь, можно ли связать проект с Git-репозиторием и какие файлы меняются после синхронизации. Прочитай diff перед merge. Сохрани известную рабочую версию, а секретные переменные добавляй через предназначенное хранилище, не коммитом. Для каждого изменения веди короткий список: цель, проверенный сценарий, оставшееся ограничение.
У Bolt есть официальные intro и quickstart; их следует перечитывать для актуальных кнопок и доступных сервисов. Не переноси из документации переменные квоты/лимиты в постоянную инструкцию: проверь их отдельно перед использованием. Ни один пример в этой статье не запускался в Bolt-аккаунте.
Источники: Bolt — обзор, первое приложение.
Тестируй после каждой смысловой итерации
Не складывай пять изменений в один prompt. Меняй сначала модель экрана, затем поведение фильтра, затем интеграцию данных. После каждого шага проверь созданные файлы и пройди сценарий заново. Если после второй итерации UI выглядит правильно, но фильтр продолжает менять только визуальный label, уточни, где находится реальный набор данных и какой код применяет фильтр.
Для задачи со сторонним сервисом задай безопасный этап: mock response в dev, затем sandbox credentials в защищённом серверном хранилище. Подтверди, что значения секрета не появляются в браузерном DevTools, HTML или исходниках. Проверь серверную ошибку и таймаут, а не только happy path. При обновлении схемы создай тестовые данные заново, чтобы migration была воспроизводима.
Перед публикацией сравни preview URL и production URL: какая версия кода развернута, какие переменные установлены и куда ведут ссылки. Публичный адрес может быть доступен, пока основной workflow сломан. Оставь заметку, что именно проверено, например «главная страница и поиск работают с mock data в preview», и что не проверено, например реальная отправка писем. Такая формулировка полезнее общего заявления «готово к запуску». Для проверки responsive и доступности запиши результаты отдельно от интеграции. Например: UI-сценарий фильтра проверен в preview; форма отправляет mock response; account login не подключён; реальное письмо не подтверждено. Такая карта полезна, если передаёшь проект разработчику: человек видит, где заканчивается generated frontend и начинается работа над сервисом.
Обсуди ownership репозитория до того, как появятся значимые правки. Если подключён GitHub, проверь направление синхронизации и ветку перед импортом. Не синхронизируй на production branch каждую итерацию. Создай отдельную branch, добавь короткие commits и удостоверься, что secrets исключены из истории до первой отправки. Составь карту зависимости от hosted сервисов до того, как продукт примет пользовательские данные. Запиши имя поставщика для базы, auth, storage, email и модели; способ экспорта; location и backup; требования к отмене аккаунта. Не включай в таблицу секретные значения. Уточни, кто владелец каждой учётной записи и что происходит, если создатель проекта перестаёт быть участником.
До публичного URL добавь простые защиты: rate limit формы, серверную валидацию, контроль прав и аварийный способ отключить дорогую функцию. Пройди guest и logged-in сценарии; не проверяй доступ только скрытием элемента. При работе с персональными данными проконсультируйся по applicable privacy requirements и не принимай сгенерированные boilerplate policies как юридический документ.
Если приложение остаётся учебным прототипом, подпиши это на самой странице и используй тестовые записи. Это помогает демонстрировать интерфейс без ложного впечатления, будто учетная запись и поддержка уже готовы.