Договор на разработку сайта защищает обе стороны, но читают его обычно по диагонали, а потом удивляются. Разберём, какие пункты в договоре действительно важны владельцу бизнеса, на что смотреть в первую очередь и какие формулировки должны насторожить. Это не юридическая консультация, а практический чек-лист — финальный текст договора всё равно стоит показать юристу.
Договор — часть большого решения о подрядчике. Если вы ещё выбираете исполнителя, посмотрите статью про то, как выбрать разработчика сайта: там про критерии и красные флаги, а здесь — про бумагу, которую вы с ним подпишете.
Предмет договора: что именно вам сделают
Предмет — это описание того, что исполнитель обязан сделать. Формулировка «разработка сайта» слишком общая. Лучше, когда предмет опирается на понятный ориентир: состав страниц, функции, прототип или описание работ. Так обе стороны одинаково понимают, что входит в проект, а что нет.
Мы, например, не требуем тяжёлого технического задания: предмет описывается прототипом главной страницы и составом работ. О том, как устроен сам процесс по шагам, — в статье про этапы создания сайта.
Прототип как основа предмета удобнее громоздкого ТЗ по простой причине: его видно. Текстовое задание на двадцать страниц легко понять по-разному, а кликабельный прототип показывает структуру, экраны и логику так, как они будут на сайте. Заказчик согласовывает то, что видит, а не то, что он вообразил по описанию. Это снимает большую часть споров о том, «так мы договаривались или нет».
Цена и срок: должны быть зафиксированы
Главный вопрос владельца — не вырастет ли цена и не затянется ли срок. В договоре должны быть указаны конкретная стоимость и срок выполнения, а также условия, при которых они могут измениться. Нормально, если доплата возможна за работы, которые вы сами добавляете сверх согласованного. Ненормально, когда базовая цена растёт просто так.
У нас цена и срок фиксируются в договоре и не меняются по ходу работы — это принципиальная позиция. Если по дороге вы захотите добавить, например, интеграцию с CRM, это оформляется отдельной строкой, а не внезапным увеличением счёта.
Насторожить должна формулировка вроде «стоимость определяется по фактически затраченному времени» без потолка. На словах это звучит гибко, на деле означает, что итоговая сумма вам заранее неизвестна и может оказаться любой. Для владельца бизнеса предсказуемость обычно важнее мнимой гибкости: лучше зафиксированная цена с понятным порядком доплат за добавления, чем открытый счёт, который растёт по ходу работы.
| Пункт | Хорошая формулировка | Повод насторожиться |
|---|---|---|
| Цена | Конкретная сумма, условия доплат описаны | «Стоимость определяется по факту» |
| Срок | Даты или рабочие дни по этапам | Срок не указан вовсе |
| Права | Передаются заказчику после оплаты | О правах ни слова |
| Доступы | Домен и сервер оформлены на заказчика | Всё оформлено на исполнителя |
| Поддержка | Срок и условия после запуска описаны | «Поддержка по договорённости» без деталей |
Этапы, оплата и приёмка
Разбивка на этапы с промежуточной оплатой защищает обе стороны. Типичная схема: часть оплаты в начале, часть после запуска. Важно, чтобы каждый этап имел понятный результат, который можно проверить: прототип, тестовая версия по ссылке, финальный сайт.
- Заявка и короткий созвон, чтобы понять задачу.
- Прототип или дизайн, который вы согласуете.
- Разработка с тестовой версией по ссылке.
- Приёмка и запуск, финальная оплата.
- Поддержка в оговорённый срок после запуска.
В договоре полезно описать, как происходит приёмка: по каким критериям сайт считается готовым и сколько времени у вас есть на замечания. Это снимает споры в финале, когда одна сторона считает работу законченной, а другая — нет.
Схема оплаты по этапам защищает обе стороны ещё и психологически. Исполнитель не работает месяц без денег и не бросает проект на полпути, а заказчик не отдаёт всю сумму вперёд и видит промежуточный результат до финальной оплаты. Классический баланс — предоплата в начале и остаток после запуска, иногда с промежуточным платежом после согласования дизайна. Полная оплата вперёд или, наоборот, работа совсем без предоплаты — повод насторожиться с обеих сторон.
Про приёмку важно понимать: без описанного порядка она превращается в бесконечную. Полезно договориться, что после передачи сайта у вас есть, например, несколько рабочих дней на замечания, замечания оформляются списком, а не по одному в день, и что считается недоработкой по договору, а что — новым пожеланием сверх согласованного. Это убирает самый частый конфликт финала проекта.
Передача прав, доступов и исходников
Самый недооценённый блок. По закону исключительные права на созданный сайт по умолчанию остаются у исполнителя, пока договор прямо не передаёт их заказчику. Поэтому в договоре обязателен пункт о передаче вам прав на код и дизайн после оплаты. Подробно эту тему мы разбираем в статье про то, кому принадлежит сайт: код, дизайн, домен.
Отдельно про доступы. Домен и сервер должны быть оформлены на вас как на владельца, а не на исполнителя. Иначе при расставании вы рискуете остаться без адреса сайта. У нас домен и сервер оформляются на клиента — это норма, а не услуга за отдельные деньги.
Полезно, чтобы договор предусматривал передачу не только прав, но и самих рабочих материалов: исходного кода, доступов к хостингу, домену и подключённым сервисам. Право на бумаге без фактических доступов мало что даёт — вы формально владеете сайтом, но не можете им управлять. Поэтому в финале проекта логично зафиксировать актом, что всё перечисленное вам передано, а не ограничиваться устным «всё у вас».
Сайт, права и доступы к которому остались у исполнителя, — это не ваш актив, а аренда с риском потерять всё при любом конфликте.
Поддержка и что после запуска
Хороший договор описывает, что происходит после запуска: сколько длится поддержка, что в неё входит, как считаются доработки дальше. У нас поддержка включена в зависимости от формата сайта, а дальше работаем почасово или абонементом по договорённости. Что обычно нужно делать после запуска, мы собрали в статье про поддержку сайта после запуска.
Важно, чтобы в поддержке было понятно разделение: что исполнитель чинит бесплатно, а что считается новой работой. Если после запуска вылезла ошибка, которой не должно быть, — это гарантийная правка. Если вы хотите добавить новый раздел или функцию — это доработка за отдельные деньги. Когда эта граница описана в договоре, не возникает ощущения, что с вас берут деньги за собственные недочёты исполнителя.
Чек-лист перед подписанием
- Понятен предмет: что именно вам сделают.
- Указаны конкретная цена и срок, описаны условия доплат.
- Есть этапы с промежуточными результатами и порядком оплаты.
- Описана приёмка и срок на замечания.
- Есть пункт о передаче прав на код и дизайн после оплаты.
- Домен и сервер оформляются на вас.
- Описаны условия поддержки после запуска.
Если хотя бы один пункт отсутствует, попросите его добавить до подписания — это нормальная практика. Мы работаем по договору с фиксированной ценой и сроком и передачей прав и доступов заказчику. Опишите задачу на странице корпоративного сайта, и мы пришлём условия, которые можно спокойно показать своему юристу.