Договор на разработку программного обеспечения связывает требования к продукту, порядок работы команды, оплату и права на результат. Из него должно быть понятно, что именно создаёт исполнитель, как согласуются изменения и что заказчик получает при завершении проекта.
В разработке требования часто уточняются по ходу работы. Поэтому важно оформить не только первоначальную задачу, но и порядок принятия решений: кто утверждает новые функции, как меняются бюджет и сроки, по каким критериям принимается результат.
В юридической практике «Софист» готовим договоры для заказчиков и разработчиков ПО, проверяем проекты контрагентов и помогаем согласовать условия. Работаем из Казани с клиентами по всей России. Подготовка договора — от 30 000 рублей, проверка и доработка — от 20 000 рублей.
С какими задачами можно обратиться
- Заказать разработку приложения, веб-сервиса, внутренней системы или отдельного модуля.
- Подготовить договор для студии или команды, которая регулярно разрабатывает ПО для клиентов.
- Оформить работу с программистом, подрядчиком или командой внешних исполнителей.
- Согласовать разработку по этапам, спринтам или с оплатой затраченного времени.
- Проверить договор заказчика или исполнителя перед подписанием.
- Обновить действующий договор, если изменились процесс разработки, расчёты или распределение прав.
У заказчика и разработчика разные приоритеты. Заказчику нужны проверяемый результат, доступ к материалам и достаточные права для дальнейшей работы. Исполнителю — согласованный объём, своевременная обратная связь и понятный порядок оплаты дополнительных задач. Условия готовим с учётом вашей стороны в сделке.
Что получает клиент
Сначала разбираем, как устроен проект: кто пишет код, как утверждаются задачи, где ведётся разработка и как стороны рассчитываются. На этой основе готовим документ под фактическую работу команды.
В зависимости от задания результат включает:
- Основной договор. Обязанности сторон, порядок постановки задач, расчёты, приёмка, права, ответственность и прекращение сотрудничества.
- Формы приложений. Задание, описание этапа, смета, график или заявка на изменение объёма — если они нужны выбранной модели.
- Документы сдачи результата. Форма акта, отчёта и перечня передаваемых материалов в согласованном составе.
- При проверке договора — правки и пояснения. Выделяем значимые риски, предлагаем изменения и объясняем оставшиеся спорные условия.
- Рекомендации по применению. Что заполнять для нового проекта, как фиксировать изменения и какие действия важны для подтверждения исполнения.
Набор документов и объём согласования определяем до начала работы. Техническое содержание задания готовит проектная команда; юридическая работа связывает его с обязательствами, оплатой, приёмкой и правами на результат.
Форматы работы и стоимость
| Формат | Что входит | Стоимость |
|---|---|---|
| Подготовка договора на разработку ПО | Договор под согласованную модель работы, необходимые формы приложений и пояснения по применению в пределах задания | От 30 000 рублей |
| Проверка и доработка договора | Анализ проекта заказчика или разработчика, предложения по изменению условий и согласованная редакция с правками | От 20 000 рублей |
| Комплексное сопровождение проекта | Несколько взаимосвязанных договоров, согласование с контрагентом, оформление отношений с командой и изменений по ходу разработки — в согласованном объёме | По объёму проекта |
На стоимость влияют состав участников, модель разработки, состояние исходных документов, количество приложений и участие в переговорах. До начала работы фиксируем состав услуги, результат, сроки и окончательную стоимость. Дополнительные задачи и их оплату согласуем отдельно.
Если договорные вопросы возникают регулярно, можно рассмотреть юридическое сопровождение IT-компании. Для отдельной сделки доступна подготовка и проверка договоров.
Как выбрать модель договора и оплаты
Название договора не определяет все правила сотрудничества. Нужно учитывать содержание обязательств и статус исполнителя: программа создаётся компанией с участием команды или непосредственно человеком, который является её автором. В проекте могут сочетаться разработка, предоставление лицензий на готовые модули, внедрение и поддержка.
Отдельно выбирают порядок оплаты. Метод организации разработки и способ расчётов — разные вопросы: работа по спринтам может оплачиваться как за согласованный результат, так и по затраченному времени.
| Модель расчётов | Что согласовать |
|---|---|
| Фиксированная цена | Объём результата, допущения оценки, этапы, критерии готовности и порядок изменения цены при новых требованиях |
| Оплата времени — Time & Materials | Ставки, состав команды, постановку задач, отчётность, подтверждение времени, бюджетные лимиты и передачу результатов |
| Смешанная модель | Какие задачи имеют фиксированную стоимость, какие оплачиваются по времени и как стороны разрешают пограничные ситуации |
Пример. Условие «ставка — 3 000 рублей в час» не отвечает на вопросы о том, кто вправе заказать работу, сколько часов разрешено потратить и чем подтверждается выполнение. В договоре можно предусмотреть оценку задачи, лимит времени и отдельное согласование превышения.
Что описать в задании и как оформлять изменения
Задание должно позволять установить, какой результат ожидается от исполнителя. Для этого определяют функции, пользовательские сценарии, интеграции, поддерживаемую среду и необходимые характеристики работы программы. Чем важнее требование для приёмки, тем точнее стоит описать способ его проверки.
Вместо общего требования «система должна работать быстро» можно согласовать сценарий, объём данных, число одновременных пользователей и допустимое время ответа. Значения определяет техническая команда, а договор закрепляет, как их проверяют.
Когда полный объём ещё неизвестен, можно начать с обследования, проектирования или ограниченного этапа. Для последующих задач устанавливают порядок утверждения: кто ставит задачу, где фиксируется её содержание и когда согласуются стоимость и сроки.
Полезно разделить:
- исправление недостатка — приведение результата в соответствие с согласованными требованиями;
- уточнение — конкретизацию задачи в пределах принятой оценки;
- дополнительную работу — изменение согласованного объёма, которое требует отдельного решения по цене и срокам.
Заявку на изменение можно связать с письмом, карточкой задачи или приложением к договору. Важно определить уполномоченных лиц и содержание согласования. Сообщение сотрудника «давайте добавим эту функцию» не должно оставлять открытым вопрос, утверждён ли дополнительный бюджет.
Для Agile-проекта согласуют период планирования, состав задач на этап, критерии их завершения и порядок проверки. Само слово Agile не заменяет эти условия.
Пример карточки отдельной задачи
Для проекта с меняющимися требованиями можно использовать короткое описание, в котором связаны результат, проверка, оценка и согласование.
| Поле | Пример заполнения |
|---|---|
| Результат | Экспорт списка заказов в CSV |
| Критерий проверки | Выгрузка содержит согласованные поля и проходит контрольный тест на тестовой базе |
| Оценка | Не более восьми часов; превышение согласуется отдельно |
| Срок | Три рабочих дня после утверждения задачи и предоставления тестовой базы |
| Утверждение | Уполномоченный представитель заказчика подтверждает объём, оценку и срок в согласованной системе |
Это пример структуры задачи: конкретные значения стороны определяют для своего проекта. В договоре закрепляют, кто вправе её утвердить и какое значение имеет такое согласование.
Сроки и участие заказчика
Разработка зависит от материалов, доступов, решений и обратной связи заказчика. Укажите, что и к какой дате он должен предоставить, сколько времени отводится на согласование и кто принимает решения.
Для задержек определяют порядок уведомления, подтверждение влияния на работу и правила изменения графика. Любая задержка ответа не должна автоматически объяснять любое отставание исполнителя: важно установить связь с конкретной задачей.
В договоре также стоит предусмотреть, что делать при длительной паузе: как сохраняется результат, оплачивается ли резервирование команды и на каких условиях работа возобновляется. Такие обязательства требуют прямого согласования.
Как принимать программу и подтверждать выполненную работу
Показа работающего интерфейса может быть недостаточно для проверки всего задания. Заранее определите тестовую среду, сценарии, исходные данные, срок проверки и состав материалов, которые исполнитель передаёт вместе с результатом.
Рабочая процедура включает:
- Уведомление о готовности конкретного этапа и передачу согласованных материалов.
- Проверку по установленным критериям.
- Оформление замечаний с описанием ошибки, условий её воспроизведения и связи с заданием.
- Исправление недостатков и повторную проверку в согласованном порядке.
- Подтверждение приёмки и расчёты за этап.
Отдельно определяют, какие недостатки препятствуют приёмке, а какие можно устранить после неё. Приёмка по истечении срока без замечаний должна быть связана с реальной передачей результата, доступностью проверки и надлежащим уведомлением. Она не должна подменять передачу материалов или означать безусловное освобождение от ответственности за скрытые недостатки.
Судебный пример: коммиты не заменили согласованную сдачу работ
В деле № А56-47032/2025 исполнитель требовал оплатить разработку с почасовым расчётом и ссылался на загрузку кода в GIT-репозиторий. Суды указали на отсутствие доказательств согласованных заявок и предъявления результата к приёмке в установленном договором порядке, включая направление актов. Арбитражный суд Северо-Западного округа 27 августа 2026 года оставил отказ в иске без изменения. Постановление № Ф07-5954/26.
Практический вывод — согласовать юридический порядок сдачи с реальным процессом команды. Если используются отчёты и задачи в системе управления проектом, нужно определить их роль в приёмке и оплате. Обстоятельства этого дела не означают, что без двустороннего бумажного акта взыскание оплаты невозможно в любом проекте.
Кому принадлежат права на разработанное ПО
Принадлежность прав зависит от содержания договора и того, кто создаёт программу. Когда создание ПО прямо заказано компании-разработчику, по общему правилу исключительное право принадлежит заказчику, если стороны не предусмотрели иное. Для договора непосредственно с самим автором действует другая конструкция — авторский заказ; в договоре нужно прямо определить, передаётся ли исключительное право или предоставляется лицензия. Наличие у автора статуса ИП или самозанятого само по себе этого вопроса не решает.
Если программа возникла при выполнении работ, которые прямо не предусматривали её создание, правила распределения прав отличаются. Поэтому нельзя одинаково оформлять создание продукта с нуля, настройку системы и сопутствующую разработку небольшого модуля.
В одном продукте могут сочетаться результаты с разными условиями использования:
| Часть продукта | Что согласовать |
|---|---|
| Новый код и другие результаты проекта | На какие результаты заказчик получает исключительное право или лицензию, с какого момента и на каких условиях; как учитывается вознаграждение за права |
| Ранее созданные модули исполнителя | Какие компоненты остаются у разработчика, на каких условиях заказчик может их использовать и изменять, доступна ли дальнейшая работа с другой командой |
| Сторонние компоненты | Перечень, версии, лицензии и ограничения, необходимые уведомления и материалы для правомерного использования |
Отдельно проверяют, как исполнитель получил права от работников и привлечённых разработчиков. Общее обещание «передать все права» не заменяет согласование состава продукта и условий для каждой группы результатов.
Полная оплата не является универсальным правилом перехода прав. Если стороны хотят связать определённый момент с оплатой или приёмкой, это нужно закрепить с учётом применимой модели договора. Получение файлов и приобретение исключительного права также следует различать.
Для продукта, который уже существовал до создания компании, полезна статья о передаче прав на программу от основателя к ООО. Если исполнитель сохраняет права на готовое ядро и предоставляет возможность его использования, отдельно прорабатывают лицензионные условия.
Какие материалы и доступы передать заказчику
Договорённость о правах стоит дополнить конкретным перечнем передаваемых материалов. Он может включать исходный и объектный код, описание зависимостей, инструкции сборки и развёртывания, документацию, тесты и доступы к согласованной инфраструктуре.
Определите репозиторий, права администратора и способ фиксации передаваемой версии. Заказчику важно иметь возможность получить предусмотренные договором материалы и продолжить работу с другой командой. Исполнителю — подтвердить, какой результат, кому и когда передан.
Судебный пример: хранение кода требует отдельного внимания
В деле № А45-26234/2022 спор возник после разработки мобильного приложения. Суды не признали доказанной передачу заказчику исходного кода и учли размещение программы исполнителем на GitHub при отсутствии согласования такого хранения в договоре. Суд по интеллектуальным правам 18 июля 2023 года оставил взыскание компенсации за нарушение исключительного права в силе. Постановление № С01-1130/2023.
Для своего проекта согласуйте место хранения, полномочия участников и использование копий после завершения работ. Это вывод для организации процесса, а не общий запрет на применение GitHub или других репозиториев.
Как учитывать open source и сторонние компоненты
Сторонние библиотеки, коммерческие SDK и ранее созданные модули могут использоваться на разных условиях. Передача прав на новый код не означает приобретение исключительного права на все компоненты внутри продукта.
В договоре полезно предусмотреть перечень компонентов с версиями и лицензиями, порядок согласования ограничений и передачу необходимых уведомлений. Например, MIT требует сохранять предусмотренные лицензией уведомления, а GPLv3 предусматривает условия предоставления соответствующего исходного кода при передаче охваченного лицензией объектного кода. Последствия оценивают по конкретной лицензии, составу продукта и способу использования; любая открытая библиотека не означает обязательного раскрытия всего проекта.
Юридическую проверку условий лицензий и технический анализ состава кода нужно различать. Для сложного продукта могут потребоваться обе задачи; их объём согласуют отдельно.
Если команда использует ИИ-инструменты, обсудите допустимость загрузки клиентского кода и закрытой документации во внешние сервисы, порядок проверки результата и ответственность за включение сторонних материалов.
Ответственность, поддержка и прекращение проекта
Согласуйте, что считается недостатком, как направляются обращения и в какие сроки исполнитель исправляет ошибки. Отдельно определите границы гарантийных обязательств, платных доработок и поддержки после завершения разработки. Подробные условия обслуживания можно оформить через договор технической поддержки и SLA.
Неустойки, пределы ответственности и исключения из них проверяют с учётом содержания обязательств и применимых требований закона. Размер санкции сам по себе не решает вопроса о том, какой результат должен был быть передан и в чём состоит нарушение.
Если проект завершается досрочно
Заранее согласуйте, как стороны передают накопленный результат и заканчивают расчёты:
- Версия и готовность. Как фиксируются текущая версия, выполненные задачи, известные недостатки и незавершённые работы.
- Материалы и доступы. Какие исходники, документы и доступы передаются, в какой срок и кому.
- Расчёты. Как подтверждаются выполненная работа, её стоимость и сумма неотработанного аванса, подлежащая возврату.
- Права. На какие промежуточные результаты и на каких условиях заказчик получает права, может ли он передать их на доработку другой команде.
- Переход к новому исполнителю. Нужны ли пояснения, передача инфраструктуры и дополнительная техническая помощь; как согласуются их объём и оплата.
Промежуточный код может ещё не образовывать самостоятельный работающий продукт. Его состав, состояние и условия использования стоит фиксировать отдельно от приёмки полностью готовой программы.
Для работы с реальными данными заказчика отдельно определяют доступ, цели обработки, тестовые наборы и удаление копий. Подробнее — о передаче персональных данных подрядчику.
Почему с этой задачей обращаются в «Софист»
Работаем с 2016 года. Сопровождаем бизнес и цифровые проекты, сотрудничаем с крупными региональными компаниями. Договорные условия рассматриваем вместе с тем, как стороны будут исполнять обязательства и подтверждать результат.
Есть опыт с разными продуктами. Работали над юридическими документами для веб-сервисов, мобильных приложений, игр, десктопных программ, ИИ-сервисов и Telegram-ботов. Учитываем способ разработки, монетизации и дальнейшего использования продукта.
Связываем несколько направлений права. В комплексных проектах учитываем интеллектуальные права, договорные отношения, персональные данные и корпоративные вопросы. Это важно, когда разработка одновременно затрагивает заказчика, команду, партнёров и будущих пользователей.
Фиксируем условия услуги. До начала работы согласуем документы, результат, стоимость и сроки. Объясняем ключевые положения и вопросы, по которым потребуется ваше решение или согласование с контрагентом.
Соблюдаем конфиденциальность. Сведения о продукте и коммерческих условиях используем для согласованной юридической задачи. При необходимости оформляем отдельное соглашение о конфиденциальности.
Кейс: сопровождение компании-разработчика ПО
Мы сопровождали IT-компанию, разрабатывающую программное обеспечение и решения для умных городов. Работа включала оформление прав на результаты разработки, регистрацию программ, документы по персональным данным и юридическое сопровождение запуска нового цифрового продукта.
Для нового продукта подготовили лицензионный договор и пользовательское соглашение. Договорные документы рассматривались вместе с другими правовыми задачами компании и её технологических проектов.
Благодарственные письма клиентов
Отзывы о сотрудничестве с юридической практикой «Софист»:
ООО «Вайс сити системс»
ООО «МАНТЛ КОД»
Часто задаваемые вопросы
После оплаты права на программу автоматически переходят заказчику?
Универсального правила о переходе только после полной оплаты нет. Нужно учитывать, кто создаёт программу, что составляет предмет договора и как стороны распределили права. Если момент связан с оплатой или приёмкой, это должно быть корректно закреплено в документах.
При почасовой оплате заказчик обязан оплатить любой отчёт разработчика?
Нужно проверить, как согласованы задачи, ставки, лимиты, отчётность и подтверждение выполнения. Односторонняя запись о затраченном времени не решает все вопросы об объёме обязательства. Порядок учёта времени должен соответствовать договору и фактическому процессу работы.
Agile означает, что сроки и результат можно не определять?
Нет. Для меняющихся требований можно согласовать этапы и порядок утверждения новых задач. Нужны правила планирования, проверки, расчётов и изменения объёма. Гибкость разработки обеспечивается этим механизмом, а не одним упоминанием Agile.
Подписание акта исключает любые последующие претензии к программе?
Нет. Значение имеют содержание акта, проведённая проверка, характер недостатка и условия договора. Явные и скрытые недостатки оцениваются по-разному. Обнаруженные при приёмке замечания нужно фиксировать, а о скрытых недостатках — своевременно сообщать исполнителю.
У нас уже есть шаблон. Нужно заказывать новый договор?
Можно начать с проверки. Если документ подходит вашей модели, доработаем спорные условия и недостающие приложения. Если потребуется существенная переработка, объясним причины и согласуем объём. Проверка и доработка договора — от 20 000 рублей.
Можно подготовить один договор для разных проектов студии?
Да, если проекты имеют общую модель работы. Можно подготовить основной договор и формы заданий, этапов и изменений, в которых заполняются параметры конкретного проекта. Для другой схемы оплаты, распределения прав или особых условий заказчика может потребоваться дополнительная проверка.
Крупный заказчик принимает только свой договор. Есть смысл обращаться к юристу?
Да. Проверим его редакцию, выделим наиболее значимые условия и предложим правки или варианты согласования. Если изменить часть положений не получится, объясним их последствия и какие действия важны при исполнении. Участие в переговорах определяем в составе задания.
Разработка уже началась. Можно оформить договор сейчас?
Да. Сначала изучим переписку, согласованные задачи, платежи и переданные результаты. Зафиксируем текущий этап и подготовим условия дальнейшей работы: постановку новых задач, оплату, приёмку и права. Возможность применения условий к уже возникшим отношениям оценим отдельно. Если разногласия уже появились, их урегулирование нужно определить в составе задачи: подписание нового документа само по себе не устраняет спор.