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

Почему вопрос прав стал важнее в 2026 году

Цифровой сервис сегодня редко создается «с нуля». В мобильном приложении, личном кабинете, CRM-модуле или SaaS-продукте могут одновременно использоваться:

• авторский код подрядчика;
• open-source-библиотеки;
• купленные UI-киты, шрифты, иконки, иллюстрации;
• low-code/no-code-платформы;
• облачные сервисы, API, SDK;
• дизайн-макеты в Figma или аналогах;
• фрагменты, созданные с помощью AI-инструментов;
• готовые модули подрядчика, которые он не готов передавать полностью.

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

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

По теме также можно посмотреть Удаление 551 фильма из PlayStation Store: почему Sony аннулирует цифровые покупки.

Критерии выбора подрядчика и договора

1. В договоре назван конкретный результат

Плохо, если предмет договора описан так:

«Оказание услуг по разработке цифрового сервиса».

Такой формулировки недостаточно. Лучше, когда перечислены конкретные результаты:

• исходный код backend и frontend;
• мобильные приложения для iOS и Android;
• дизайн-макеты;
• UI-компоненты;
• база данных или ее структура;
• API-документация;
• техническая документация;
• инструкции администратора;
• сборочные файлы;
• доступы к репозиторию, хостингу, облакам, аналитике;
• переданные лицензии или перечень сторонних компонентов.

Чем точнее описан результат, тем проще доказать, что именно должно быть передано после оплаты.

2. Отдельно прописана передача исключительных прав

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

Проверьте:

• какие права передаются: использование, изменение, переработка, распространение, публикация, передача третьим лицам;
• территория использования: весь мир или конкретная страна;
• срок: бессрочно или на ограниченный период;
• момент перехода прав: после полной оплаты, после подписания акта или после передачи исходников;
• можно ли привлекать другого подрядчика для доработок;
• можно ли продавать сервис, масштабировать его, выпускать white-label-версии.

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

3. Исходники передаются вместе с результатом

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

Минимальный комплект:

• исходный код;
• репозиторий Git с историей изменений;
• инструкция по запуску проекта;
• файл окружения без секретов, но с перечнем нужных переменных;
• список зависимостей и версий;
• схема базы данных;
• документация по API;
• доступы к CI/CD, хостингу, домену, облаку;
• дизайн-файлы в редактируемом формате;
• экспорт ассетов;
• список сторонних лицензий.

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

4. Дизайн и макеты не остаются «в портфолио студии» без ограничений

Дизайн цифрового сервиса — это не только картинки. В него входят:

• структура экранов;
• визуальный стиль;
• иконки;
• компоненты интерфейса;
• прототипы;
• анимации;
• дизайн-система;
• исходники в Figma, Sketch, Adobe XD или другом инструменте.

Проверьте, может ли исполнитель:

• использовать ваш дизайн для другого клиента;
• показывать проект в портфолио до публичного запуска;
• публиковать скриншоты с коммерческими данными;
• оставлять у себя право на UI-кит;
• продавать похожие компоненты другим заказчикам.

Нормальная практика — разрешить показывать проект в портфолио после релиза, но запретить раскрывать внутренние данные, бизнес-логику, пользовательские сценарии и закрытые экраны.

5. В договоре есть ТЗ, смета и порядок правок

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

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

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

2. смета;

3. календарный план;

4. перечень передаваемых материалов;

5. акт приема-передачи;

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

7. список сторонних компонентов и лицензий.

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

Таблица проверки договора до оплаты

Сравнение вариантов оформления прав

Вариант 1. Полная передача исключительных прав

Это лучший вариант, если вы создаете собственный продукт: мобильное приложение, SaaS, личный кабинет, маркетплейс, внутреннюю платформу, CRM-модуль.

Что получает заказчик:

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

Что проверить:

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

Минус: цена может быть выше на 10–30%, особенно если подрядчик обычно переиспользует свои модули.

Вариант 2. Лицензия на использование

Подходит, если вы покупаете доступ к готовой платформе, white-label-решению или модулю, который подрядчик развивает для многих клиентов.

Что получает заказчик:

• право использовать сервис в оговоренных пределах;
• быстрый запуск;
• поддержку от владельца платформы;
• меньшую стартовую стоимость.

Риски:

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

Типичные цены: лицензия на готовый B2B-сервис может стоить условно от 5 000–30 000 рублей в месяц за небольшой кабинет до 100 000+ рублей в месяц за корпоративный контур с интеграциями. Конкретная цена зависит от пользователей, модулей, хранения данных и SLA.

Вариант 3. Смешанная модель

Часто встречается на практике: уникальный дизайн и бизнес-логика переходят заказчику, а ядро, CMS, UI-kit или библиотека остаются у подрядчика по лицензии.

Когда это нормально:

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

Когда опасно:

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

Что обязательно зафиксировать в акте

Акт приема-передачи — не формальность. Если в акте написано только «услуги оказаны в полном объеме», вы подтверждаете оплату, но не фиксируете передачу конкретных материалов.

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

