Кабинет

Главная
Статьи
Договор разработки сайта: приёмка работ и права на код

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

Автор статьи, юрист (г. Курск)

Коротко

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

Проверено: октябрь 2026

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

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

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

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

Сравнение договора подряда и договора оказания услуг

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

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

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

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

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

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

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

Если ТЗ отсутствует или составлено в стиле «нужен современный красивый сайт», доказать требования к результату значительно сложнее. Но разработчик не получает права сдать любой результат: качество должно соответствовать договору, а при неполноте его условий — обычно предъявляемым требованиям (ст. 721 ГК РФ). Поэтому при заключении договора настаивайте на детальном ТЗ как согласованном приложении.

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

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

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

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

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

Таблица распределения прав на сайт между заказчиком и разработчиком

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

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

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

Обратите внимание на оговорку о вознаграждении. В возмездном договоре об отчуждении исключительного права нужно согласовать размер вознаграждения или порядок его определения: иначе договор считается незаключённым. Можно прямо указать, что вознаграждение включено в согласованную цену работ. Безвозмездное отчуждение возможно не во всех случаях: между коммерческими организациями оно запрещено (п. 3 и 3.1 ст. 1234 ГК РФ). Правило о первоначальной принадлежности прав заказчику по ст. 1296 ГК РФ нужно отличать от отдельного договора отчуждения.

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

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

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

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

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

Акт приёмки — ключевой документ. По общему правилу с принятия результата начинается гарантийный срок, а момент перехода исключительного права определяется законом и договором. Подписание акта не прекращает обязанности устранять недостатки: значение имеют оговорки о явных дефектах, скрытый характер недостатков и сроки их обнаружения (ст. 720, 723, 724 ГК РФ). Подписывать акт «для галочки», не проверив сайт по ТЗ, — распространённая и дорогостоящая ошибка.

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

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

Схема процесса приёмки работ по договору разработки сайта

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

В договоре можно предусмотреть срок проверки и последствия отсутствия мотивированных возражений после подтверждённой передачи результата. Но молчание само по себе не доказывает, что работа выполнена надлежащим образом. Пункт 4 ст. 753 ГК РФ касается оформления сдачи строительных работ односторонним актом, а не устанавливает универсальную автоматическую приёмку любого сайта. Для разработки сайта подробно согласуйте порядок передачи и проверки результата с учётом ст. 720 ГК РФ.

Например, разработчик присылает письмо «Сайт готов, прошу принять», заказчик две недели молчит, а разработчик выставляет счёт. Одной оговорки о сроке на возражения недостаточно, чтобы считать любую работу принятой. Значение имеют фактическое выполнение работ, подтверждённая передача согласованного результата и документов, соблюдение договорного порядка приёмки и отсутствие обоснованных возражений заказчика. Срок на проверку, например 5–10 рабочих дней, стоит согласовать в договоре; сам по себе он не заменяет доказательств исполнения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чеклист для проверки договора на разработку сайта

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

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

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

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

Короткий вывод

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