Цифровые сервисы: гид

Акт передачи кода, дизайна и доступов: чек-лист перед финальной оплатой проекта

Автор и проверка: Алексей Воронов, редакционный координатор ormobil.com · Факты, документы, риски и применимость · Обновлено: 01 сентября 2025 г.

Перед финальной оплатой цифрового проекта нужно принять не только «готовый сайт», приложение или личный кабинет, а весь комплект результата: код, дизайн-исходники, доступы, домены, хостинг, репозитории, лицензии,

Критерии выбора: какой акт передачи нужен именно вашему проекту

Акт передачи кода, дизайна и доступов — это не формальность «работы выполнены». Для цифрового сервиса он подтверждает, что заказчик получил управляемый результат: может поддерживать проект, менять подрядчика, переносить инфраструктуру, продлевать домены, выпускать обновления и доказывать права на созданные материалы.

Формат акта зависит от типа проекта:

• для лендинга достаточно передать код, CMS, домен, хостинг, макеты и доступы к аналитике;

• для интернет-магазина нужны еще платежный провайдер, каталог, база заказов, уведомления, интеграции с доставкой и CRM;

• для мобильного приложения критичны аккаунты Apple Developer и Google Play Console, сертификаты, keystore, push-ключи, исходники iOS/Android;

• для SaaS или личного кабинета важны backend, frontend, база данных, API, очереди, cron-задачи, логи, мониторинг, резервные копии и инструкции по деплою.

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

Критерии проверки: что должно быть передано до финальной оплаты

Ниже — базовая таблица проверки для сайта, мобильного приложения, CRM, личного кабинета или другого программного продукта.

| Блок | Что должно быть передано | Как проверить перед оплатой | Красный флаг |

|---|---|---|---|

| Код | Репозиторий, ветки, история коммитов, backend, frontend, мобильные исходники, миграции | У заказчика есть роль owner/admin, проект открывается, зависимости устанавливаются | Передан только ZIP-архив без истории и инструкции |

| Дизайн | Figma-файлы, UI-kit, компоненты, адаптивные версии, иконки, иллюстрации | Файл скопирован в рабочее пространство заказчика, есть право редактирования | Доступ только на просмотр или только PNG/JPG |

| Домены | Аккаунт регистратора, DNS-зона, данные о продлении | Домен оформлен на заказчика или компанию, есть доступ к управлению DNS | Домен зарегистрирован на подрядчика |

| Хостинг и облака | Серверы, панели управления, базы, хранилища, CDN, SSL | Заказчик входит в аккаунт, видит тарифы, роли, счета и ресурсы | Оплата идет с личной карты разработчика |

| Репозиторий и CI/CD | GitHub/GitLab/Bitbucket, pipeline, ключи деплоя, окружения | Можно собрать и задеплоить проект по инструкции | Релиз возможен только с ноутбука конкретного разработчика |

| Базы данных | Доступ, схема, миграции, резервные копии, инструкция восстановления | Есть актуальный backup и тест восстановления | Нет понятной процедуры бэкапа |

| Лицензии | Шрифты, изображения, шаблоны, библиотеки, SDK, плагины | Есть список лицензий, сроков, ограничений и владельцев | Использованы неизвестные материалы «из интернета» |

| Аналитика и маркетинг | Метрики, пиксели, события, email/SMS/push-сервисы | Аккаунты принадлежат заказчику, подрядчик — приглашенный пользователь | Все создано на личную почту подрядчика |

| Документация | README, инструкция запуска, схема окружений, список сервисов | Новый разработчик может поднять проект за 1–2 рабочих дня | Без звонка автору проект не запускается |

| Права | Исключительные права или лицензия на использование результата | Условия совпадают с договором, ТЗ и приложениями | В акте нет слов о передаче прав |

| Поддержка | Гарантийный срок, SLA, порядок исправления ошибок | Критичные баги закрываются за 1 рабочий день, обычные — за 3–5 дней | После оплаты поддержки нет |

