Договор и планирование

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

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

Редакция ХЭМС30 июля 202613 мин

Коротко

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

Что обязательно зафиксировать до подписания

Договор нужен не для перечисления общих обещаний, а для одинакового понимания результата. Если в документе написано только «разработка современного сайта», стороны по-разному представят количество макетов, адаптивы, интеграции, наполнение и готовность к запуску. Чем сложнее проект, тем важнее приложения: техническое задание, смета, календарный план и критерии приемки.

В российском гражданском праве договор подряда связывает работу с передачей результата заказчику. Для цифрового проекта этим результатом могут быть прототип, дизайн-макеты, исходный код, настроенная CMS, опубликованный сайт и документация. В договоре нужно прямо назвать, что именно передается на каждом этапе.

Условие	Что должно быть понятно	Риск без фиксации
Предмет	Какой продукт и в каком составе создается	Разный объем ожиданий
Этапы	Какой результат передается после каждого шага	Невозможно проверить прогресс
Сроки	Начало, окончание и зависимости	Спор о причинах переноса
Цена	Фикс, диапазон или почасовая модель	Неожиданные дополнительные расходы
Приемка	Критерии, срок проверки и формат замечаний	Бесконечный цикл правок
Права	Кому и когда переходят права на результат	Ограничения при смене команды

Опишите предмет через результат и границы

Предмет лучше раскрывать через пользовательские сценарии и комплект поставки. Вместо «сделать интернет-магазин» укажите: каталог с категориями и фильтрами, карточка товара, корзина, оформление заказа, интеграция оплаты, статусы в админ-панели и события аналитики. Для каждого сценария нужен понятный конечный результат.

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

Макеты, прототипы и примеры не должны заменять спецификацию. Референс показывает направление, но не определяет все состояния интерфейса. Состав лучше сверить с техническим заданием на сайт, где сценарии и критерии готовности описаны отдельно.

Перечень страниц, шаблонов и основных состояний.
Функции, роли, интеграции и источники данных.
Адаптивные разрешения и поддерживаемые браузеры.
Состав контента и ответственный за его подготовку.
Домен, сервер, аналитика, формы и уведомления.
Исходники, документация и доступы при передаче.

Свяжите сроки с этапами и вводными заказчика

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

ГК РФ позволяет фиксировать начальный, конечный и промежуточные сроки работ. Для сайта разумно разбить проект на проектирование, дизайн, разработку, интеграции, тестирование и запуск. После каждого этапа заказчик видит результат и понимает, что должно произойти дальше.

Если дата запуска привязана к выставке или рекламной кампании, в договоре полезно определить минимальный обязательный релиз. Тогда второстепенные функции не блокируют публикацию основной версии.

Бриф и планЗафиксировать задачу, границы первого релиза, риски и ответственных.
ПрототипСогласовать структуру, сценарии и состав интерфейсов до визуального дизайна.
ДизайнПринять ключевые экраны, состояния и адаптивы.
РазработкаПолучать промежуточные версии на тестовом адресе.
ТестированиеПроверить критерии приемки, интеграции и обработку ошибок.
ЗапускПередать доступы, документацию и опубликовать согласованный релиз.

Зафиксируйте цену и порядок изменений

В договоре нужно различать твердую цену, приблизительную оценку и почасовую работу. При фиксированной цене особенно важен точный объем. При time and materials важны ставка, отчетность, лимит периода и правила приоритизации. Смешанная модель может сочетать фиксированные этапы и отдельный бюджет на неизвестные интеграции.

Новые пожелания не должны попадать в проект через переписку без оценки. Рабочая схема проста: запрос описывают, подрядчик называет влияние на стоимость и срок, стороны подтверждают изменение, после чего оно входит в план. Это защищает бюджет и не заставляет команду молча сокращать тестирование.

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

Модель	Когда подходит	Что проверить
Фиксированная цена	Объем и критерии хорошо определены	Исключения и порядок change request
Time and materials	Продукт развивается итерациями	Ставки, лимиты, отчетность и приоритеты
Поэтапный фикс	Большой проект можно разделить	Результат и цена каждого этапа
Гибрид	Есть понятная основа и неизвестные интеграции	Какая часть фиксирована, какая оценивается отдельно

Проверьте права на результат и технические доступы

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

Заказчик должен получить доступ к домену, DNS, хостингу, репозиторию, CMS, аналитике и резервным копиям в согласованном объеме. Критичные аккаунты лучше регистрировать на компанию клиента, а подрядчику выдавать рабочие роли. Так смена команды не превращается в восстановление собственности.

Если подрядчик использует готовые модули, нужно назвать их лицензии и регулярные платежи. Также полезно определить, может ли студия показывать проект в портфолио и какие данные нельзя раскрывать.

Переход прав после полной или поэтапной оплаты.
Список сторонних библиотек, шрифтов, фото и лицензий.
Передача исходного кода и истории репозитория.
Аккаунты домена, сервера, аналитики и внешних сервисов.
Правила публикации кейса и конфиденциальность.
Порядок удаления доступов после завершения работ.

Какие формулировки должны насторожить

Опасна не краткость договора сама по себе, а отсутствие способа проверить обещание. Формулировки «современный дизайн», «полная SEO-оптимизация», «неограниченные правки» и «готовность под ключ» ничего не измеряют без приложения. Замените их конкретным результатом: числом шаблонов, списком событий аналитики, составом технической подготовки или количеством циклов согласования.

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

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

Размытая формулировка	Что запросить вместо нее
Сайт под ключ	Комплект поставки и критерии публикации
SEO включено	Технические настройки, страницы и события
Правки без ограничений	Циклы, сроки ответа и change request
Передача после оплаты	Список исходников, аккаунтов и прав
Поддержка проекта	Срок, канал, SLA и перечень работ

Определите приемку, гарантию и поддержку

Приемка должна проверять согласованный результат, а не субъективное впечатление. Для формы это успешная отправка и получение уведомления, для оплаты — корректные статусы и защита от повторной обработки, для адаптива — работа на указанных разрешениях. Замечание должно ссылаться на критерий, сценарий или макет.

Нужно указать срок проверки, формат списка замечаний и количество циклов исправлений. Ошибка — это несоответствие согласованному требованию. Новая функция или изменение принятого решения оформляется как отдельная задача.

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

Хороший договор не усложняет отношения. Он превращает ожидания в проверяемые результаты и заранее объясняет, что происходит при изменении задачи.

FAQ

Частые вопросы

01Можно ли заключить договор без готового технического задания?

Да. В договоре можно выделить отдельный этап проектирования, результатом которого станет согласованная спецификация. До его завершения фиксируют цель, бюджет этапа, формат результата и порядок оценки дальнейшей разработки.

02Кто должен владеть доменом и хостингом?

Критичные аккаунты лучше оформлять на заказчика. Подрядчик получает необходимые роли на время работы. В договоре или акте передачи перечисляют домен, DNS, сервер, репозиторий, CMS, аналитику и внешние кабинеты.

03Как ограничить бесконечные правки?

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

04Когда переходят права на дизайн и код?

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

05Нужна ли гарантия после запуска?

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

Источники и документация

Материал подготовлен редакцией ХЭМС на основе проектной практики. Цены и технические условия актуальны на дату публикации и уточняются после разбора задачи.

Обсудить проект

Соберем понятный объем до договора

Разберем задачу, выделим этапы, результаты и интеграции. Вы получите основу для сметы и договора без скрытых допущений.