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

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

Разбираем пункты, которые действительно решают, в порядке важности.

1. Предмет и объём работ

Самый важный пункт, и почти всегда самый слабый.

В самом договоре обычно написано что-то вроде «выполнить работы по созданию сайта». Это ни о чём: под такую формулировку подходит и лендинг за 30 тысяч, и портал за миллион.

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

Без этого приложения невозможно определить, выполнены обязательства или нет. Как составляется само задание — в статье как составить ТЗ на сайт.

2. Права на результат

Пункт, о котором вспоминают, когда решают сменить подрядчика.

По умолчанию исключительные права на созданное произведение остаются у исполнителя. К заказчику они переходят только если это прямо прописано.

Что проверить:

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

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

3. Порядок и этапы оплаты

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

Полная предоплата лишает вас единственного рычага влияния. Полная постоплата не устраивает исполнителя и обычно означает, что что-то не так с оценкой рисков.

Что проверить: привязаны ли платежи к результатам этапов, а не к календарным датам. Иначе может возникнуть ситуация, когда срок платежа наступил, а этап не сдан.

4. Сроки и что на них влияет

Сроки должны быть привязаны не к календарю, а к последовательности: «дизайн — 15 рабочих дней с момента утверждения прототипа».

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

Самая частая реальная причина срыва сроков — не медленный подрядчик, а незакрытые обязательства с вашей стороны. Что именно тормозит проекты, разбирали в статье этапы разработки сайта.

5. Приёмка

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

Внимательно на пункт об автоматической приёмке. Формулировка «работы считаются принятыми, если заказчик не направил замечания в течение N дней» — стандартная и в целом нормальная. Но убедитесь, что N достаточен для реальной проверки: три дня на приёмку магазина — мало.

Критерии приёмки лучше вынести в приложение: работающие сценарии, список проверенных устройств, метрики скорости. Иначе спор о том, «нормально ли работает сайт», не имеет объективного разрешения.

6. Правки и дополнительные работы

Что считается правкой в рамках договора, а что новой задачей.

Здоровая формулировка: два-три круга правок на этапе дизайна входят в стоимость, изменения объёма оформляются дополнительным соглашением с указанием цены и сдвига срока.

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

7. Гарантия

Что покрывает и сколько длится. Стандартно: 1–3 месяца, в течение которых бесплатно устраняются ошибки, возникшие по вине исполнителя.

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

Гарантия — не то же самое, что поддержка сайта: первая устраняет дефекты, вторая сопровождает и развивает проект.

8. Расторжение

Самый неприятный пункт, о котором думают в последнюю очередь.

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

Ответ должен быть: да, за оплаченные этапы вы получаете результат. Иначе при разрыве на середине вы остаётесь без денег и без наработок.

9. Конфиденциальность и данные

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

Чего в договоре быть не должно

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

Ссылок на несуществующие приложения. Договор упоминает ТЗ, а приложения нет — типичная ситуация, при которой объём работ юридически не определён.

Одностороннего изменения условий. Право исполнителя менять сроки или стоимость без согласования.

Итог

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

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

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