Права на код и дизайн цифрового сервиса: что проверить в договоре, актах и исходниках перед оплатой

Критерии выбора: что именно проверять перед оплатой

В цифровом сервисе права распределяются не «по ощущениям», а по документам и фактической передаче материалов. В российской практике программы для ЭВМ охраняются как объекты авторского права, включая исходный текст и объектный код; для заказной разработки важно, что договор может изменить стандартное распределение прав. Поэтому формулировки в договоре, ТЗ и актах критичны.

Если вы оплачиваете мобильное приложение, веб-сервис, CRM-модуль, личный кабинет, маркетплейс, API, дизайн-систему или MVP, проверьте 7 групп объектов:

1. Код: backend, frontend, мобильные приложения, скрипты, инфраструктурные файлы.

2. Дизайн: макеты, UI-kit, иконки, иллюстрации, анимации, дизайн-система.

3. Документация: ТЗ, архитектура, API-описания, инструкции по сборке и деплою.

4. Доступы: репозиторий, облако, домен, хостинг, аналитика, CI/CD, сторы приложений.

5. Сторонние материалы: библиотеки, фреймворки, шрифты, стоки, плагины, SaaS-сервисы.

6. Акты и приложения: перечень переданных результатов, версии, ссылки, файлы, даты.

7. Гарантия и поддержка: срок исправления ошибок, стоимость правок, регламент реакции.

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

---

Таблица проверки: договор, акты, исходники и дизайн

---

Что изменилось и что проверять сейчас

В 2026 году риск спора за цифровые активы стал выше не потому, что изменилась сама логика разработки, а потому что проекты чаще собираются из множества компонентов: open-source библиотек, no-code модулей, AI-инструментов, стоковых изображений, облачных сервисов, платных API и шаблонов интерфейса.

Раньше заказчик часто проверял только внешний результат: «открывается ли сайт» или «работает ли приложение». Сейчас этого недостаточно. Перед оплатой нужно понимать:

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

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

• не нарушают ли лицензии open-source библиотек коммерческое использование;

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

• можно ли зарегистрировать программу, товарный знак или подать продукт на аудит инвестору;

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

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

---

Сравнение вариантов: исключительные права, лицензия или только результат услуги

Перед оплатой важно понять, какую модель вы фактически покупаете.

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

---

Что должно быть в договоре

1. Точный предмет разработки

Плохая формулировка:

> Исполнитель оказывает услуги по разработке цифрового сервиса.

Лучше:

> Исполнитель разрабатывает веб-сервис, мобильное приложение, административную панель, API, дизайн-макеты, UI-kit, техническую документацию и передает результаты в составе, указанном в ТЗ и приложениях.

В договоре должны быть привязки к:

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

• прототипам;

• дизайн-макетам;

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

• списку экранов;

• API;

• интеграциям;

• этапам и срокам;

• критериям приемки.

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

2. Права на результат

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

• какие права передаются;

• на какие объекты;

• в какой момент;

• за какое вознаграждение;

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

• можно ли передавать права третьим лицам;

• сохраняет ли исполнитель право показывать проект в портфолио;

• может ли исполнитель повторно использовать фрагменты кода.

Особенно важно разделить:

• индивидуально написанный код;

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

• open-source компоненты;

• платные библиотеки;

• дизайн-шаблоны;

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

• шрифты;

• AI-сгенерированные элементы.

3. Вознаграждение за права

Если в договоре цена указана только как «стоимость услуг», полезно отдельно прописать, что вознаграждение за передачу прав включено в общую цену. Иначе в споре может возникнуть аргумент, что услуги оплачены, а права — нет или передавались в ограниченном объеме.

Практичный вариант оплаты:

• 30% — предоплата после подписания договора и ТЗ;

• 40% — после демонстрации рабочей версии или milestone;

• 20% — после передачи исходников, макетов и документации;

• 10% — после приемки и исправления критических замечаний.

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

4. Гарантии исполнителя

Исполнитель должен гарантировать, что:

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

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

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

• платные лицензии указаны в приложении;

• open-source компоненты перечислены;

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

• переданные материалы можно использовать в согласованном коммерческом проекте.

Если исполнитель привлекал фрилансеров, важно, чтобы его договоры с ними позволяли передать права вам. Иначе студия может подписать акт, но фактически не иметь полного объема прав.

---

Что должно быть в акте приемки

Акт — не формальность. Именно он часто фиксирует, что заказчик принял и что исполнитель передал.

В акте желательно перечислить:

• название проекта;

• номер и дату договора;

• этап разработки;

• версию продукта;

• ссылку на репозиторий;

• перечень веток или релизов;

• архив исходного кода;

• ссылку на дизайн-макеты;

