Договор на разработку сайта чаще всего пишет исполнитель, и пишет его в свою пользу - с расплывчатым предметом, без штрафов за срыв сроков и без ясности, кому в итоге принадлежит код. За несколько лет работы с Tilda, WordPress и кастомными веб-сервисами я видел десятки таких шаблонов и знаю, на что заказчик обычно не обращает внимания при подписании, а потом жалеет об этом на середине проекта. Собрал по пунктам, что нужно требовать в договор до того, как поставить подпись.
Предмет договора на разработку сайта: почему формулировки решают всё
Типичная фраза в шаблонах студий - «Исполнитель обязуется разработать сайт в соответствии с пожеланиями Заказчика». Это не предмет договора, а повод для бесконечных споров: пожелания меняются, а формулировка не дает опоры ни одной из сторон.
Предмет должен быть привязан к конкретному результату: количество страниц или экранов, платформа (Tilda, WordPress, кастомная разработка на Laravel или Next.js), список функциональных блоков - каталог, корзина, личный кабинет, интеграция с СДЭК или эквайрингом. Если сайт делается на конструкторе, отдельно фиксируется, что доработки сверх стандартных блоков конструктора (кастомные скрипты, JS-виджеты) оплачиваются отдельно - иначе любое «а можно еще вот так» становится предметом спора о том, входило оно в договор или нет.
Я в своих договорах всегда выношу техническое описание в отдельное приложение, а в теле договора просто ссылаюсь на него: «Исполнитель разрабатывает сайт в соответствии с Техническим заданием (Приложение №1), являющимся неотъемлемой частью договора». Это защищает и меня, и заказчика от разночтений задним числом.
Техническое задание как приложение к договору на создание сайта
Без технического задания договор на разработку сайта превращается в договор о намерениях. ТЗ должно быть приложением с подписью обеих сторон, а не перепиской в мессенджере, на которую потом никто не сможет сослаться.
В ТЗ на практике должно быть закреплено:
- структура сайта - карта страниц, а не абстрактное «многостраничный сайт»;
- список интеграций с указанием конкретных сервисов: эквайринг Т‑Банка для WooCommerce, доставка СДЭК с расчетом стоимости, CRM, вебхуки в Telegram;
- требования к адаптивности и браузерам, в которых сайт обязан корректно работать;
- перечень контента, который предоставляет заказчик, и кто отвечает за его подготовку - тексты, фото, товарные карточки;
- критерии приемки по каждому крупному блоку, а не только по сайту целиком.
Один из частых провалов - заказчик подписывает договор без техзадания, полагаясь на устные договоренности с менеджером. Через два месяца выясняется, что «личный кабинет» в понимании исполнителя - это форма входа, а в понимании заказчика - история заказов, бонусы и повторный заказ в один клик. Спор в такой ситуации решается не в пользу того, кто прав по смыслу, а в пользу того, у кого есть подписанный документ.
Сроки, этапы и штрафы за просрочку
Срок «60 рабочих дней с момента получения предоплаты» без разбивки на этапы - ловушка. Заказчик не может проверить прогресс до самого дедлайна и обычно узнает о срыве сроков в последнюю неделю, когда переносить релиз уже некуда.
В договоре должна быть таблица этапов с датами и результатом каждого этапа - не абстрактным «дизайн готов», а конкретным: макеты всех ключевых страниц утверждены, верстка главной и каталога сдана, интеграции протестированы на тестовом окружении. Я обычно делю крупные проекты на 3-5 этапов с оплатой по факту сдачи каждого - это дисциплинирует обе стороны и снимает риск, что исполнитель возьмет полную предоплату и пропадет на два месяца.
Отдельный пункт - штрафные санкции за просрочку. Практика показывает: 0,1-0,5% от стоимости этапа за каждый день просрочки - рабочая цифра, которая не разоряет исполнителя при небольшой задержке, но заставляет держать сроки. Без этого пункта единственный рычаг заказчика при затягивании проекта - расторжение договора, которое почти всегда дороже и дольше, чем ожидание.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Стоимость, порядок оплаты и что входит в цену
Цена в договоре должна быть привязана к объему работ из ТЗ, а не идти отдельной строкой без расшифровки. Если в договоре просто «150 000 рублей за сайт», при любом расширении объема заказчик не может доказать, что доплата за доработку не входила в изначальную сумму.
Важно закрепить:
- график платежей по этапам, а не 100% предоплату - на рынке нормой считается 30-50% предоплаты, остальное по актам;
- что именно входит в стоимость: домен и хостинг оплачиваются отдельно или включены в проект, тестовые интеграции с платежными системами и службами доставки - это доработка или базовый функционал;
- порядок пересмотра цены при изменении объема - почасовая ставка на доработки сверх ТЗ или фиксированная смета на каждое изменение.
При работе с интернет-магазином на WordPress отдельно прописываю стоимость интеграции эквайринга и доставки, потому что это трудоемкие блоки: настройка вебхуков Т‑Банка под WooCommerce и синхронизация статусов заказов с личным кабинетом СДЭК занимают не один день и не входят в «базовую разработку сайта» ни у одной студии. Если заказчику нужен магазин под ключ с такими интеграциями, разумнее сразу закладывать это в смету, а не выяснять постфактум - у меня подобные проекты идут как разработка интернет-магазина под ключ с интеграциями как частью сметы, а не отдельной допродажей.
Права на код, дизайн и контент после сдачи проекта
Это пункт, который чаще всего отсутствует в шаблонах студий, и именно он бьет по заказчику больнее всего. По умолчанию, если в договоре ничего не сказано об интеллектуальных правах, исключительное право на программный код и дизайн остается у исполнителя - заказчик получает только право использования, причем в объеме, который договор прямо не определяет.
В договоре должно быть явно написано, что исключительные права на весь код, включая кастомные скрипты и доработки, переходят заказчику в момент подписания акта или полной оплаты. Отдельно стоит зафиксировать передачу исходников: не архив с готовым сайтом, а весь репозиторий с историей коммитов, доступы к хостингу и админ-панели переданы на аккаунт заказчика, а не остаются на аккаунте исполнителя «для удобства обслуживания».
Я сталкивался с ситуацией, когда заказчик заказал Telegram-бота на aiogram у фрилансера, получил рабочего бота, но исходный код так и не увидел - фрилансер держал его у себя под предлогом «доработок». Через полгода фрилансер пропал, бот сломался после обновления Telegram Bot API, а чинить было нечего - заказчик оплачивал работу, а не код. Для ботов и автоматизаций на n8n этот пункт даже важнее, чем для сайтов: без исходной логики сценариев второй разработчик будет восстанавливать её с нуля, а не дорабатывать существующую.
Акт приемки-передачи и гарантийный период
Без акта приемки договор формально не закрыт, даже если сайт работает и заказчик им пользуется. Акт должен ссылаться на конкретные пункты ТЗ, которые проверялись при сдаче, а не содержать общую фразу «работы выполнены в полном объеме, претензий нет».
Гарантийный период на исправление ошибок, допущенных при разработке, - стандартная практика, обычно 30-60 дней после подписания акта. Важно разграничить в договоре два разных сценария: исправление багов, возникших по вине исполнителя (не работает форма, съезжает верстка на мобильных), и доработки по новым пожеланиям заказчика - это разные виды работ с разной оплатой. Я не обещаю клиентам бесплатную поддержку после сдачи проекта: гарантия покрывает исправление ошибок разработки, а любые доработки функционала оформляются отдельным ТЗ и оплачиваются по действующим расценкам.
| Раздел договора | Частая ошибка заказчика | Как должно быть |
|---|---|---|
| Предмет договора | Общая фраза без привязки к ТЗ | Ссылка на ТЗ как приложение с подписями сторон |
| Сроки | Один срок на весь проект | Этапы с датами и штрафами за просрочку |
| Оплата | 100% предоплата | 30-50% предоплата + оплата по актам этапов |
| Права на код | Не упомянуты вовсе | Переход исключительных прав по акту, передача исходников |
| Приемка | Акт без конкретики | Акт со ссылками на пункты ТЗ |
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Можно ли подписывать договор на разработку сайта без технического задания?
Можно, но это создает риск для обеих сторон: без ТЗ невозможно объективно определить, выполнены ли обязательства исполнителя. Если студия предлагает начать без ТЗ «чтобы не терять время», это почти всегда означает, что позже объем работ будет трактоваться в её пользу.
Кто должен предоставлять контент для сайта - заказчик или исполнитель?
Это нужно закрепить в ТЗ поэтапно: тексты, фото товаров, юридические документы обычно готовит заказчик, а копирайтинг и подбор изображений - по отдельной смете, если это не входит в базовый пакет. Без этого пункта разработка часто стопорится не по вине исполнителя, а из-за отсутствия контента, при этом простой засчитывается как срыв сроков с обеих сторон одновременно.
Что делать, если исполнитель отказывается передавать исходный код после сдачи проекта?
Если в договоре прямо прописан переход исключительных прав и передача исходников по акту, это прямое основание для претензии и обращения в суд. Если такого пункта нет, доказать право на исходники значительно сложнее - поэтому его нужно вносить в договор до начала работ, а не пытаться получить код постфактум.
Нужен ли отдельный пункт про интеграции с CRM, эквайрингом и доставкой?
Да, и лучше выносить это в отдельный раздел ТЗ с указанием конкретных сервисов. Интеграция СДЭК с расчетом стоимости доставки в реальном времени и настройка эквайринга - это не «пара часов работы», а полноценный этап с тестированием на боевых и тестовых ключах, и в договоре он должен быть отражен отдельной строкой сметы, а не растворяться в общей стоимости сайта.