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

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

Зачем этот гайд

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

Подготовка

Фиксированная цена работает, если объём чётко описан в ТЗ — тогда подрядчик берёт на себя риск недооценки. Повременная оплата (time & material) уместна для исследовательской части проекта, где объём заранее не известен — но тогда договору нужен потолок (cap) или regular reporting, иначе смета растёт без контроля. Комбинация — не универсальное зло: T&M на этапе прототипирования и фикс на разработку по согласованному ТЗ снимает риск с обеих сторон. Оплата одним платежом по факту сдачи всего проекта — самый рискованный вариант для заказчика: у подрядчика нет стимула сдавать промежуточные результаты.

Пошаговый порядок

Оплата должна быть привязана к этапам, а каждый этап — к акту приёмки с конкретными критериями (не «сайт готов», а «раздел каталога отображает товары с фильтрами по цене и категории согласно ТЗ п. 4.2»). Без этого правила приёмка превращается в спор о вкусах на финальной сдаче. Стоит прописать срок на проверку акта (например, 5 рабочих дней) и что происходит, если заказчик не отвечает в срок — иначе проект зависает в юридической неопределённости.

Частые ошибки

Договор должен явно передавать заказчику исключительные права на разработанный код после полной оплаты — «серый» вариант без этого пункта означает, что формально правами продолжает владеть подрядчик. Отдельно стоит прописать статус сторонних компонентов: open-source библиотеки передаются по своим лицензиям (это нормально), а платные плагины/темы/API-ключи — с указанием, на кого оформлена подписка и что происходит при её окончании.

Чеклист

Гарантийный период (обычно 1–3 месяца после сдачи) должен покрывать исправление багов, но явно не включать новые фичи — иначе любая доработка превращается в спор, входит она в гарантию или нет. Отдельно стоит зафиксировать SLA на реакцию по критичным ошибкам после запуска (например, «критичный баг — реакция в течение 4 рабочих часов») — без этого срока «поддержка» ничем не обеспечена на практике.

Что делать дальше

• Самозанятый не может нанимать субподрядчиков от своего лица официально — если в проекте участвует команда, а договор с одним самозанятым, ответственность за остальных юридически размыта
• У самозанятого есть лимит годового дохода (для применения этого налогового режима) — при превышении статус слетает задним числом, что может создать вопросы к уже подписанному договору
• Между юрлицами проще прописать штрафные санкции за просрочку и типовую передачу исключительных прав — с самозанятым это тоже возможно, но реже встречается в шаблонных договорах, которые он предлагает
• НДС не начисляется ни у самозанятого, ни у большинства ИП/ООО на УСН — при выборе подрядчика это не решающий критерий, если важны риски выше

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

Что упускают в шаблонных договорах

1. ТЗ не приложено к договору или существует только в переписке — при споре не на что сослаться
2. Нет критериев приёмки по этапам — «сдача проекта» превращается в оценочное суждение
3. Не прописана передача исключительных прав — заказчик формально не может передать код другому подрядчику для доработки
4. Гарантия не разграничена с доработками — любое обращение после сдачи вызывает спор
5. Нет порядка согласования изменений ТЗ — любая правка «пока делаем» не защищена ни по срокам, ни по смете

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