Если подрядчик передает только архив с файлами, но не передает репозиторий, доступы администратора, исходники дизайна и права, проект нельзя считать полноценно принятым.

Что изменилось: почему проверка стала жестче

Современные цифровые проекты редко состоят только из файлов на хостинге. Даже небольшой сервис может использовать 10–20 внешних зависимостей: облако, CDN, платежи, карты, SMS, email-рассылку, push-уведомления, аналитику, систему ошибок, no-code-модули, AI-инструменты, конструкторы форм и сторонние API.

Из-за этого финальная приемка в 2026 году должна отвечать не на вопрос «работает ли демо», а на более важные вопросы:

• кто фактически владеет аккаунтами;

• можно ли перенести проект без участия подрядчика;

• не привязан ли продакшн к личной карте, телефону или почте разработчика;

• можно ли выпустить обновление через 3 месяца;

• есть ли документы на платные материалы и библиотеки;

• кто оплачивает сервисы после релиза;

• как быстро исправляются ошибки после запуска.

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

Что включить в акт передачи кода

Фраза «исходный код передан» слишком общая. В акте лучше перечислить конкретные артефакты и ссылки.

Для сайта, веб-сервиса или личного кабинета

Проверьте, что переданы:

• ссылка на репозиторий GitHub, GitLab, Bitbucket или корпоративный Git;

• актуальная ветка production, main, master или release;

• frontend, backend, админ-панель, API, миграции базы данных;

• инструкция по установке и локальному запуску;

• описание тестового, staging- и production-окружения;

• список внешних API, webhooks, cron-задач, очередей и workers;

• инструкция по деплою;

• структура базы данных и миграции;

• резервная копия базы и порядок восстановления;

• список переменных окружения без публикации секретов в открытом виде;

• доступ к логам, мониторингу и системе ошибок.

Практический тест: новый разработчик должен поднять проект по инструкции за 1–2 рабочих дня. Если без личных пояснений автора это невозможно, документация неполная.

Для мобильного приложения

Для iOS и Android дополнительно запросите:

• исходники приложения;

• доступы к Apple Developer и Google Play Console;

• bundle ID и package name;

• сертификаты, provisioning profiles, keystore-файлы;

• push-сертификаты и ключи;

• описание сборки и публикации релиза;

• версии SDK, фреймворков и зависимостей;

• доступ к crash-аналитике;

• тестовые сборки и инструкцию проверки;

• данные по deep links, universal links, push, оплатам и авторизации.

Особенно важно зафиксировать передачу Android keystore. Его потеря может серьезно осложнить выпуск обновлений приложения. В акте стоит отдельно указать, где хранится keystore, кто имеет доступ и как подтверждена возможность сборки.

Что включить в акт передачи дизайна

Дизайн — это не набор картинок для согласования, а рабочая основа для будущих доработок. Если переданы только PNG или PDF, новый дизайнер не сможет нормально развивать интерфейс.

В акте укажите:

• ссылку на Figma, Sketch, Adobe XD или другой исходный файл;

• права доступа: владелец, редактор, просмотр;

• факт передачи файла в рабочее пространство заказчика;

• структуру страниц, фреймов и экранов;

• UI-kit и библиотеку компонентов;

• состояния кнопок, форм, ошибок, пустых экранов, загрузки;

• адаптивные версии: desktop, tablet, mobile;

• дизайн-систему, если она была предусмотрена ТЗ;

• иконки, иллюстрации, баннеры, изображения;

• исходники логотипа, если подрядчик его создавал;

• экспортные форматы: SVG, PNG, PDF, WebP, AVIF — если они нужны проекту;

• лицензии на шрифты, изображения и графику.

Нормальная передача дизайна означает, что заказчик может пригласить другого дизайнера и продолжить работу без пересоздания макетов с нуля.

Передача доступов: где чаще всего возникают проблемы

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

Проверьте минимум 15 групп доступов:

1. Доменный регистратор.

2. DNS-зона.

3. Хостинг или облачная платформа.

4. SSL-сертификаты.

