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

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

1. Предмет договора и приложения

Должно быть чётко: «разработка сайта согласно ТЗ (Приложение №1)». Если ТЗ нет в приложении — у подрядчика есть свобода трактовки. Если ТЗ есть, но в нём общие фразы — это то же самое. Хорошее ТЗ занимает 10–50 страниц с экранами, сценариями и критериями приёмки.

2. Этапы и порядок приёмки

• Каждый этап описан отдельно: что сдаётся, по какому критерию принимается, сколько дней на проверку.
• Указано, что считается отказом приёмки (мотивированный отказ в письме, не «мне не нравится»).
• Прописано, что подписание акта не лишает права на гарантию.

3. Сроки и ответственность за их срыв

Срок без штрафа — это пожелание. Прописывайте: «за каждый день просрочки — 0.1% от стоимости этапа, но не более 10%». Симметрично — штраф для заказчика за просрочку приёмки (чтобы было справедливо).

4. Стоимость и порядок оплаты

• Чёткая разбивка по этапам с суммами.
• Не больше 30% предоплаты на старт.
• Условия изменения цены: только письменное доп.соглашение.
• Указано, что входит в стоимость, а что — нет (контент, лицензии, хостинг).

5. Права на код, дизайн и материалы

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

Если в договоре написано «заказчик получает право использования» — это лицензия, а не права. Сменить подрядчика без согласия первого вы не сможете.

6. Гарантия

• Минимум 3 месяца с момента релиза (рыночный стандарт — 6 месяцев).
• Указано, что входит: исправление багов кода, дизайна, вёрстки.
• Указано, что НЕ входит: новые фичи, изменения требований, доработки.
• Срок реакции на критический баг — не больше 1 рабочего дня.

7. Конфиденциальность и передача доступов

• NDA или раздел о конфиденциальности — для большинства проектов обязателен.
• Прописано, кто и в какой момент передаёт доступы (хостинг, домен, репозиторий, аккаунты сервисов).
• После окончания работ — все доступы возвращаются/закрываются.

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

Опишите оба сценария: что будет, если заказчик хочет уйти, и что — если уходит подрядчик. Обычно — оплата за фактически выполненный объём с актом сверки, передача всех артефактов в течение N дней, возврат остатка предоплаты.

Чего не должно быть в договоре

• Эксклюзив на сопровождение после релиза — это привязывает вас к подрядчику.
• Запрет на работу с конкурентами подрядчика.
• Автоматическая пролонгация без вашего согласия.
• Подсудность в городе подрядчика, если он в другом регионе.

Итог

Хороший договор не сложнее 10–15 страниц и не использует канцелярит ради канцелярита. Если подрядчик прислал шаблон, в котором половина пунктов — в его пользу, это повод торговаться. Если хотите — пришлите свой проект договора, разберём в формате «что усилить» бесплатно.