• список переданных файлов;

• документацию;

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

• перечень неисправленных замечаний, если они есть;

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

Плохой акт:

> Услуги оказаны в полном объеме, стороны претензий не имеют.

Хороший акт:

> Переданы исходный код backend и frontend, мобильное приложение версии 1.0.3, дизайн-макеты, UI-kit, инструкция по развертыванию, перечень зависимостей, доступ к репозиторию, документация API, права на созданные результаты в объеме договора.

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

---

Что проверить в исходниках

Перед оплатой попросите технического специалиста сделать быстрый аудит. Даже 2–4 часа проверки могут сэкономить недели переделки.

Минимальный технический чек:

• есть ли доступ к GitHub, GitLab, Bitbucket или другому репозиторию;

• видна ли история коммитов;

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

• указаны версии Node.js, PHP, Python, Java, Go, Docker и других зависимостей;

• есть файл README или инструкция запуска;

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

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

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

• есть структура окружений: dev, staging, production;

• описан деплой;

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

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

• нет неизвестных зашифрованных модулей;

• нет критических зависимостей без лицензии.

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

---

Что проверить в дизайне

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

Попросите передать:

• редактируемые макеты;

• UI-kit;

• компоненты;

• стили;

• иконки в SVG;

• иллюстрации;

• анимации;

• экспортированные ассеты;

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

• список используемых шрифтов;

• лицензии на платные элементы;

• правила использования логотипа, если он создавался в рамках проекта.

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

---

Документы и доступы: что запросить у подрядчика

Перед финальной оплатой запросите единый пакет передачи проекта.

Документы

• договор;

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

• смета;

• календарный план;

• приложения по правам;

• акты по этапам;

• финальный акт;

• гарантийные обязательства;

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

• лицензии на материалы;

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

• инструкция по администрированию;

• описание API;

• схема архитектуры;

• список аккаунтов и сервисов.

Доступы

• репозиторий;

• сервер или облако;

• домен;

• DNS;

• хостинг;

• база данных;

• CI/CD;

• аналитика;

• платежный кабинет;

• push-уведомления;

• Apple Developer / Google Play Console, если есть мобильное приложение;

• Figma или аналог;

• таск-трекер;

• корпоративная почта;

• хранилище файлов.

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

---

Когда вариант не подходит и что может пойти не так

Не оплачивайте финальный этап без дополнительной проверки, если:

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

• ТЗ отсутствует или состоит из 5–10 общих фраз;

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

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

• дизайн доступен только «для просмотра»;

• репозиторий оформлен на личный аккаунт разработчика;

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

• в проекте есть неизвестные шаблоны и компоненты;

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

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

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

• исполнитель обещает «потом все передать», но просит оплатить 100% сейчас.

Что может случиться:

1. Нельзя сменить подрядчика

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

2. Сервис придется переписывать

Внешне продукт работает, но исходники неполные, зависимости устарели, документации нет.

3. Возникнет спор за дизайн

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

4. Появятся скрытые платежи

Платный шрифт, шаблон, плагин, API или SaaS оформлен на подрядчика и требует отдельной подписки.

5. Проект заблокируют в сторах или рекламе

Из-за чужих изображений, спорных товарных знаков, неоформленных прав на контент или аккаунтов.

6. Инвестор или покупатель снизит оценку продукта

На due diligence выяснится, что права на ключевые части не подтверждены.

---

Договор

• [ ] Есть точное описание цифрового сервиса.

• [ ] Приложено ТЗ.

• [ ] Указаны этапы и сроки.

• [ ] Прописан порядок правок.

• [ ] Определены критерии приемки.

• [ ] Есть раздел об интеллектуальных правах.

• [ ] Указано, какие права передаются.

• [ ] Указан момент перехода прав.

• [ ] Вознаграждение за права включено в цену или выделено отдельно.

• [ ] Прописаны гарантии исполнителя.

• [ ] Есть ответственность за нарушение прав третьих лиц.

• [ ] Описана поддержка после сдачи.

Акты

• [ ] Акт ссылается на договор и ТЗ.

• [ ] В акте перечислены переданные результаты.

• [ ] Указаны версии продукта.

• [ ] Приложены ссылки на репозиторий и макеты.

• [ ] Зафиксирована передача доступов.

• [ ] Указаны неисправленные замечания, если они есть.

• [ ] Прописан срок гарантийного исправления.

Исходники

• [ ] Передан репозиторий.

• [ ] Есть история изменений.

• [ ] Проект собирается по инструкции.

• [ ] Переданы миграции базы данных.

• [ ] Описаны зависимости.

• [ ] Нет секретов в коде.

• [ ] Нет привязки к личным аккаунтам исполнителя.

• [ ] Есть инструкция по деплою.

