Блог

Договор на разработку сайта: что проверить, чтобы не обжечься

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

Почему проблемы начинаются еще до разработки сайта?

Короткий ответ: потому что стороны договариваются о разном результате.
🟣 Заказчик представляет современный инструмент продаж.
🟣 Подрядчик представляет набор задач, которые необходимо выполнить в рамках бюджета.
Пока ожидания не зафиксированы на бумаге, конфликт практически неизбежен.
В команде Рокет Пони мы придерживаемся простой позиции:

Большинство проблем возникает не из-за плохих исполнителей или плохих заказчиков.


Их причина гораздо банальнее.


Люди по-разному понимают, что именно должно получиться в конце проекта.

Какие ошибки заказчики совершают чаще всего?

Ниже собрали ошибки, которые регулярно становятся причиной конфликтов.

Таблица типичных ошибок

Ошибка
Чем грозит
Нет технического задания
Сайт сделали, но не тот
Нет этапов приемки
Вы увидите результат только в конце
Не определены сроки согласования
Дедлайны становятся бесконечными
Не описан состав работ
Возникают споры «входит или нет»
Нет регламента правок
Проект застревает на бесконечных доработках
Не прописаны допработы
Бюджет начинает расти
Нет передачи доступов
Вы можете потерять контроль над проектом
Не урегулированы права на контент
Возможны претензии правообладателей
Нет передачи исключительных прав
Сайт может оказаться юридически не вашим

Почему техническое задание важнее самого договора?

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

Мне нужен современный сайт

Исполнитель отвечает:

Сделаем

Через два месяца оказывается, что у каждой стороны было собственное понимание слова «современный».
Поэтому техническое задание должно содержать:
  • структуру сайта;
  • перечень страниц;
  • функциональные требования;
  • интеграции;
  • требования к мобильной версии;
  • используемую CMS;
  • описание контента;
  • критерии приемки;
  • дизайн-референсы.
Если требования остались только в мессенджерах, доказать свою правоту в спорной ситуации будет крайне сложно.

Как правильно организовать приемку сайта?

Короткий ответ: принимать поэтапно.
Одна приемка в конце проекта выглядит удобно только на бумаге.
На практике заказчик впервые открывает сайт спустя несколько месяцев разработки и понимает, что ожидал совершенно другой результат.
Гораздо безопаснее разбить работу на этапы:
Этап
Результат
Проектирование
Прототипы и структура
Дизайн
Макеты страниц
Разработка
Готовый функционал
Тестирование
Исправление ошибок
Запуск
Сайт на рабочем домене
Каждый этап должен завершаться актом приемки.
Дополнительно важно предусмотреть:
  • срок проверки результата;
  • требования к мотивированному отказу;
  • порядок корректировки замечаний;
  • механизм подписания одностороннего акта.

Кому на самом деле будет принадлежать сайт?

Короткий ответ: не факт, что вам.
Именно этот момент предприниматели часто упускают из вида.
Многие считают:

Если сайт оплачен, значит он мой

Юридически все может быть намного сложнее.
Сайт состоит из множества объектов:
  • программного кода;
  • дизайна;
  • текстов;
  • изображений;
  • базы данных;
  • шрифтов;
  • подключенных модулей.
У каждого элемента есть свой правообладатель.
Если передача исключительных прав не прописана в договоре отдельно, могут возникнуть серьезные ограничения на использование проекта.

Что должно быть указано в разделе об интеллектуальной собственности?

Обязательно проверьте наличие следующих формулировок:
✅ исключительные права отчуждаются заказчику;
✅ права переходят после подписания акта и оплаты;
✅ вознаграждение за передачу прав включено в стоимость проекта;
✅ подрядчик гарантирует наличие прав у всех привлеченных специалистов;
✅ заказчик может передавать сайт другому подрядчику для дальнейшего развития.

Почему домен должен принадлежать заказчику?

Короткий ответ: потому что домен и есть ваш адрес в интернете.
На практике до сих пор встречаются ситуации, когда домен оформляется:
  • на разработчика;
  • на сотрудника агентства;
  • на фрилансера;
  • на бывшего маркетолога.
