Договор на разработку сайта: что проверить перед подписанием

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

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

Предмет договора и ТЗ как приложение

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

Техническое задание должно быть отдельным приложением, а не абзацем внутри договора. В ТЗ фиксируются структура сайта, перечень функций (форма заявки, каталог, личный кабинет, интеграции с CRM или платёжной системой), адаптивность, требования к скорости загрузки. Если ТЗ появляется уже в процессе работы, у подрядчика будет формальное право сказать, что заказывали именно то, что он сделал.

Для сайта под ключ на типовом стеке сроки и цены такой работы описаны на странице разработки сайтов под ключ.

Этапы, сроки и срыв сроков

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

Разумнее разбивать работу на этапы с отдельными датами: дизайн-макет, вёрстка, программирование, тестирование, сдача. У каждого этапа — свой срок и предъявляемый результат, плюс основание для сдвига (задержка контента или правок со стороны заказчика) и последствия срыва по вине подрядчика — неустойка, право расторгнуть договор, право нанять другого исполнителя за его счёт. Без такого пункта единственный рычаг — общие нормы об ответственности, а это долгий путь через претензию и суд.

Порядок приёмки и что считается недостатком

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

Отдельно стоит развести недостаток и доработку за отдельную плату. Расхождение с ТЗ — недостаток, он исправляется бесплатно. Функционал, которого не было в ТЗ, — новая задача. Без этого разграничения любая правка превращается в спор о том, кто её должен оплачивать.

Гарантийный период

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

В договоре стоит зафиксировать длительность гарантии (на рынке для сайтов такого масштаба это обычно один-три месяца после сдачи) и что она покрывает — ошибки в коде, а не новые пожелания. Без этого пункта обращение после подписания акта формально превращается в новый платный заказ. Проблема, всплывшая уже после гарантии, — отдельная задача, для неё есть услуга доработки сайта от 15 000 ₽.

Передача исходников и доступов

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

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

Права на результат: кому достаются код и дизайн

Это ключевой узел договора, и код с дизайном в нём стоит разводить.

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

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

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

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

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

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

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

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

Порядок расторжения

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

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

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

Частые вопросы

Где взять шаблон договора на разработку сайта?

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

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

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

Нужно ли отдельно прописывать передачу прав, если оплата уже прошла?

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

Что делать, если подрядчик отказывается передавать исходники после сдачи проекта?

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

Можно ли расторгнуть договор, если подрядчик перестал выходить на связь?

Можно, но порядок зависит от условий договора. Отсутствие реакции на претензию в разумный срок обычно расценивается как существенное нарушение обязательств, что даёт право на односторонний отказ. Чёткий срок ответа на претензию в самом договоре сильно упрощает процедуру — без него придётся ориентироваться на общие сроки гражданского законодательства.

Уже держите договор в руках, но не уверены, всё ли в нём на вашей стороне? Пришлите его на разбор перед подписанием — отметим слабые места.