• [ ] Передана техническая документация.

Дизайн

• [ ] Переданы редактируемые макеты.

• [ ] Есть UI-kit или библиотека компонентов.

• [ ] Переданы иконки и ассеты.

• [ ] Указаны шрифты.

• [ ] Проверены лицензии на изображения и иллюстрации.

• [ ] Макеты находятся в аккаунте заказчика или экспортированы.

• [ ] Разрешены доработки и использование в следующих версиях продукта.

Лицензии и сторонние компоненты

• [ ] Есть список open-source библиотек.

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

• [ ] Указаны платные плагины и шаблоны.

• [ ] Понятно, кто оплачивает подписки.

• [ ] Есть документы на материалы или услугу.

• [ ] Нет компонентов с неизвестным происхождением.

---

Практический сценарий: как провести приемку за 3–7 дней

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

День 1: собрать документы

Запросите договор, ТЗ, смету, акты, ссылки на макеты, репозиторий, список лицензий и доступов. Сразу зафиксируйте, что финальная оплата будет после проверки комплекта.

День 2–3: технический аудит

Попросите разработчика или независимого специалиста проверить сборку, зависимости, структуру кода, базу данных и инструкции. Для небольшого сервиса достаточно 2–6 часов. Для сложного SaaS или мобильного приложения — 1–3 рабочих дня.

День 3–4: дизайн-аудит

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

День 4–5: юридическая сверка

Сравните договор, ТЗ и акт. Если в договоре обещана передача исключительных прав, акт должен подтверждать передачу конкретных результатов. Если правовая модель — лицензия, проверьте срок, территорию, способы использования и ограничения.

День 5–7: исправления и финальная оплата

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

---

Внутренние ссылки, которые уместно добавить

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

• из блока про ТЗ — на материал о том, как составить техническое задание на разработку цифрового сервиса;

• из блока про поддержку — на статью о том, что включить в договор сопровождения мобильного приложения или веб-сервиса;

• из блока про смету — на разбор, как сравнивать сметы на разработку и не пропустить скрытые расходы.

---

Достаточно ли оплатить разработку, чтобы права автоматически перешли заказчику?

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

Что важнее: договор или акт?

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

Можно ли платить 100% до передачи исходников?

Это рискованно. Безопаснее оставить 10–20% финального платежа до передачи репозитория, дизайн-файлов, документации, доступов и подписания корректного акта.

Нужно ли требовать исключительные права всегда?

Нет. Если вы покупаете типовой модуль, шаблон, SaaS или white-label решение, исполнитель может законно предоставлять только лицензию. Но если вы заказываете индивидуальный продукт, особенно для стартапа или коммерческой платформы, исключительные права на созданные специально для вас части часто важны.

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

Сначала проверьте договор. Если передача исходников предусмотрена, требуйте исполнить обязательство письменно. Если не предусмотрена, придется договариваться отдельно: о выкупе, лицензии, передаче архива или техническом сопровождении. На будущее передачу исходников нужно прописывать до старта работ.

Дизайн в Figma открыт по ссылке. Этого достаточно?

Нет, доступ по ссылке не равен передаче прав и исходников. Лучше, чтобы макеты были переданы в рабочее пространство заказчика или экспортированы в согласованном редактируемом формате, а в акте было указано, какие дизайн-материалы переданы.

Кто отвечает за шрифты, изображения и платные плагины?

Это нужно прописать в договоре. Подрядчик должен раскрыть, какие материалы использованы, на каких условиях и кто оплачивает лицензии. Иначе после запуска может выясниться, что коммерческое использование требует отдельной покупки.

Можно ли потом отдать проект другой команде?

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

Какие документы попросить минимум?

Минимальный комплект: договор, ТЗ, смета, финальный акт, ссылка на репозиторий, дизайн-макеты, инструкция по запуску, перечень зависимостей, список лицензий и подтверждение передачи доступов.

Когда нужен юрист?

Юрист нужен, если стоимость проекта существенная, продукт планируется продавать, привлекать инвестиции, регистрировать права, масштабировать как SaaS или передавать третьим лицам. Для MVP с бюджетом условно до 300–500 тыс. рублей иногда достаточно шаблонной проверки, но для продукта с коммерческой ценностью лучше провести полноценный аудит.

---

Материал носит информационный характер и не заменяет юридическую консультацию под конкретный договор и юрисдикцию. Для проверки правовой базы по российскому праву полезно сверяться с частью четвертой ГК РФ и разъяснениями Роспатента: программы для ЭВМ охраняются как объекты авторского права, включая исходный текст и объектный код. Источники: Роспатент, часть четвертая ГК РФ, ГК РФ ст. 1295 о служебных произведениях.