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

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

Порядок пунктов соответствует порядку, в котором эти вещи ломаются на практике.

1. Предмет договора

Искать: ссылку на приложение с перечнем работ.

Нормально: «Исполнитель обязуется выполнить работы в объёме, определённом Приложением № 1».

Опасно: «Исполнитель обязуется разработать сайт» без приложения. Предмет не определён, приёмка невозможна.

Проверка: приложение существует отдельным файлом и подписано одновременно с договором.

2. Сроки

Искать: дату начала, привязанную к событию, и дату окончания.

Нормально: «Работы начинаются в течение двух рабочих дней с даты поступления аванса и предоставления Заказчиком материалов согласно п. 3.2».

Опасно: «Ориентировочный срок выполнения — один месяц». Слово «ориентировочный» снимает ответственность.

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

3. Приёмка

Искать: форму сдачи и срок рассмотрения.

Нормально: «Исполнитель направляет уведомление о готовности этапа. Заказчик в течение пяти рабочих дней подписывает акт либо направляет мотивированные замечания».

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

Проверка: сказано, что замечания должны быть мотивированными и письменными. Без этого спор идёт голосом.

4. Права на код и дизайн

Искать: момент перехода исключительных прав.

Нормально: «Исключительные права на результат работ переходят Заказчику в полном объёме с момента подписания акта и полной оплаты».

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

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

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

Искать: на кого оформляются учётные записи.

Нормально: «Домен и хостинг регистрируются на Заказчика. Доступы передаются по перечню в составе сдачи проекта».

Опасно: молчание. Домен, оформленный на подрядчика, — самый частый способ потерять сайт при ссоре.

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

6. Гарантия

Искать: срок и предмет гарантии.

Нормально: «Исполнитель в течение трёх месяцев с даты сдачи безвозмездно устраняет ошибки, возникшие по его вине».

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

Проверка: отделены ошибки исполнителя от доработок. Это разные вещи и разные счета.

7. Изменения объёма

Искать: порядок оформления новых пожеланий.

Нормально: «Изменение объёма работ оформляется дополнительным соглашением с указанием стоимости и срока».

Опасно: отсутствие пункта. Тогда каждое «а давайте ещё» разрушает срок и превращает проект в бесконечный.

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

Искать: судьбу денег и результата.

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

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

9. Ответственность

Искать: ограничение ответственности и неустойку.

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

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

10. Порядок связи

Искать: канал, в котором обмен считается официальным.

Нормально: указана электронная почта сторон, переписка в ней признана юридически значимой.

Опасно: согласование в мессенджере без указания в договоре. Восстановить историю потом сложно.

Порядок действий перед подписанием

1. Прочитать приложение с перечнем работ раньше самого договора.

2. Отметить отсутствующие пункты из списка выше.

3. Направить исполнителю правки одним письмом, а не по одной.

4. Убедиться, что подписаны и договор, и приложение, и что даты совпадают.

5. Сохранить подписанные файлы отдельно от переписки.

Состав работ по типовым проектам — от лендинга до платформы — приведён в разделе с ценами, его удобно использовать как основу приложения.

11. Приложение с перечнем работ

Искать: отдельный документ, а не абзац внутри договора.

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

Опасно: формулировки «прочие работы», «доработки по ходу проекта», «оптимизация». Такие строки не поддаются приёмке.

Проверка: по каждой строке вы можете сказать, как убедитесь, что она выполнена. Если не можете — строку надо переписать.

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

Искать: обязанность не разглашать переданные сведения и порядок обращения с персональными данными пользователей сайта.

Нормально: указано, что исполнитель обрабатывает данные только для выполнения работ и удаляет тестовые копии после сдачи.

Опасно: отсутствие пункта в проекте с личными кабинетами или клиентской базой.

Как читать договор за двадцать минут

Порядок чтения отличается от порядка пунктов.

Сначала приложение с работами: без него остальное не проверяется. Потом сроки и приёмка — там живут почти все конфликты. Потом права и доступы — там живут все катастрофы. Ответственность и расторжение читаются последними, потому что применяются реже всего.

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

Что делать, если исполнитель не согласен на правки

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

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

Отказ обсуждать первую группу — сам по себе результат проверки. Он экономит вам проект.

Коротко

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

Опасны не жёсткие формулировки, а отсутствующие. Пустое место в договоре толкуется в пользу того, кто его составил.