Сдача проекта — момент, когда студия либо закрепляет доверие клиента, либо закладывает конфликт на год вперёд. Знакомая картина: код лежит в аккаунте фрилансера, домен оформлен на студию, пароли разбросаны по переписке, и клиент не может ничего поменять без исполнителя. Ниже — чек-лист передачи со стороны студии: репозиторий, права, состав передачи, инструкция для следующего разработчика, данные, акт и поддержка.
Почему код должен сразу жить в репозитории клиента
Репозиторий клиента нужен с первого дня работы, а не в день сдачи. Причины практические:
- Клиент платит за актив. Пока код лежит у вас, клиент владеет им только на бумаге, и он это понимает.
- Меньше споров об оплате. Клиент видит промежуточные версии в своём репозитории, а не получает архив в последний день.
- Вы не храните чужое. Не нужно годами держать проекты бывших клиентов и отвечать за доступы к ним.
- Повторные заказы. Клиент, которому отдали всё без торга, возвращается с новыми задачами охотнее, чем тот, кто выпрашивал пароли.
Как выглядит ситуация с другой стороны, когда исполнитель пропал вместе с доступами, описано в материале для заказчиков, у которых пропал подрядчик. Его полезно прочитать глазами клиента.
Если проект собран в Roboweb, выгрузка кода даёт архив с проектом на Next.js + Prisma + PostgreSQL. Его содержимое размещается в репозитории клиента обычными средствами git — на GitFlic, GitHub или внутреннем сервере компании. Прямая выгрузка в GitHub из кабинета для передачи не подходит: она создаёт новый публичный репозиторий в аккаунте GitHub, подключённом к кабинету студии, а не приватный репозиторий в организации клиента. Экспорт доступен на платных тарифах и расходует энергию, поэтому заложите его в смету, особенно если выгрузок будет несколько. Как учитывать такие расходы в фиксированной цене, мы разбирали в статье о фикс-цене для клиента.
Подготовка: аккаунт клиента на GitHub или GitFlic и права доступа
Площадку выбирает клиент — с учётом того, где его компании удобнее и надёжнее хранить код. Аргументы за и против собраны в статье GitFlic или GitHub. Дальше порядок одинаковый:
- Аккаунт или организацию создаёт клиент — на корпоративную почту, а не на личную почту сотрудника и не на вашу.
- Владелец — сотрудник клиента с включённой двухфакторной аутентификацией, если площадка её поддерживает.
- Студию приглашают участником с правом записи в конкретный репозиторий, а не владельцем организации.
- Репозиторий приватный, если клиент сознательно не решил иначе.
- После сдачи права студии понижаются до чтения или отзываются полностью — это фиксируется в акте.
Сравните два подхода:
- Плохо: «Создадим репозиторий у себя, а в конце передадим». Конец проекта часто размыт, и «в конце» не наступает.
- Хорошо: «Репозиторий в организации клиента с первого дня; у клиента права владельца, у студии — участника».
Что входит в передачу: код, схема базы, переменные окружения, домен
| Что передаём | Где находится | Чьё после сдачи |
|---|---|---|
| Исходный код | Репозиторий клиента | Клиента |
| Схема базы | prisma/schema.prisma | Клиента |
| Список переменных | .env.example | Клиента |
| Значения секретов | Менеджер паролей клиента | Клиента |
| База PostgreSQL | Хостинг клиента | Клиента |
| Домен | Кабинет регистратора | Клиента |
| Заявки | Файл CSV | Клиента |
Пояснения к строкам, в которых чаще всего ошибаются:
- Код. В выгрузке фронтенд, серверная часть, аккаунты посетителей и серверные функции. Что где лежит, подробно описано в разборе структуры экспорта на Next.js + Prisma.
- Схема базы. Разворачивается скриптом db:push, миграций в комплекте нет. Скажите об этом клиенту прямо: менять схему на живой базе без плана нельзя.
- Переменные окружения. В .env.example указан DATABASE_URL. Реальные значения в репозиторий не попадают и не пересылаются в чатах и почте — только через менеджер паролей или другой защищённый канал.
- Домен. Оформлен на клиента. Если когда-то регистрировали его на себя «для скорости», переоформите до сдачи. Подключение своего домена к проекту доступно на платных тарифах.
- Хостинг и база. Если после выгрузки продукт переезжает на инфраструктуру клиента, аккаунты оформляются на клиента, а оплата идёт с его реквизитов.
Короткая инструкция для следующего разработчика
В README выгрузки уже описаны запуск и ограничения. Добавьте к нему раздел о передаче — на одну-две страницы:
- Запуск: установить зависимости, задать DATABASE_URL, выполнить db:push, запустить dev; для сборки — build и start.
- Где работает продукт: хостинг, база, домен и на кого они оформлены.
- Ограничения каркаса: поля моделей в схеме строковые, типы и связи нужно уточнить; безопасность стартовая — нужны HTTPS, доверенный обратный прокси и периодическая чистка просроченных сессий; один экспорт — одна база данных.
- Устройство интерфейса: разметка хранится в app/_site.ts, формы, каталог, кабинет и корзину оживляет public/rw-export.js. Компонентов React по экранам в выгрузке нет: если они нужны, разметку на них раскладывает разработчик.
- Что меняли руками после выгрузки — список файлов и причин, чтобы новая выгрузка не затёрла доработки.
- Контакты: кто у клиента принимает решения по продукту.
Если инструкция не помещается в две страницы, это сигнал, что проект пока не готов к передаче.
Заявки и данные: выгрузка и передача ответственности
Данные — самая чувствительная часть сдачи.
- Заявки. Разберите статусы в разделе «Заявки с проектов» — новые, обработанные, отклонённые — и выгрузите их в CSV. Файл передаётся тем же защищённым каналом, что и секреты.
- Куда пойдут новые заявки. Заявки приходят туда, где живёт проект. Если после сдачи он продолжает публиковаться из кабинета студии, обращения клиентов будут приходить вам. Договоритесь заранее, где проект живёт дальше.
- Тестовые данные. Уберите из базы проекта тестовые аккаунты и записи, а тестовые заявки в кабинете отметьте отклонёнными, чтобы клиент не путал их с настоящими.
- Ответственность. После передачи данными распоряжается клиент. Копии на стороне студии удаляются в согласованный срок, а факт удаления фиксируется в акте. Если студия работала с персональными данными по поручению клиента, условия такого поручения по 152-ФЗ нужно закрепить в договоре, а правовые детали согласовать с юристом клиента.
Хорошая сдача — та, после которой клиент может обойтись без вас. Именно поэтому он чаще возвращается.
Акт приёмки и условия поддержки после сдачи
В акт стоит включить:
- адрес репозитория и отметку сданной версии — тег или коммит;
- перечень переданных доступов с подтверждением, что владелец — клиент;
- на кого оформлены домен, хостинг и база;
- передачу файла с заявками и удаление копий у студии;
- понижение или отзыв прав студии в репозитории;
- известные ограничения каркаса, о которых клиент предупреждён.
Условия поддержки фиксируйте отдельно от сдачи:
- Срок бесплатного исправления ошибок в сданной версии.
- Граница между ошибкой и новой задачей: «форма не отправляется» — ошибка, «добавьте поле» — новая задача.
- Срок реакции на обращения — прописывается в договоре.
- Стоимость доработок: почасово или фиксированными пакетами.
- Изменения третьих лиц: поддержка распространяется на сданную версию; правки другого разработчика оцениваются отдельно.
Следующий шаг: превратите этот чек-лист в приложение к договору и шаблон акта. Пройдите его на текущем проекте до финального платежа — пропущенные пункты проще закрыть сейчас, чем через полгода по звонку клиента.
