Договор разработки сайта: приёмка работ и права на код

Почему разработка сайта — это особый вид договора

Допустим, вы заплатили разработчику 200 000 рублей за корпоративный сайт, получили готовый продукт, подписали акт. А через год разработчик вдруг предъявляет претензию: «Сайт принадлежит мне как автору, потому что в договоре не прописана передача прав». Звучит абсурдно — но именно такие ситуации регулярно рассматриваются в судах.

Договор на создание сайта — один из самых сложных в практике малого бизнеса. Он одновременно затрагивает три блока гражданского права: нормы о подряде (гл. 37 ГК РФ), нормы об оказании услуг (гл. 39 ГК РФ) и нормы об интеллектуальной собственности (часть IV ГК РФ, ст. 1225–1551). Типовой шаблон из интернета, где написано «исполнитель разрабатывает сайт, заказчик оплачивает» — это договор ни о чём. Чтобы составить его правильно, нужно понимать, какие нормы применяются и в чём их различие.

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

Подряд или услуги: от выбора зависит сумма потерь при расторжении

Договор на разработку сайта юридически относят либо к договору подряда (гл. 37 ГК РФ), либо к договору возмездного оказания услуг (гл. 39 ГК РФ). На практике стороны часто используют смешанный вариант или вовсе не задумываются над этим вопросом — и потом расплачиваются разницей в возмещении убытков.

Договор подряда предполагает, что важен конкретный материальный результат: подрядчик выполняет работу и передаёт её заказчику (ст. 702 ГК РФ). Если заказчик отказывается от договора до завершения работ, он обязан оплатить уже выполненную часть и возместить убытки в разнице до общей цены (ст. 717 ГК РФ). Иными словами — доплатить, даже если работа его больше не интересует.

Договор оказания услуг сделан иначе: важен процесс, а не только результат. При отказе заказчика от услуг ему достаточно оплатить лишь фактические расходы исполнителя (ст. 782 ГК РФ). С точки зрения заказчика — это выгоднее. Именно поэтому опытные разработчики настаивают на квалификации как «договор подряда» — она выгоднее для них. Прямо укажите в договоре, нормы какой главы применяются при возникновении споров.

Техническое задание: фундамент, без которого всё рассыплется

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

Хорошее ТЗ для договора разработки сайта включает: описание функциональных разделов, требования к дизайну (со ссылками на референсы), перечень браузеров и устройств, на которых сайт должен корректно отображаться, требования к скорости загрузки, SEO-требования, если предусмотрены. Желательно — прототипы страниц в виде приложения.

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

Ещё один важный момент: ТЗ должно содержать критерии приёмки — измеримые, а не оценочные. Например, не «сайт должен быстро работать», а «время загрузки главной страницы не более 3 секунд по инструменту Google PageSpeed Insights». Не «дизайн должен быть современным», а «дизайн разрабатывается в соответствии с брендбуком, предоставленным Заказчиком (Приложение № 2)». Только такие критерии дают возможность объективно проверить результат при приёмке.

Кому принадлежит сайт после оплаты: главный вопрос договора

Сайт — это объект авторского права. Он представляет собой совокупность нескольких охраняемых произведений: программный код, дизайн, графические элементы, тексты. У каждого из них есть автор, и именно у автора возникают исключительные права с момента создания (ст. 1255, 1259 ГК РФ).

Если исполнитель — организация или ИП (не физическое лицо-автор), применяется ст. 1296 ГК РФ: исключительное право принадлежит заказчику, если договором не предусмотрено иное. Если исполнитель — физическое лицо-автор, применяется договор авторского заказа (ст. 1288 ГК РФ), и условия передачи прав нужно прописывать отдельно. Используйте образец договора авторского заказа в случае, если вы работаете напрямую с фрилансером-физлицом.

Критически важно: личные неимущественные права автора (право авторства, право на имя) не отчуждаются никогда — ни по договору, ни по закону (ст. 1255 ГК РФ). То есть даже купив все имущественные права, вы не можете требовать от разработчика «убрать своё имя» из кода. Это нормально и на практике не мешает бизнесу.

Формулировка о передаче прав: как написать, чтобы не оспорили

Самая распространённая ошибка — писать в договоре «права на сайт переходят к заказчику после оплаты» без конкретизации, какие именно права и в каком объёме. Суд может истолковать такую формулировку как передачу только права использования (лицензию), но не исключительного права. А это означает, что разработчик сохраняет право продавать аналогичный код другим клиентам.