5. Репозиторий кода.

6. CI/CD-система.

7. CMS или админ-панель.

8. Базы данных.

9. Файловое хранилище.

10. Email-сервис.

11. SMS, push, captcha, CDN.

12. Платежный провайдер.

13. Аналитика и пиксели.

14. Сервис ошибок, логов и мониторинга.

15. Apple Developer, Google Play Console и сервисы мобильной аналитики.

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

После передачи:

• смените все пароли;

• включите двухфакторную аутентификацию;

• замените резервные email и телефоны;

• удалите лишних пользователей;

• пересоздайте API-ключи, если они передавались небезопасно;

• проверьте, кто оплачивает тарифы и подписки.

Сравнение вариантов передачи проекта

Перед финальной оплатой важно выбрать не самый быстрый, а самый безопасный формат приемки.

| Вариант передачи | Когда подходит | Плюсы | Риски | Что проверить |

|---|---|---|---|---|

| Архив с файлами | Маленький лендинг, статичная верстка, прототип | Быстро и дешево | Нет истории изменений, сложно поддерживать | Есть ли все файлы, инструкции, лицензии |

| Репозиторий Git | Сайт, приложение, сервис, интеграции | История коммитов, ветки, контроль версий | Может быть передана не вся кодовая база | Роль owner/admin, актуальная release-ветка |

| Передача аккаунтов заказчику | Домен, хостинг, облака, аналитика | Полный контроль инфраструктуры | Нужно аккуратно менять роли и пароли | Владелец аккаунта, 2FA, резервные контакты |

| Совместная приемка с техаудитом | Средний и крупный проект | Видны скрытые дефекты до оплаты | Требует бюджета и времени | Отчет аудитора, список критичных замечаний |

| Передача с гарантийным удержанием | Проекты с риском багов после релиза | Подрядчик мотивирован исправлять ошибки | Нужно заранее описать условия | Сумма удержания, срок, критерии выплаты |

| Этапная передача | Долгий проект с несколькими релизами | Меньше риска накопления проблем | Нужна дисциплина документов | Акты по каждому этапу, список результатов |

Для небольшого проекта техническая проверка перед оплатой может стоить 15 000–50 000 ₽. Для сложного сервиса, мобильного приложения, маркетплейса или продукта с платежами — 70 000–200 000 ₽ и выше. Это часто дешевле, чем восстанавливать доступы, переписывать модуль или заново собирать приложение.

Для тиража или проекта запросите 3 сметы: базовую, оптимальную и срочную. Отдельно отметьте сроки 3–7 дней, гарантию и стоимость переделки. Так проще понять, где подрядчик предлагает только передачу файлов, а где действительно берет ответственность за приемку, запуск и поддержку.

Какие документы нужны вместе с актом

Один акт без приложений часто не закрывает все риски. Минимальный комплект документов:

• договор;

• техническое задание;

• смета или спецификация;

• акт выполненных работ;

• акт передачи кода, дизайна и доступов;

• приложение со списком репозиториев, макетов и сервисов;

• приложение с перечнем лицензий;

• документ о передаче исключительных прав или лицензии на использование;

• регламент гарантийной поддержки;

• список замечаний, если приемка не полностью чистая.

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

1. Документы и права

• Есть договор, ТЗ, смета и приложения.

• В договоре указано, что именно считается результатом работ.

• Описан порядок передачи прав на код, дизайн и материалы.

• Указаны сроки приемки: например, 5 рабочих дней.

• Зафиксирован гарантийный период: 30, 60 или 90 дней.

• Есть порядок исправления ошибок и доработок.

• Финальная оплата привязана к подписанию акта передачи.

• В акте перечислены конкретные ссылки и артефакты, а не только общая формулировка.

2. Код и инфраструктура

• Репозиторий передан в рабочее пространство заказчика.

• У заказчика есть права owner/admin.

• В репозитории есть весь код, а не отдельная часть frontend.

• Зависимости устанавливаются без ошибок.

• Есть инструкция запуска и деплоя.