• ссылку на репозиторий;
• дату и хеш последнего коммита;
• архив исходного кода;
• список веток и релизов;
• ссылку на дизайн-макеты;
• перечень переданных файлов;
• данные о переданных доступах;
• перечень сторонних лицензий;
• инструкции по запуску;
• список известных ограничений;
• гарантийный срок;
• остаток задач, если они переносятся в следующий этап.

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

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

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

Минимальный набор:

1. договор на разработку;

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

3. смета;

4. календарный план;

5. приложение о передаче прав;

6. акт приема-передачи;

7. реестр исходников и макетов;

8. список сторонних компонентов;

9. лицензии на шрифты, изображения, UI-киты;

10. инструкция администратора;

11. инструкция разработчика;

12. регламент гарантийной поддержки.

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

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

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

Сценарий 1. Код есть, но запустить его невозможно

Вам передали архив, но нет инструкции, переменных окружения, версии базы данных, docker-файлов, ключей API и описания зависимостей. Формально исходники переданы, фактически новый разработчик тратит 20–40 часов только на восстановление проекта.

Что делать заранее: включить в договор критерий приемки — проект должен запускаться по инструкции на тестовом окружении.

Сценарий 2. Дизайн передан картинками

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

Что делать заранее: указать формат макетов и право редактирования. Например: «редактируемый файл с доступом владельца или редактора».

Сценарий 3. Подрядчик оставил домен и облако на себе

Сервис работает, но домен, хостинг, облачная база, пуш-уведомления и аккаунт разработчика зарегистрированы на исполнителя. При конфликте вы теряете управление.

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

Сценарий 4. Использованы платные материалы без лицензий

В интерфейсе есть шрифты, иконки, фотографии или UI-kit, но нет подтверждения покупки и разрешенного способа использования. Через несколько месяцев может прийти претензия от правообладателя.

Что делать заранее: попросить реестр материалов с источником, типом лицензии и ограничениями.

Сценарий 5. В договоре запрещена доработка третьими лицами

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

Что делать заранее: прямо добавить право на модификацию, переработку, адаптацию и привлечение третьих лиц.

Когда полная передача прав не подходит

Полная передача исключительных прав не всегда нужна и не всегда экономически оправдана.

Она может быть избыточной, если:

• вы арендуете готовую SaaS-платформу;
• нужен быстрый MVP на 1–3 месяца для проверки гипотезы;
• бюджет ограничен, а продукт еще не подтвержден рынком;
• подрядчик использует собственное ядро, которое не продает;
• вам достаточно выгрузки данных и стабильной поддержки.

В таких случаях лучше не требовать «все права на все», а честно зафиксировать лицензию, доступы, экспорт данных, срок уведомления о расторжении и стоимость миграции. Например, для MVP можно согласовать лицензию на 6 месяцев, право выгрузки данных в CSV/JSON и опцию выкупа исходников за отдельную сумму.

Чек-лист перед решением

Перед оплатой пройдитесь по этому списку.

• В договоре назван конкретный цифровой сервис, а не абстрактные услуги.
• Есть техническое задание с функциями, экранами, интеграциями и критериями приемки.
• Указано, кому принадлежат исключительные права на код.
• Указано, кому принадлежат права на дизайн, макеты и UI-компоненты.
• Передача прав привязана к понятному событию: оплате, акту, передаче исходников.
• Есть право дорабатывать сервис своими силами или с другим подрядчиком.
• Исходный код передается в рабочем виде.
• Репозиторий, домен, хостинг, облака и аккаунты оформлены на заказчика.
• Передаются редактируемые дизайн-файлы, а не только картинки.
• Есть список open-source и коммерческих компонентов.
• Проверены лицензии на шрифты, изображения, иконки, SDK и UI-киты.
• В смете отдельно указаны разработка, дизайн, интеграции, тестирование, поддержка.
• Зафиксированы сроки: например, этап прототипа 3–7 дней, дизайн 5–15 рабочих дней, разработка MVP 4–8 недель.
• Указано количество правок: например, 2 раунда по дизайну и 1 раунд по текстам.
• Есть гарантия на ошибки: обычно 30–90 дней после приемки.
• Понятна стоимость доработок: например, почасовая ставка или пакет часов.
• В акте перечислены все переданные файлы, доступы и документы.
• Подрядчик подтвердил права субподрядчиков.
• Есть порядок расторжения и передачи материалов при остановке проекта.
• Вы понимаете, что останется у подрядчика: фреймворк, CMS, библиотека, шаблон или ничего.

Практический пример формулировки для договора

Можно использовать как ориентир для обсуждения с юристом:

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

Для сторонних компонентов нужна отдельная оговорка:

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

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

Как проверить подрядчика до подписания

До старта проекта задайте подрядчику 7 вопросов:

1. Какие части сервиса будут написаны специально для нас?

2. Какие части вы используете как свои готовые модули?

3. Что из этого перейдет нам в собственность, а что будет по лицензии?

4. В каком формате вы передаете исходники и макеты?

5. Кто будет владельцем репозитория, домена, облака и аккаунтов?

6. Какие сторонние библиотеки, шрифты и сервисы планируются?

7. Сколько стоит передача проекта другой команде после завершения работ?

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