Рабочая формулировка: «После подписания акта сдачи-приёмки и полной оплаты Заказчику передаются исключительные права на все результаты работ, созданные Исполнителем в рамках настоящего договора, в полном объёме, на весь срок их действия, на территории всего мира (ст. 1296 ГК РФ). Вознаграждение за передачу исключительных прав включено в стоимость работ по настоящему договору.»

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

Поэтапная оплата: как структурировать платежи, чтобы не потерять всё

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

Распространённая практика: аванс 30–50% при подписании договора, промежуточные платежи по итогам утверждённых этапов, остаток 20–30% после подписания итогового акта. Каждый этап должен иметь чёткое описание в ТЗ и срок сдачи. Это мотивирует обе стороны держать процесс в тонусе — заказчик вовремя проверяет промежуточные результаты, разработчик не уходит в долгострой.

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

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

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

Перед подписанием акта проверьте: соответствие функционала ТЗ, корректное отображение на мобильных устройствах, скорость загрузки, работу форм обратной связи и CTA-кнопок, наличие SSL-сертификата. Если нашли несоответствия — составьте мотивированный отказ с подробным перечнем замечаний. Абстрактная фраза «сайт не нравится» не считается мотивированным отказом.

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

Молчание как согласие: дедлайн на мотивированный отказ

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

На практике это выглядит так: разработчик присылает письмо «Сайт готов, прошу принять», заказчик две недели молчит (занят, в отпуске, просто тянет). Потом разработчик выставляет счёт и заявляет, что работа принята. Суды поддерживают такую позицию, если в договоре прописан разумный срок на возражения — обычно 5–10 рабочих дней.

Поэтому для заказчика важно: во-первых, прописать в договоре конкретный срок проверки (5–10 рабочих дней — разумный компромисс), во-вторых, назначить ответственного сотрудника, который в этот срок реально проверит сайт по ТЗ и пришлёт замечания в письменной форме (электронная почта подойдёт, если это предусмотрено договором).

Важный нюанс: мотивированный отказ должен содержать конкретный перечень недостатков со ссылкой на пункты ТЗ. Фраза «нам не нравится дизайн» — не мотивированный отказ. Хороший отказ звучит так: «Пункт 5.3 ТЗ требует адаптивной вёрстки для экранов 320px — при проверке на iPhone 12 горизонтальный скролл присутствует. Пункт 8.1 ТЗ: форма обратной связи не отправляет письмо на admin@company.ru». Такой отказ невозможно проигнорировать, и он создаёт чёткое задание для доработки.

Что остаётся у разработчика: CMS, фреймворки и «технологическая кухня»

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

В чём проблема? Если разработчик использовал собственную проприетарную CMS и у вас нет на неё лицензии, вы не сможете самостоятельно или силами другого подрядчика вносить изменения в сайт без согласия разработчика. Это типичный «вендорный замок»: вроде бы вы купили сайт, но бесконечно зависите от одного поставщика.

Решение простое: либо настаивайте на использовании открытых CMS (1С-Битрикс, WordPress, OpenCart), либо требуйте включить в договор лицензию на использование проприетарной системы, либо получите исходный код с правом его доработки. Лицензионные правоотношения регулирует лицензионный договор на программное обеспечение — он может стать отдельным приложением к основному договору, если CMS — собственная разработка студии.

Гарантийный период: что важно прописать в договоре

Гарантийный срок — это период, в течение которого разработчик обязан бесплатно устранять недостатки, выявленные после приёмки. Без чёткой формулировки в договоре любая постгарантийная переписка превращается в спор о том, что является «недостатком», а что — «новым заданием».

Рекомендуемый минимум в договоре: срок гарантии (обычно 3–12 месяцев с даты подписания итогового акта), чёткое определение, что является гарантийным случаем (ошибки в коде, несоответствие ТЗ), что им не является (ошибки из-за действий заказчика, форс-мажор, несовместимость с добавленными заказчиком плагинами), срок устранения критических и некритических багов (например, 24 часа и 5 рабочих дней соответственно).

