Конструктор договора на разработку сайта (ПО)

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

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

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

Самый опасный шаблон — не тот, который короткий, а тот, который создает иллюзию, будто все важное уже урегулировано.

2. Как правильно определить правовую природу такого договора

С точки зрения ГК РФ договор на разработку сайта или программного обеспечения редко укладывается в одну «чистую» модель. Обычно его основа — подряд: исполнитель выполняет работу и передает ее результат, а заказчик принимает и оплачивает. Но вместе с этим в договор часто включают элементы возмездного оказания услуг: консультации, наполнение контентом, тестирование с участием команды заказчика, техподдержку, сопровождение после запуска, обучение сотрудников. Свобода договора позволяет соединять такие элементы в одном документе.

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

На практике безопаснее всего использовать смешанный договор, в котором каждый блок назван своим именем. Тогда суду проще понять, какое правило ГК РФ применять к конкретному спору: о сроках, приемке, оплате, недостатках или правах на результат.

3. Предмет договора: что именно должно быть создано

По статье 432 ГК РФ договор считается заключенным, если стороны достигли соглашения по всем существенным условиям. Для разработки сайта ключевое условие — предмет. Формулировка «исполнитель обязуется разработать сайт» слишком размыта. Из нее невозможно точно понять, идет ли речь о лендинге, интернет-магазине, корпоративном сайте, веб-сервисе, личном кабинете, маркетплейсе, админ-панели, мобильном backend, API-модуле или сложной информационной системе.

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

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

Если предмет описан общими словами, заказчик начинает ждать один результат, а исполнитель — сдавать другой. В IT-проектах это происходит постоянно: заказчик считает, что «сайт» уже включает личный кабинет, CRM-интеграцию, мультиязычность и SEO-подготовку, а исполнитель исходит из того, что речь шла только о frontend-части. Поэтому предмет лучше раскрывать через основную формулировку в договоре и через приложение с функциональным описанием.

4. Техническое задание: почему без него даже хороший образец часто не работает

На практике именно ТЗ делает договор рабочим. Можно скачать очень подробный шаблон, можно использовать конструктор, можно взять типовой образец у знакомых, но без технического задания такой документ все равно остается полуфабрикатом. В договоре должно быть прямо написано, что ТЗ, спецификация, roadmap, backlog или иной согласованный документ являются неотъемлемой частью договора. Иначе предмет и критерии приемки останутся размытыми.

В ТЗ обычно фиксируют:

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

Здесь есть важная правовая тонкость. Если вы хотите, чтобы на результат действовала статья 1296 ГК РФ о произведении, созданном по заказу, из договора и приложений должно быть видно, что предметом соглашения является именно создание соответствующего результата. Если же договор написан так, будто исполнитель просто оказывает набор услуг или выполняет абстрактные работы, а программа или сайт появляются как побочный итог, возрастает риск спора уже в логике статьи 1297 ГК РФ. Для заказчика это крайне нежелательно, если он рассчитывает получить максимально ясный правовой титул на код и иные материалы.

5. Сроки выполнения работ и этапность

Статья 708 ГК РФ требует указывать в договоре подряда начальный и конечный сроки выполнения работы. По соглашению сторон могут быть предусмотрены и промежуточные сроки. Для разработки сайта это особенно важно, потому что IT-проект редко сдается одной датой «под ключ». Намного надежнее разбить его на этапы: аналитика, прототип, дизайн, frontend, backend, интеграции, тестирование, релиз, передача исходников и доступов.

Этапность полезна не только для управления проектом, но и для юриста. Благодаря ей проще:

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

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

6. Цена договора и как отделить основные работы от доработок

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

Если стороны используют лицензионную модель, надо помнить о пункте 5 статьи 1235 ГК РФ. Возмездный лицензионный договор без условия о размере вознаграждения или порядке его определения может быть признан незаключенным, если в нем не указано, что он безвозмездный. Поэтому, когда договор совмещает разработку и предоставление права использования, безопаснее отдельно прописать, что входит в цену работ, а что относится к предоставлению прав. Этот вывод подтвержден и в пункте 40 Постановления Пленума Верховного Суда РФ от 23.04.2019 № 10.

Чаще всего в практике встречаются три модели оплаты:

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

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

7. Приемка результата: акт, тестирование и мотивированный отказ

