Беру реальный договор на разработку сайта образец из своей практики и показываю, какие пункты в нём реально защищают заказчика, а какие подрядчики вставляют для вида. За несколько лет работы фрилансером я видел десятки версий таких договоров: от одностраничного шаблона, скачанного за пять минут до дедлайна, до документа на пятнадцать страниц с приложениями, который никто из сторон не читал до конца.
Разница между ними не в объёме текста, а в том, прописаны ли там конкретные вещи: кто и когда подтверждает этапы, что происходит при срыве сроков, кому принадлежит код после оплаты и что считается основанием для отказа принимать работу. Ниже структура, которую я использую сам и рекомендую заказчикам сверять с любым присланным подрядчиком вариантом.
Структура договора на разработку сайта: обязательные разделы
Рабочий договор строится вокруг восьми блоков. Если хотя бы половины из них нет, документ защищает в основном исполнителя, а не заказчика.
- Предмет договора - конкретно, что разрабатывается: сайт-визитка, интернет-магазин, веб-сервис, а не абстрактное «выполнение работ по заданию заказчика».
- Техническое задание как приложение - без него предмет договора остаётся декларацией.
- Сроки по этапам, а не одна финальная дата.
- Стоимость и порядок оплаты, включая, что входит в цену, а что оплачивается отдельно.
- Порядок сдачи и приемки работ с критериями готовности.
- Права на код, дизайн и контент после полной оплаты.
- Ответственность сторон и штрафные санкции за просрочку.
- Реквизиты, контакты и порядок разрешения споров.
Если заказчик получает от подрядчика договор без раздела про права на код или без конкретных сроков по этапам, это повод переписать документ до подписания, а не после первого конфликта.
Техническое задание как приложение к договору на разработку
Самая частая причина затяжных споров - размытое ТЗ. Формулировка «интеграция с CRM» ничего не защищает: под ней можно понимать и синхронизацию контактов раз в сутки, и полноценный обмен заказами в реальном времени. Я в своих договорах прописываю интеграции предметно: например, «эквайринг T‑Bank в связке с WooCommerce», «расчёт стоимости и сроков доставки через API СДЭК», «кастомный скрипт на JavaScript для Tilda под конкретную форму заявки», «телеграм-бот на aiogram с сценарием из пяти шагов» или «автоматизация передачи заявок в n8n между формой на сайте и таблицей».
Конкретика в ТЗ решает две вещи сразу: заказчик понимает, за что платит, а исполнитель не может по ходу проекта объявить согласованную функцию «доработкой сверх сметы». Если ТЗ меняется в процессе, в договоре должен быть пункт про порядок согласования изменений: письменно, с фиксацией новой стоимости и сроков, а не по переписке в мессенджере, которую потом сложно приложить к делу.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Сроки, этапы и штрафы за просрочку
Одна дата сдачи на весь проект - плохой признак. Я разбиваю работу минимум на три-четыре этапа: прототип и дизайн, вёрстка и функционал, интеграции, тестирование и запуск. У каждого этапа своя дата и свой акт. Это даёт заказчику возможность остановить проект после конкретного этапа, если что-то идёт не так, вместо того чтобы ждать финала и обнаружить, что переделывать нужно всё с нуля.
Штрафные санкции за просрочку обычно прописывают в процентах от стоимости этапа за каждый день задержки, например 0,1-0,5% в день с потолком в 10% от суммы договора. Без верхнего предела условие превращается в декларацию: никто не взыскивает штраф, который теоретически может превысить саму стоимость проекта, через суд такое условие часто признают несоразмерным. Отдельно стоит прописать форс-мажор: отключение хостинга у третьей стороны, сбои в работе платёжных систем или API, к которым подключается сайт, не должны автоматически считаться виной исполнителя, но и не должны становиться поводом переносить сроки без объяснений.
Приемка работ и акт приема-передачи сайта
Приемка - это не «заказчик посмотрел и вроде согласен». Это подписанный документ с датой и конкретным результатом.
Акт приема-передачи
К акту должен прилагаться список того, что сдаётся: доступы к хостингу и админке, исходный код, если он передаётся отдельно от рабочей копии на сервере, документация по нестандартным модулям. Без этого списка через полгода будет сложно доказать, что часть функционала вообще существовала на момент сдачи.
Тестовый период после сдачи
Я обычно закладываю в договор 7-14 дней на выявление ошибок после подписания акта, в течение которых заказчик может присылать список найденных багов, а исполнитель обязан их закрыть без дополнительной оплаты. Это не то же самое, что бесплатная поддержка на будущее - речь только про ошибки, допущенные при разработке в рамках уже оплаченного ТЗ, а не про новые доработки.
Права на исходный код и контент после запуска
По статье 1296 ГК РФ исключительное право на программу для ЭВМ или сайт, созданные по заказу, принадлежит заказчику, если договором не предусмотрено иное. На практике многие типовые шаблоны содержат оговорку в пользу исполнителя или размытый предмет договора, и тогда заказчик оплатил разработку, но юридически не может быть уверен, что вправе передать код другому подрядчику для доработки без отдельного согласия автора.
В договоре должно быть прямо написано: исключительные права на код, дизайн-макеты и контент, созданный в рамках проекта, переходят к заказчику с момента полной оплаты. Отдельно стоит упомянуть библиотеки и плагины с открытой лицензией - на них право у исполнителя не возникает и передавать нечего, но список использованных сторонних компонентов в договоре или ТЗ стоит зафиксировать, чтобы не было сюрпризов с лицензионными ограничениями после запуска. Если заказываете разработку сайта под ключ, эту формулировку я включаю в договор сам, до подписания, а не по запросу клиента.
Оплата по договору: схемы и защита от недобросовестного исполнителя
Схема оплаты определяет, кто несёт риск на каждом этапе проекта.
| Схема оплаты | Когда платится | Основной риск |
|---|---|---|
| 100% предоплата | До начала работ | Деньги отданы заранее, результат не гарантирован |
| 50% на старте / 50% после сдачи | Аванс и финальный платёж по акту | Исполнитель может тянуть с последним этапом, зная, что уже получил половину |
| Поэтапная 30/40/30 | По акту на каждом этапе | Самый предсказуемый вариант, риск размазан по срокам, а не сконцентрирован в одной точке |
В договоре стоит прописать и обратную ситуацию: что происходит с уже перечисленным авансом, если заказчик отказывается от проекта на середине без вины исполнителя, и что происходит с оплаченными этапами, если исполнитель пропал или систематически срывает сроки. Без этого пункта спор решается только через суд и, как правило, долго.
Если на сайте будут собираться контакты клиентов через формы или CRM-интеграцию, отдельно стоит зафиксировать, что персональные данные хранятся на серверах в России - это прямое требование статьи 18 152-ФЗ, и подрядчик, предлагающий по умолчанию завести форму на иностранный сервис без такой оговорки, создаёт заказчику риск отдельно от самого договора.
Перед подписанием присланного подрядчиком варианта я обычно советую прогнать его по этому списку самостоятельно или отдать на быструю проверку: часто хватает одной консультации от 3 000 ₽, чтобы найти три-четыре формулировки, которые в реальном конфликте сыграют против заказчика.
Частые вопросы
Нужно ли заверять договор на разработку сайта у нотариуса?
Нет, для договора подряда на разработку сайта нотариальное заверение не требуется по закону. Достаточно письменной формы с подписями сторон и, если это юрлица, печатями при их наличии. Электронная переписка и скан с подписью тоже имеют юридическую силу, если в договоре прямо прописан такой порядок обмена документами.
Что делать, если исполнитель сорвал сроки по договору?
Сначала зафиксировать факт просрочки письменно, сославшись на конкретный пункт и дату из договора, и потребовать выплаты неустойки, если она прописана. Если условие о штрафах отсутствует, можно требовать возмещения убытков по общим нормам ГК РФ, но доказать их размер сложнее, поэтому штрафной пункт стоит включать заранее, а не искать его задним числом.
Кому принадлежат права на сайт, если в договоре ничего не написано про код?
По умолчанию (ст. 1296 ГК РФ) исключительные права принадлежат заказчику, но договор может предусмотреть иное, и тогда права остаются у исполнителя, а заказчик получает только право использовать результат в рамках того, что прямо следует из предмета договора. На практике это означает, что без явного пункта о передаче прав заказчик рискует не суметь легально отдать код на доработку другому разработчику.
Можно ли использовать типовой образец договора на разработку сайта из интернета?
Можно как основу, но не как финальный документ. Такие шаблоны почти всегда без конкретных сроков по этапам, без штрафов с верхним пределом и без чёткого раздела про права на код. Я использую подобные образцы только как каркас, а затем переписываю разделы под конкретный проект и его интеграции.