Договор на разработку сайта обычно читают по диагонали, а потом спорят о правках, сроках и правах на код. Собрали пункты, на которые стоит потратить час до подписания, чтобы проект шёл спокойно.
Почему договор — рабочий инструмент, а не формальность
За пятнадцать лет работы мы видели много проектов, пришедших к нам после неудачного опыта с другим подрядчиком. В большинстве таких историй конфликт начинался не с плохого кода или слабого дизайна, а с расплывчатого договора. Стороны по-разному понимали, что входит в работу, сколько раундов правок предусмотрено, кто готовит тексты и когда проект считается сданным. Каждый был по-своему прав, и никто не мог доказать свою правоту документом.
Хороший договор защищает обе стороны. Заказчику он даёт ясность: что он получит, когда и в каком виде. Исполнителю — предсказуемость: объём работ зафиксирован, изменения оформляются отдельно, оплата привязана к понятным точкам. Ниже — пункты, которые мы советуем проверить в любом договоре на создание сайта, независимо от того, с кем вы работаете. Эта статья — взгляд практиков, а не юридическая консультация: финальную редакцию договора имеет смысл показать своему юристу.
Предмет договора и техническое задание
Фраза «разработка сайта компании» в предмете договора ничего не означает. Сайт из пяти страниц и портал с личными кабинетами — это одна и та же формулировка. Объём работ должен раскрываться в приложении: техническом задании, спецификации или хотя бы подробном перечне страниц и функций.
Что проверить в приложении:
- список типов страниц и шаблонов, которые будут разработаны (главная, раздел каталога, карточка товара, статья, контакты и т.д.);
- перечень функций: формы, фильтры, личный кабинет, поиск, калькулятор, интеграции;
- адаптивность — для каких ширин экрана делается вёрстка и в каких браузерах проверяется;
- кто и в каком объёме наполняет сайт: только шаблоны с примерами или весь каталог;
- что явно не входит в работу — это так же важно, как то, что входит.
Если ТЗ ещё не готово, нормальная практика — разделить проект на два договора или два этапа: сначала аналитика и проектирование с результатом в виде ТЗ и прототипов, потом разработка по согласованному документу. Так вы платите за конкретный результат на каждом шаге и можете остановиться после первого этапа, если что-то не устроит.
Этапы, сроки и то, что их сдвигает
Срок в договоре почти всегда указывается в рабочих днях и считается от определённого события: предоплаты, передачи материалов, согласования предыдущего этапа. Проверьте, от чего именно. Если срок «90 рабочих дней с момента подписания», а материалы вы передадите через месяц, формально исполнитель уже опаздывает, а фактически ждал вас.
Хорошая структура выглядит так: проект разбит на 4–6 этапов, у каждого есть результат, срок исполнителя и срок заказчика на согласование. Например, на проверку дизайн-макета заказчику отводится 5 рабочих дней. Если за это время замечаний нет, этап считается принятым. Этот пункт иногда вызывает сопротивление, но без него проект может месяцами висеть на согласовании без движения.
| Этап | Результат | Ориентир по сроку исполнителя | Срок на согласование |
|---|---|---|---|
| Аналитика и прототип | Структура, прототипы ключевых страниц | 3–5 недель | 5 рабочих дней |
| Дизайн | Макеты для десктопа и мобильных | 4–6 недель | 5 рабочих дней |
| Вёрстка и программирование | Работающий сайт на тестовом сервере | 6–10 недель | 10 рабочих дней |
| Наполнение и тестирование | Сайт с контентом, отчёт о тестах | 2–4 недели | 5 рабочих дней |
| Запуск | Сайт на рабочем домене | 1 неделя | — |
Цифры в таблице — ориентир для корпоративного сайта или каталога средней сложности, у каждого проекта они свои. Важно другое: в договоре должна быть логика, при которой сдвиг на вашей стороне сдвигает и срок исполнителя, а не превращается в спор.
Правки: сколько, каких и как оформляются
Самый конфликтный пункт. Под словом «правки» стороны часто понимают разное. Для дизайнера это изменение цвета кнопки или порядка блоков. Для заказчика — иногда и полная смена концепции после того, как он показал макет руководителю.
Нормальная практика — развести два понятия. Корректировки в рамках согласованного прототипа и концепции входят в стоимость, обычно в объёме 2–3 итераций на этап. Изменения, которые выходят за рамки согласованного, — новые разделы, новые функции, смена логики — оформляются как дополнительные работы с отдельной оценкой. Обратите внимание, чтобы в договоре был описан порядок: как вы присылаете запрос, в какой срок получаете оценку, как подписывается дополнительное соглашение.
Совет студии: собирайте замечания по макету от всех участников в один документ и отправляйте одним списком. Три письма от трёх руководителей с противоречащими друг другу пожеланиями съедают раунд правок и никого не приближают к результату.
Приёмка и гарантийный период
Проверьте, как в договоре описана приёмка. Лучше всего, если есть конкретный список критериев: сайт открывается на указанных устройствах, функции работают по сценариям из ТЗ, формы отправляют заявки на указанную почту. Размытое «работа выполнена качественно» не помогает ни одной из сторон.
Важен срок на приёмку и последствия его истечения. Если акт не подписан и мотивированный отказ не направлен в течение, скажем, 10 рабочих дней, работа считается принятой. Это нормальное условие, и бояться его не нужно — нужно просто заранее выделить время на проверку. О том, как проверять сайт перед подписанием акта, у нас есть отдельный материал в блоге.
Отдельный пункт — гарантийные обязательства. Добросовестные подрядчики бесплатно исправляют ошибки в своём коде в течение 3–12 месяцев после запуска. Гарантия обычно не распространяется на ошибки, возникшие после вмешательства третьих лиц, обновления сторонних модулей по инициативе заказчика или смены хостинга. Это разумно, но стоит прочитать, что именно считается ошибкой, а что — доработкой.
Права на результат и доступы
Кому принадлежат дизайн, код и тексты после оплаты? Многие уверены, что раз заплатили — значит, всё их. На практике это определяется договором. Смотрите, чтобы в нём было прямо указано: исключительные права на макеты, уникальный код и созданные тексты переходят к заказчику после полной оплаты соответствующего этапа, либо заказчику предоставляется лицензия с понятным объёмом.
Нюанс: коммерческая CMS, платные модули, шрифты и фотобанки не могут перейти в вашу собственность, на них оформляются лицензии. В договоре хорошо бы видеть перечень сторонних компонентов и кто оплачивает их продление. Нередкая неприятная ситуация — через год после запуска выясняется, что лицензия на CMS оформлена на подрядчика, и продлить её без него нельзя.
Доступы — отдельная тема. Домен должен быть зарегистрирован на вашу компанию. Хостинг, административная панель, репозиторий с кодом, системы аналитики — всё это должно передаваться вам вместе с актом. Запишите это в договор как обязательство исполнителя, а не как жест доброй воли.
Оплата, ответственность и выход из проекта
Типичные схемы оплаты: 50/50, поэтапная оплата после каждого этапа, предоплата этапа перед его началом. Для длинных проектов поэтапная схема удобнее обеим сторонам: у заказчика нет риска заплатить за всё вперёд, у исполнителя — работать месяцами без денег.
Проверьте, что предусмотрено при расторжении. Если проект останавливается на середине, как рассчитывается стоимость выполненной части и что вы получаете на руки? Честный вариант: оплачиваются фактически выполненные и переданные этапы, заказчик получает все материалы по ним. Штрафные санкции должны быть симметричными: если есть пени за просрочку оплаты, логично ожидать и пени за просрочку сдачи этапа по вине исполнителя.
Чек-лист перед подписанием
- Объём работ раскрыт в приложении: страницы, функции, адаптивность, наполнение, исключения.
- Проект разбит на этапы с результатом и сроком по каждому.
- Есть срок на согласование с вашей стороны и понятно, что происходит при его истечении.
- Описано, сколько итераций правок входит в этап и как оформляются изменения объёма.
- Прописаны критерии приёмки и срок на проверку.
- Есть гарантийный период и понятно, что в него входит.
- Права на макеты, код и тексты переходят к вам после оплаты или оформлена лицензия с понятным объёмом.
- Домен, хостинг, админ-панель, репозиторий и аналитика оформлены на вас или передаются вам.
- Перечислены сторонние лицензии и понятно, кто их продлевает.
- Порядок оплаты привязан к этапам, условия расторжения описаны.
- Итоговую редакцию посмотрел юрист вашей компании.
Час, потраченный на этот список до подписания, экономит недели переписки в середине проекта. А подрядчик, который спокойно отвечает на вопросы по каждому пункту и готов уточнять формулировки, обычно так же спокойно ведёт и сам проект.