Статья 720 ГК РФ — одна из ключевых норм для таких договоров. Заказчик обязан осмотреть и принять результат работы в сроки и в порядке, которые предусмотрены договором, а при обнаружении недостатков заявить о них подрядчику. Из этой нормы для IT-договора вытекает очень практичное правило: в договоре мало написать «стороны подписывают акт». Нужно описать, как именно проходит проверка результата.

Обычно имеет смысл урегулировать:

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

По пунктам 2–4 статьи 720 ГК РФ заказчик, обнаруживший недостатки при приемке, вправе ссылаться на них, если они оговорены в акте или ином документе о приемке; если работа принята без проверки, заказчик обычно лишается права ссылаться на явные недостатки; о скрытых недостатках нужно сообщить подрядчику в разумный срок после их обнаружения. Это значит, что для цифрового проекта особенно важно фиксировать результаты тестирования письменно, а не устно в чате.

Судебная практика также показывает значение мотивированного отказа. В определении Судебной коллегии по экономическим спорам Верховного Суда РФ от 24.02.2022 № 305-ЭС21-22419 по делу № А40-94872/2020 подтвержден общий подрядный подход: односторонний акт приемки может быть опровергнут, если мотивы отказа от его подписания признаны обоснованными. Для IT-споров это не специальное правило только о сайте, но очень полезный ориентир: если заказчик не принимает этап, у него должен быть не общий эмоциональный ответ, а конкретный перечень дефектов, несоответствий ТЗ и воспроизводимых ошибок.

Чем сложнее цифровой продукт, тем слабее работает формула «не понравилось — не принимаем».

8. Кому принадлежат права на сайт, код, дизайн и базу данных

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

Статья 1228 ГК РФ прямо говорит, что автором результата интеллектуальной деятельности признается гражданин, творческим трудом которого создан такой результат. Это означает, что сама по себе компания не является автором в личном смысле, хотя может быть правообладателем. Поэтому, если исполнитель — студия или IT-компания, для заказчика важны заверения о том, что исполнитель получил необходимые права от работников и привлеченных лиц и вправе передать или предоставить их заказчику в согласованном объеме.

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

9. Отчуждение права или лицензия: что выбрать

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

Если выбрана лицензия, по статье 1235 ГК РФ лицензиат может использовать результат только в тех пределах и теми способами, которые прямо предусмотрены договором; право использования, не указанное прямо, не считается предоставленным. Поэтому в договоре важно назвать хотя бы основные параметры:

вид лицензии: исключительная или простая;

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

Постановление Пленума Верховного Суда РФ от 23.04.2019 № 10 подтверждает, что отсутствие в возмездном лицензионном договоре условия о размере вознаграждения или порядке его определения при отсутствии прямого указания на безвозмездность ведет к риску признания договора незаключенным. Для договора на разработку сайта это особенно важно тогда, когда стороны вроде бы «продают результат», но юридически оформляют именно лицензию.

10. Что именно надо передать заказчику помимо акта

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

Обычно в состав передачи включают:

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

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

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

11. Баги, недостатки, гарантия и техподдержка — почему это не одно и то же

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

Статья 723 ГК РФ регулирует последствия ненадлежащего качества работы. Если результат выполнен с недостатками, заказчик может требовать безвозмездного устранения, соразмерного уменьшения цены или возмещения своих расходов на исправление, когда такое право предусмотрено договором. Но это не означает, что подрядчик обязан бесплатно реализовывать новые функции, которых изначально не было в ТЗ.

Поэтому в договоре нужно отдельно определить:

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

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

12. Персональные данные, конфиденциальность и доступ к реальным базам

Если сайт собирает заявки, анкеты, контакты клиентов, данные сотрудников или ведет личные кабинеты пользователей, проект почти неизбежно затрагивает Закон о персональных данных. И здесь ошибка многих заказчиков в том, что они вспоминают об этом только после запуска. На самом деле соответствующие обязанности нужно распределять уже в договоре разработки. Статья 18.1 Закона № 152-ФЗ требует от оператора принимать меры, необходимые и достаточные для выполнения обязанностей по закону, а статья 19 — правовые, организационные и технические меры для защиты персональных данных.

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

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

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

13. Можно ли просто скачать шаблон и подписать его без серьезной доработки

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

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

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

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