Как составить договор на разработку ПО: техническое задание, права на код и расчеты

Материал актуален на 25.09.2026, подготовлен в соавторстве: Полина Пушкарева @PauletteB — адвокат практики интеллектуальной собственности и Александр Афонин @ABP_LEGAL_ALEX — руководитель практики интеллектуальной собственности

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

Содержание:

1. Основные вопросы, которые должны быть разрешены в договоре на разработку ПО

2. Какой договор заключать на разработку ПО?

3. Что именно создаем, предмет договора и техническое задание

4. Когда начинается и заканчивается разработка, сроки и этапы разработки ПО

5. Как управляем изменениями, оформление изменений в ТЗ и дополнительных работ

6. Как платим за разработку, стоимость разработки и порядок оплаты

7. Как принимаем разработанное ПО?

8.  Кому принадлежит исключительное право на ПО?

9. Что делать со сторонними компонентами?

10. Что происходит при расторжении договора?

11. Гарантия, ответственность, NDA и персональные данные

12. Чек-лист договора на разработку ПО: что важно проверить перед подписание?

1. Основные вопросы, которые должны быть разрешены в договоре на разработку ПО

Компании и разработчики часто относятся к договору на разработку ПО как к формальности, считая, что главное – договориться о цене, сроке и результате. Но на практике именно договор определяет, что именно должен сделать подрядчик, что обязан дать заказчик, кто получает права на код и что делать, если проект пошел не по плану.

Для программного продукта недостаточно написать: «разработать программное обеспечение». В договоре нужно заранее ответить на практические вопросы:

• что именно создается и по каким критериям это можно проверить?

• как стороны согласуют новые требования?

• как рассчитывается стоимость разработки?

• когда результат считается переданным и принятым?

• какие права получает заказчик, а что остается у исполнителя?

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

• что происходит, если проект прекращается до завершения?

Без этих ответов технический проект легко превращается в спор о том, «что имелось в виду», «готов ли продукт», «почему это не входит в цену» и «кому принадлежит код».

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

Отсутствие подписанного договора или использование шаблона без адаптации создает риски для обеих сторон. Заказчик может заплатить за разработку и не получить согласованный объем прав, исходный код или доступ к инфраструктуре. Исполнитель может выполнить работу, но столкнуться с отказом от приемки и оплаты из-за того, что результат и порядок подтверждения работ не были зафиксированы.

Пример из судебной практики

Показателен спор по делу № А40-94827/2024. Истец утверждал, что выполнил работы по трем договорам, однако ответчик не подписал договоры и не выплатил более 27 млн рублей. В подтверждение своих доводов истец представил переписку, односторонние акты и проекты договоров.

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

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

2.Какой договор заключать на разработку ПО?

В российском праве нет отдельного поименованного договора «на разработку ПО». В зависимости от содержания проекта стороны используют подряд, возмездное оказание услуг, авторский заказ или смешанную конструкцию.

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

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

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

Почему стоит относиться осторожно к шаблонам из Интернета

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

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

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

3. Что именно создаем, предмет договора и техническое задание

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

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

Пример описания предмета договора

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

В предмете договора следует указать:

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

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

• состав передаваемых материалов: исходный и объектный код, документация, дизайн, схемы баз данных, инструкции по развертыванию

• ссылку на ТЗ и иные приложения

• способ передачи результата и доступов

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

В ТЗ рекомендуется включить (в зависимости от проекта):

• описание проекта – назначение ПО, основные сценарии использования

• функциональные требования – что система должна делать (по пунктам)

• технические требования – язык программирования, фреймворки, базы данных, хостинг, совместимость

• требования к дизайну – референсы, стиль, адаптивность

• интеграции – какие внешние сервисы должны быть подключены (платежные системы, CRM, API).

• критерии готовности – что считается «готовым продуктом «(например, «все функции из раздела 2 работают, тесты пройдены, документация передана»)

• требования к тестированию – какие тесты должны быть пройдены (юнит-тесты, интеграционные, нагрузочные)

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

ТЗ должно быть подписано обеими сторонами и стать приложением к договору. Любые изменения в ТЗ оформляются дополнительным соглашением.

4. Когда начинается и заканчивается разработка, сроки и этапы разработки ПО

Этот вопрос обычно регулируется разделом «Сроки и этапы выполнения работ».

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

Пример описания этапности работ

«Работы, предусмотренные настоящим Договором, выполняются в следующие сроки:

• Этап 1 (прототипирование и дизайн): с 15.09.2026 по 15.10.2026:

• Этап 2 (верстка и фронтенд): с 16.10.2026 по 30.11.2026;

• Этап 3 (бэкенд и интеграции): с 01.12.2026 по 31.01.2027;

• Этап 4 (тестирование и запуск): с 01.02.2027 по 28.02.2027.»

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

Пример описания порядка изменения сроков

В договоре можно указать:

• общий срок проекта

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

• срок передачи исходных данных заказчиком

• срок предоставления доступов

• срок согласования решений

• срок приёмки

• срок исправления замечаний

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

Также важно прописать, когда начинается отсчет срока. Срок этапа может начинаться после:

• получения аванса

• утверждения технического задания

• передачи необходимых данных

• предоставления доступа к инфраструктуре

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

 5. Как управляем изменениями, оформление изменений в ТЗ и дополнительных работ

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

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

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

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

Пример из договора

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

6. Как платим за разработку, стоимость разработки и порядок оплаты

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

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

Дополнительно в договоре можно определить, кто оплачивает:

• облачные сервисы

• лицензии

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

