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

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

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

Почему «типовой договор» — самое опасное место

Споры вокруг сайтов возникают не столько из-за недобросовестности, сколько из-за того, что стороны по-разному понимают слово «сайт». Заказчик держит в голове инструмент, который приносит заявки. Исполнитель — набор макетов и свёрстанных страниц. Договор на полторы страницы с предметом «услуги по разработке сайта» подходит обоим пониманиям, а значит, не решает ни одного будущего спора.

Сюжеты, которые повторяются на форумах предпринимателей, однотипны: предоплата ушла, менеджер перестал отвечать; «месяц по договору» превратился в полгода; итог вышел дороже сметы на 20–40%; после сдачи оказалось, что войти в админку нельзя, а домен зарегистрирован на исполнителя. Общая черта у всех — в договоре не было пункта, описывающего такой случай.

Что проверить по пунктам

Предмет и приложение с техническим заданием

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

Проверяется три вещи: приложение существует физически, а не «будет согласовано позднее» (эта формулировка означает, что предмет не определён); в ТЗ перечислены страницы, а не разделы в общих словах; указано, кто пишет ТЗ и оплачивается ли эта работа отдельно.

Когда ТЗ на момент подписания ещё нет, разумный вариант — два договора. Первый на проектирование: результат — согласованное ТЗ и смета. Второй на разработку по этому ТЗ. Так крупная предоплата не уходит за работу, объём которой ещё никто не знает.

Этапы разработки сайта и порядок оплаты

Создание сайта распадается на этапы: ТЗ, прототип структуры, дизайн, вёрстка и сборка, наполнение и интеграции, тестирование и запуск. Разбивка бывает разной, принцип один — каждый этап заканчивается материальным результатом, который можно посмотреть и принять.

У каждого этапа в договоре должны быть три параметра: результат, срок в рабочих днях, сумма. Оплата привязана к закрытию этапа, а не к календарю. Схема «70% предоплаты, 30% по готовности» — это не этапы, а аванс, после которого спешить незачем.

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

Что считается сдачей и как работает приёмка

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

Важны детали. Замечания принимаются только по несоответствию ТЗ — иначе правки становятся бесконечными, и это бьёт уже по исполнителю. Молчание дольше N дней приравнивается к приёмке; пункт справедливый, но N должен быть реалистичным — трёх рабочих дней на проверку интернет-магазина мало.

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

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

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

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

Доступы, домен и хостинг

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

В договоре перечисляется, что передаётся при сдаче: панель регистратора домена, хостинг или аккаунт конструктора, админка на правах владельца, системы аналитики, почта на домене, платёжный модуль. Список сильнее формулировки «передаются логины и пароли». Отдельный пункт — передача происходит до последнего платежа, а не после. Зависимость от подрядчика начинается не с кода, а с доступов: пока вход есть только у одной стороны, договорённости держатся на доброй воле.

Срыв сроков

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

Гарантийный период

Гарантия на сайт — устранение дефектов, а не бесплатные доработки. Нужны срок (типично 1–6 месяцев с даты приёмки), определение дефекта как несоответствия ТЗ, выявленного после сдачи, и срок реакции. Явно исключаются изменения, внесённые заказчиком или третьими лицами, сбои у хостинга и внешних сервисов, новые пожелания. Дальше гарантии начинается поддержка — отдельный договор с отдельной ценой, о котором лучше договориться заранее.

Сколько стоит и от чего зависит

Публичных прайсов у практики Dodigi нет. Ориентиры ниже взяты из опубликованных прайсов студий — они показывают порядок цифр на рынке.

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

Для калибровки сроков: витрина услуг лаборатории ОК Оригинал запускалась за месяц; интернет-магазин анализов воды ОК Вода и сайт услуг ТСК Лаборатория — за два месяца каждый. Восемь страниц Getsman на своём коде собрались за два дня, но там не было ни каталога, ни оплаты.

На что смотреть: типичные ошибки

• Предоплата больше половины при отсутствии ТЗ. Аванс должен быть соразмерен первому этапу, а не всему проекту.
• Сроки без учёта согласований. Проект длится ровно столько, сколько заказчик отвечает на вопросы. Без пункта о продлении спор о виновнике опоздания не имеет решения.
• Нет пункта о доступах. Сайт сдан, деньги уплачены, войти нельзя — чинится только переговорами.
• Домен на исполнителе. Проверяется до подписания, а не после запуска.
• Расплывчатый объём правок. «Доработки по замечаниям заказчика» без ограничения по итерациям и по соответствию ТЗ приводят к тому, что этап не закрывается никогда.
• Нет исходников дизайна. Свёрстанные страницы отдали, файлы макетов — нет; следующий подрядчик начнёт с нуля.
• Контент вне договора. Кто пишет тексты и откуда берутся фотографии — самый частый источник простоя. Пункт «контент предоставляет заказчик» справедлив, но требует срока.

Вопросы и ответы

Где взять образец договора на разработку сайта? Образцы есть в открытом доступе, но брать их целиком не стоит: большинство написано под интересы исполнителя и слабо ровно в тех местах, что разобраны выше. Разумный порядок — взять образец как каркас и пройти по семи пунктам, убедившись, что каждый закрыт. Финальную версию по крупной сумме проверяет юрист.

Чем отличается договор на разработку сайта с самозанятым? По составу пунктов ничем: предмет, этапы, приёмка, права, доступы, гарантия нужны те же. Отличия в расчётах — самозанятый формирует чек в приложении «Мой налог», и его получение стоит зафиксировать как условие оплаты. Особенно внимательно проверяется отчуждение исключительного права: физическое лицо остаётся автором, и без явной формулировки право не переходит.

Какие этапы разработки сайта должны быть в договоре? Минимальный рабочий набор: техническое задание, прототип структуры, дизайн, сборка и вёрстка, наполнение и интеграции, тестирование и запуск. На лендинге этапов может быть три, на крупном проекте — больше. Значение имеет не количество, а наличие у каждого этапа проверяемого результата и своей суммы.

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

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

Коротко

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

Разбор конкретного договора или подготовка технического задания перед подписанием — задача обсуждаемая: контакты.