• Production-версия соответствует согласованному релизу.

• Секреты не лежат открыто в коде.

• Настроены резервные копии.

• Есть доступ к логам, мониторингу и ошибкам.

3. Дизайн и материалы

• Figma-файл или другой исходник передан заказчику.

• Есть право редактирования и копирования.

• Переданы UI-kit, компоненты и адаптивные версии.

• Есть исходники иконок, иллюстраций, баннеров.

• Проверены шрифты и лицензии.

• Файл не зависит от личного аккаунта дизайнера.

• Переданы экспортные форматы, необходимые разработке.

4. Доступы и безопасность

• Все ключевые аккаунты оформлены на заказчика или компанию.

• Пароли переданы безопасно и затем изменены.

• Включена двухфакторная аутентификация.

• Проверены резервные email и телефоны.

• Удалены лишние пользователи.

• Подрядчику оставлены только нужные роли.

• API-ключи пересозданы, если передавались через небезопасные каналы.

• Есть доступ к домену, DNS, хостингу, базе и платежам.

5. Лицензии и сторонние сервисы

• Есть список всех платных сервисов.

• Указана стоимость подписок в месяц или год.

• Понятно, кто оплачивает сервисы после релиза.

• Проверены ограничения по коммерческому использованию.

• Нет демо-версий, которые отключатся через 7–14 дней.

• Нет библиотек или шаблонов с неясным происхождением.

• Есть документы на платные шрифты, изображения, SDK и плагины.

6. Тестирование и запуск

• Проверены основные пользовательские сценарии.

• Формы, оплата, уведомления и личный кабинет работают.

• Проект проверен на популярных браузерах и мобильных устройствах.

• Для приложения проверены установка, авторизация, push и обновление данных.

• Ошибки из баг-листа закрыты или вынесены в отдельное соглашение.

• Зафиксирована версия, которая принимается.

• Есть тестовые доступы и инструкция для поддержки.

Для интернет-магазина минимальный тест — пройти путь от выбора товара до оплаты и получения уведомления. Для мобильного сервиса — установить сборку, авторизоваться, выполнить ключевое действие, проверить push-уведомление и корректное обновление данных.

Когда финальную оплату лучше не проводить

Финальную оплату стоит отложить, если:

• подрядчик не передает исходный код;

• доступ к репозиторию выдан только на чтение;

• домен зарегистрирован на подрядчика и не передается;

• Figma-файл остается в личном аккаунте дизайнера;

• нет инструкции по запуску;

• приложение нельзя собрать без компьютера конкретного разработчика;

• неясно, кому принадлежат исключительные права;

• подрядчик обещает «потом все пришлем» после оплаты;

• неизвестно, какие платные сервисы подключены;

• нет документов на шрифты, изображения, шаблоны или библиотеки;

• нет гарантийного периода и порядка исправления ошибок;

• продакшн работает на личной карте, почте или телефоне подрядчика.

Компромиссный вариант — оплатить принятую часть, а остаток закрыть после передачи недостающих материалов. Например: 70% уже оплачено по этапам, 20% перечисляется после передачи кода и дизайна, 10% — после проверки запуска, смены доступов и исправления критичных багов.

Что может пойти не так

Потеря домена

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

Невозможность доработки

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

Скрытые платежи

После релиза может выясниться, что хостинг, карты, SMS, email, шрифты, плагины и аналитика оплачены личной картой подрядчика. Суммарно подписки могут стоить от 3 000 до 30 000 ₽ в месяц и выше, особенно если есть SMS, видео, облачное хранение, карты или высокая нагрузка.

Спор о правах

Если в договоре не указано, что права на результат передаются заказчику, подрядчик может ограничивать использование, переработку или передачу проекта другой команде. Для программного кода, дизайна, иллюстраций и текстов условия передачи прав нужно фиксировать письменно.

Отсутствие поддержки

Проект может пройти демонстрацию, но сломаться на реальных пользователях: платежи, уведомления, интеграции, личный кабинет, импорт данных. Поэтому гарантийный период 30–90 дней и понятная классификация ошибок — не формальность, а защита бюджета.