Пока отношения хорошие, проблем нет.
Проблемы начинаются при расторжении сотрудничества.
По правилам регистрации владельцем домена считается администратор доменного имени. Именно он обладает основным набором прав по управлению доменом.
Поэтому в договоре должно быть зафиксировано:
  • домен оформляется на заказчика;
  • кабинет регистратора принадлежит заказчику;
  • передача домена регламентирована сроками;
  • данные можно проверить через WHOIS.

Какие доступы нужно обязательно получить после завершения проекта?

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

Доступы к сайту

  • панель управления CMS;
  • FTP или SSH;
  • база данных;
  • репозиторий исходного кода;
  • SSL-сертификаты;
  • API-ключи.

Доступы к инфраструктуре

  • хостинг;
  • домен;
  • DNS;
  • почтовый сервер.

Доступы к маркетингу

  • Яндекс Метрика;
  • Google Analytics (если используется);
  • рекламные кабинеты;
  • системы коллтрекинга.
Отдельно рекомендуем оформить акт передачи доступов. Это избавит обе стороны от лишних споров в будущем.

Почему бесплатные правки могут стать проблемой?

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

Нужно ли отдельно прописывать работу с персональными данными?

Короткий ответ: обязательно.
Сегодня практически каждый сайт собирает персональные данные:
  • заявки;
  • телефоны;
  • электронную почту;
  • формы обратной связи;
  • данные аналитики.
Поэтому сайт автоматически попадает в сферу действия законодательства о персональных данных.
Минимум, который необходимо проверить:
✅ политика обработки персональных данных;
✅ согласие на обработку данных;
✅ корректная работа форм;
✅ cookie-баннер;
✅ порядок передачи данных подрядчику.
Этот вопрос многие воспринимают как формальность до первой проверки или инцидента.

Что проверить перед подписанием договора?

Практический чеклист

Перед тем как поставить подпись, убедитесь, что:
✅ ТЗ подготовлено и подписано.
✅ Есть этапы разработки.
✅ Есть этапы приемки.
✅ Зафиксированы сроки согласования.
✅ Прописан состав работ.
✅ Определен порядок правок.
✅ Есть механизм дополнительных работ.
✅ Передаются исходные коды.
✅ Передаются все доступы.
✅ Домен оформляется на вас.
✅ Хостинг принадлежит вам.
✅ Лицензии оформляются на вас.
✅ Аналитика на ваших аккаунтах.
✅ Рекламные кабинеты на ваших аккаунтах.
✅ Есть гарантийный период.
✅ Исключительные права отчуждаются.
✅ Урегулирован вопрос персональных данных.
✅ Есть порядок расторжения договора.
✅ Указана ответственность сторон.

Что важнее: найти идеальный договор или идеального подрядчика?

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

Вывод

Договор на разработку сайта не должен состоять из трех страниц общих фраз.
Чем подробнее описаны ожидания, сроки, права, обязанности и порядок взаимодействия, тем меньше вероятность конфликта.
Особое внимание стоит уделить пяти пунктам:
  1. Техническое задание.
  2. Этапы приемки.
  3. Исключительные права.
  4. Домен и доступы.
  5. Персональные данные.
Именно вокруг них сегодня возникает большинство серьезных споров при разработке сайтов.

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

Что делать дальше, если всё понятно, но в итоге не очень)))

Если вы планируете разработку нового сайта, смену подрядчика или хотите проверить текущий договор на скрытые риски, команда Рокет Пони поможет посмотреть на ситуацию глазами маркетологов, разработчиков и бизнеса одновременно.
Иногда один вовремя замеченный пункт в договоре способен сохранить сотни тысяч рублей и несколько месяцев нервов.
Записывайся на бесплатную часовую консультацию, а для жителей Тулы и гостей нашего города есть возможность прийти к нам в офис, выпить кофе и спокойно обсудить текущие задачи бизнеса, сайт, маркетинг и возможные точки роста. Предварительная запись обязательна — мы работаем, а не сидим в ожидании гостей.
Вы можете связаться с нами любым удобным способом:
2026-09-22 16:49 Юридические вопросы