• домены и сертификаты

• сторонние API

• услуги хостинга

• иные необходимые расходы

7. Как принимаем разработанное ПО?

Здесь важно предусмотреть:

• порядок приемки – как сдаётся работа (акт, письмо, система трекинга)

• срок на проверку – сколько времени у заказчика на тестирование

• порядок мотивированного отказа – как оформить замечания

• правило автоматической приемки – если заказчик молчит N дней, работа считается принятой

• повторная сдача – сроки устранения замечаний

Пример формулировки:

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

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

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

• тестовые сценарии

• список поддерживаемых платформ

• допустимое время отклика

• перечень ролей пользователей

• список интеграций

• требования к безопасности

• допустимое количество ошибок

 8. Кому принадлежит исключительное право на ПО?

В договоре нужно разграничить как минимум четыре вопроса:

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

• предоставляется ли заказчику лицензия вместо отчуждения исключительного права

• когда возникают или переходят соответствующие права

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

Возможны разные модели:

1. исключительное право может перейти заказчику полностью или поэтапно, например, после оплаты соответствующего этапа.

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

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

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

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

Пример формулировки:

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

5.2. До момента полной оплаты исключительные права на результат работ принадлежат Исполнителю.

5.3. Исполнитель гарантирует, что:

• ПО разработано им лично;

• при разработке ПО не использовались материалы, нарушающие права третьих лиц (включая программы с открытым исходным кодом с ограничительными лицензиями);

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

5.4. Передача исключительных прав оформляется Актом об отчуждении исключительного права (Приложение № 3).

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

9.Что делать со сторонними компонентами?

В договоре следует отделить:

• код, созданный специально по заказу

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

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

• платные библиотеки, сервисы и API третьих лиц

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

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

По open source нужно проверить лицензию каждого значимого компонента и способ его интеграции. Последствия зависят от конкретной лицензии, характера взаимодействия компонентов и способа распространения программы. Некоторые лицензии семейства GPL при распространении производного или объединенного программного продукта могут требовать предоставления соответствующего исходного кода на условиях GPL. Само по себе использование любой GPL-библиотеки не означает обязанности опубликовать весь код проекта.

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

10.Что происходит при расторжении договора?

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

В договоре стоит закрепить, что при прекращении работ исполнитель в течение определенного срока передает:

• результаты оплаченных этапов и фактически созданный код

• актуальную документацию и инструкции по запуску

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

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

• сведения о незавершенных задачах и известных дефектах

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

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

11. Гарантия, ответственность, NDA и персональные данные

В договоре рекомендуется определить гарантийный срок и понятие дефекта. Багом можно считать несоответствие согласованным требованиям или ошибку, из-за которой функция не работает предусмотренным ТЗ способом. Новое требование, изменение внешнего сервиса, неправильная эксплуатация или вмешательство третьих лиц обычно не должны считаться гарантийным дефектом.

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

Пример формулировки:

«6.1. Исполнитель устанавливает гарантийный срок продолжительностью 6 (шесть) месяцев с момента подписания итогового Акта сдачи-приемки.

6.2. В течение гарантийного срока Исполнитель обязуется безвозмездно устранять ошибки (баги), выявленные в ПО, при условии, что такие ошибки:

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

• не вызваны действиями Заказчика (неправильная эксплуатация, внесение изменений в код третьими лицами).

6.3. Ошибки устраняются в следующие сроки:

• критические (система не работает): в течение 2 рабочих дней;

• значительные (отдельные функции не работают): в течение 5 рабочих дней;

• незначительные (косметические дефекты): в течение 10 рабочих дней.

6.4. За нарушение сроков выполнения работ Исполнитель уплачивает Заказчику неустойку в размере 0,1% от стоимости соответствующего этапа за каждый день просрочки, но не более 10% от общей стоимости договора.

6.5. Общая ответственность Исполнителя по настоящему Договору ограничена суммой фактически оплаченных Заказчиком работ.

6.6. Исполнитель не несет ответственности за косвенные убытки Заказчика (упущенную выгоду, потерю данных, репутационный вред)».

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

 12. Чек-лист договора на разработку ПО: что важно проверить перед подписание?

Структура договора должна помогать предотвратить конкретные проблемы, а не просто включать формальный набор разделов:

Строгой обязательной формы у договора на разработку ПО нет. Обычно в него включают преамбулу, предмет, ТЗ, сроки, цену, приемку, обязанности сторон, интеллектуальные права, гарантии, ответственность, конфиденциальность, изменение условий, форс-мажор, разрешение споров, порядок прекращения и реквизиты. Но важнее не сам список, а то, чтобы каждый раздел был связан с фактической моделью проекта.

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

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

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

2. Предмет договора конкретный, есть ссылка на ТЗ. ТЗ подписано обеими сторонами и является приложением к договору

3. Сроки разбиты на этапы с конкретными датами

4. Стоимость указана с НДС или без (в зависимости от системы налогообложения исполнителя). Порядок оплаты понятен (аванс, этапы, финал)

5. Прописан порядок приемки со сроком на проверку и правилом автоматической приемки

6. Есть раздел о переходе исключительных прав к заказчику или сохранении их за исполнителем

7. Установлен гарантийный срок

8. Определена ответственность сторон, в том числе неустойка за просрочку

9. Есть раздел о конфиденциальности (если передаете чувствительные данные)

10. Прописан порядок изменения

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

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

А вы всегда заключаете договор или полагаетесь на устные договоренности? Возникали ли у вас споры при разработке программ? Поделитесь в комментариях.