Обратите внимание: гарантийный период — это не техническая поддержка. Поддержка (добавление новых разделов, обновление контента, SEO-правки) оказывается по отдельному договору. Смешивать их в одном разделе — значит создавать почву для споров: заказчик считает, что правки в рамках «поддержки» включены в гарантию, разработчик уверен, что гарантия закончилась. Разграничьте понятия в договоре явно, и обе стороны сэкономят нервы.

• Гарантийный срок — 3–12 месяцев, прописать явно
• Критические баги (сайт недоступен) — устранение в течение 24 часов
• Некритические ошибки — устранение в течение 5 рабочих дней
• Поддержка и доработки — отдельный договор или допсоглашение
• Гарантия не распространяется на изменения, внесённые заказчиком

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

Ответственность сторон: штрафы и ограничение убытков

В договоре на разработку сайта важно предусмотреть взаимную ответственность. Со стороны разработчика: неустойка за нарушение сроков сдачи этапов или итогового результата (обычно 0,1–0,5% от стоимости этапа за каждый день просрочки). Со стороны заказчика: неустойка за задержку предоставления исходных материалов и за просрочку оплаты.

Ограничение ответственности — стандартная оговорка в договорах с разработчиками: «Ответственность сторон ограничена стоимостью работ по соответствующему этапу». Это защищает разработчика от требований о возмещении упущенной выгоды, которые в IT-спорах могут быть астрономическими. Заказчику стоит настаивать на исключении из этого ограничения случаев нарушения прав интеллектуальной собственности — они должны возмещаться в полном объёме.

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

Расторжение договора: разные последствия в зависимости от типа

При расторжении договора по инициативе заказчика последствия зависят от того, как вы квалифицировали договор. По договору подряда (ст. 717 ГК РФ): оплата выполненной части работ и возмещение убытков в разнице между общей ценой и уже оплаченной суммой. По договору оказания услуг (ст. 782 ГК РФ): только возмещение фактических расходов исполнителя. Разница для заказчика может быть очень существенной.

При расторжении по инициативе разработчика ситуация зеркальная. По договору подряда (ст. 719 ГК РФ) разработчик может приостановить или отказаться от работ, если заказчик не предоставил необходимые материалы или не оплатил аванс. По договору услуг — исполнитель может отказаться при условии возмещения заказчику убытков (ст. 782 ГК РФ).

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

Типичные ошибки заказчиков при заключении договора

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

Третья ошибка — домен зарегистрирован на разработчика. Это создаёт риск шантажа: при конфликте разработчик «удерживает» домен, и сайт становится недоступен. Всегда регистрируйте домен на себя (или переоформляйте сразу после заключения договора). Четвёртая — в договоре нет порядка передачи исходников и доступов (FTP, хостинг, панель администратора). После разрыва отношений разработчик может отказать в передаче доступов, и заставить его сделать это в суде — долго и дорого.

• Нет ТЗ или оно написано «на коленке»
• Не прописана передача исключительных прав
• Домен зарегистрирован на разработчика
• Не указан срок гарантии и порядок устранения багов
• Не предусмотрен порядок передачи доступов при расторжении

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

Итоговый чеклист: что проверить до подписания договора

• Прописан тип договора — подряд или услуги?
• ТЗ является неотъемлемым приложением с подписями сторон?
• Передача исключительных прав сформулирована явно?
• Указано, что вознаграждение за права включено в стоимость?
• Домен зарегистрирован на заказчика или предусмотрена передача?
• Прописана поэтапная оплата с привязкой к результатам?
• Указан срок на мотивированный отказ (5–10 рабочих дней)?
• Есть условие об «автоматической» приёмке при молчании?
• Прописан гарантийный срок и порядок устранения дефектов?
• Указаны CMS и библиотеки, используемые в разработке?
• Разработчик дал гарантию чистоты использованных материалов?
• Предусмотрен порядок передачи доступов при расторжении?
• Ответственность сторон за нарушение сроков и оплаты прописана?

Если все 13 пунктов закрыты — договор можно подписывать. Если нет — возвращайтесь к переговорам. Разработать полный пакет документов (договор + ТЗ + акт) можно составить онлайн на Договор.ру, или скачать готовые образцы в разделе все категории договоров. А если вы уже работаете с разработчиком и хотите урегулировать дополнительные условия, оформите их через шаблон дополнительного соглашения к договору — это быстрее и надёжнее, чем переписывать весь договор.

Автор статьи: Мария Губина (юрист)