Сначала информация, а не доступ
Понятное описание сценария работы, того, кто пользователи, и того, какие данные должны сохраняться, — именно это определяет реальные архитектурные решения и важнее любых учётных данных на старте.
Какой доступ обычно нужен
- Доступ к хостингу/деплою для той среды, где будет работать приложение
- API-ключи для любых сторонних систем, которые подключаются, — см. [Integrations](/ru/integrations/)
- Тестовый или staging-аккаунт для любой подключаемой CRM/инструмента, если он есть
Что НЕ нужно по умолчанию
Доступ к финансовым/биллинговым системам, не связанным с проектом, или админ-доступ шире, чем требует конкретная интеграция, — см. What Access Does an AI Automation Agency Need (на английском), тот же принцип применительно к стороне ИИ-агентов бизнеса.
Кому что принадлежит после
Код, инфраструктурные аккаунты и данные остаются вашими — ничего не строится в аккаунте, независимом от вас. О том, как это настроить, см. GitHub and Vercel account ownership setup (на английском) и staging vs production environments (на английском). Если вы принимаете приложение от разработчика, который ушёл, начните с taking over an existing web app (на английском).
Два аккаунта, о которых часто забывают: домен и DNS (чек-лист, на английском) и аналитика (владение аналитикой и тег-менеджером, на английском).
Частые вопросы
Нужны ли вам учётные данные от продакшн-базы данных с первого дня?+
Обычно нет — во время разработки используется staging/тестовая среда, а доступ к продакшену запрашивается ближе к запуску.
Что если у нас нет чистой документации текущего процесса?+
Это нормально — исследование на этапе разговора о скоупе продукта как раз и предназначено для того, чтобы выявить и задокументировать это, а не предполагать, что оно уже существует.
Кому принадлежит код после разработки?+
Вам — кодовая база и инфраструктурные аккаунты остаются под вашим контролем.
Сайт и форма заявки — на русском, проект ведётся на английском. Русский как язык проекта мы не обещаем.