Практический порядок приемки за 3–7 дней

Для небольшого или среднего проекта проверку можно организовать за рабочую неделю.

День 1: собрать договор, ТЗ, смету, акт, ссылки, список доступов и перечень передаваемых материалов.

День 2: проверить репозитории, дизайн, домены, хостинг, облака, аналитику и сторонние сервисы.

День 3: поднять проект по инструкции или передать его на технический аудит.

День 4: протестировать пользовательские сценарии, интеграции, формы, оплату, уведомления.

День 5: сформировать список замечаний, разделить их на критичные и некритичные.

День 6–7: принять исправления, сменить пароли, включить 2FA, подписать акт или акт с замечаниями.

Срочная приемка за 1–2 дня возможна, но риск пропустить скрытые проблемы выше. Для сложного мобильного приложения, B2B-платформы, маркетплейса или сервиса с платежами разумнее планировать 7–14 дней.

Как сформулировать замечания в акте

Если проект в целом можно принять, но есть недочеты, не ограничивайтесь устной договоренностью. В акте или приложении укажите:

• список замечаний;

• степень критичности;

• срок исправления;

• ответственного исполнителя;

• сумму удержания, если она предусмотрена;

• критерий, по которому замечание считается закрытым.

Пример: «Не передан доступ администратора к DNS-зоне. Срок передачи — 2 рабочих дня. До устранения замечания удерживается 10% финальной оплаты». Такая формулировка полезнее, чем общее «подрядчик обязуется все доделать».

Можно ли платить финальную сумму до подписания акта?

Лучше не платить 100% до передачи кода, дизайна, доступов и проверки работоспособности. Без финансового удержания у подрядчика меньше мотивации быстро закрывать недостающие материалы, документы и критичные баги.

Достаточно ли обычного акта выполненных работ?

Для цифрового проекта часто недостаточно. Нужен подробный акт передачи или приложение к акту, где перечислены репозитории, макеты, доступы, лицензии, документация, права и гарантийные условия.

Нужно ли указывать пароли в акте?

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

Что важнее: код или доступы?

Оба блока критичны. Код без доступа к домену, хостингу и базе данных не дает полного контроля над проектом. Доступы без кода не позволяют нормально развивать продукт и менять подрядчика.

Что делать, если подрядчик не хочет передавать исходники дизайна?

Сначала проверьте договор и ТЗ. Если исходники входили в результат работ, требуйте их передачи до финальной оплаты. Если не входили, можно оформить дополнительное соглашение и отдельно оплатить передачу, но лучше не оставлять этот вопрос «на потом».

Можно ли принять проект с замечаниями?

Да, если замечания не блокируют запуск и зафиксированы письменно. В акте нужно указать список недочетов, сроки исправления и сумму удержания. Критичные проблемы — отсутствие кода, домена, доступа к базе, прав или возможности собрать приложение — лучше закрыть до оплаты.

Какой гарантийный срок считать нормальным?

Для небольших проектов часто используют 30 дней. Для сервисов с интеграциями, платежами и мобильными приложениями разумнее 60–90 дней. Важно не только число дней, но и порядок реакции: например, критичный баг — в течение 1 рабочего дня, обычный — за 3–5 рабочих дней.

Что делать, если доступы уже передали в мессенджере?

Сразу после приемки смените пароли, включите двухфакторную аутентификацию, обновите резервные email и телефоны, пересоздайте API-ключи и удалите лишних пользователей. Затем зафиксируйте в акте, что доступы получены и проверены.

Нужно ли привлекать технического специалиста?

Если проект дороже нескольких сотен тысяч рублей, содержит платежи, персональные данные, мобильные приложения или сложные интеграции, техническая проверка почти всегда оправдана. Даже короткий аудит за 2–7 рабочих дней может выявить проблемы, которые после финальной оплаты обойдутся дороже.

Что считать полной передачей проекта?

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