Хороший договор нужен не для суда, а для того, чтобы обе стороны заранее договорились, что считается результатом. Большинство конфликтов в разработке - это не обман, а разное понимание одних и тех же слов. «Сделать сайт» для заказчика и для студии может означать очень разные объёмы работы. Задача договора и приложений к нему - убрать это расхождение.
Состав работ
Самый важный документ - это не сам договор, а техническое задание или спецификация в приложении. Там должно быть перечислено, сколько страниц, какие типы страниц, какие функции, на каком движке, сколько языков, кто пишет тексты, кто готовит фотографии. Фраза «разработка корпоративного сайта» без расшифровки не значит ничего. Если ТЗ ещё не готово, в договоре так и пишут: первый этап - разработка ТЗ, и только после его утверждения фиксируется цена остального.
Сроки и этапы
Сроки стоит разбивать на этапы с промежуточными результатами: дизайн, вёрстка, программирование, наполнение, запуск. Так вы видите прогресс и можете остановиться, если что-то идёт не туда. Отдельно проверьте, как считается срок, если задержка на стороне заказчика - например, вы неделю не присылали тексты. Нормальная формулировка: срок сдвигается на время ожидания ваших материалов.
Приёмка работ
Как именно вы принимаете сайт: по какому списку критериев, за сколько дней даёте замечания, что происходит, если замечаний нет. Важный момент - что считается недоработкой, а что новым пожеланием. Кнопка не работает - это недоработка, её чинят бесплатно. «А давайте теперь сделаем ещё и каталог» - это новая задача за отдельные деньги. Без этого разграничения приёмка может тянуться месяцами.
- Права на дизайн и код переходят к заказчику после полной оплаты - это должно быть написано прямо
- Все доступы (хостинг, домен, админка, аналитика) передаются заказчику при сдаче
- Указано, какие сторонние компоненты платные и кто оплачивает их продление
- Прописан гарантийный срок на исправление ошибок после запуска
- Есть условия расторжения: что получает заказчик, если проект останавливается на середине
Права и доступы
Частая и болезненная ситуация: сайт сделан, отношения со студией испортились, а домен зарегистрирован на студию, хостинг оформлен на неё же, исходники никто не отдаёт. Формально заказчик заплатил за сайт, а фактически не может им управлять. В договоре должно быть чётко: домен регистрируется на заказчика или передаётся ему, исходный код и макеты передаются при сдаче, все логины и пароли - тоже.
Поддержка после запуска
Разработка и поддержка - это разные договоры или как минимум разные разделы. Уточните, что входит в гарантию (исправление ошибок разработчика) и что уже платная работа (доработки, обновления, консультации). Если планируете обслуживание у той же студии, условия и стоимость лучше зафиксировать сразу, пока у вас сильная переговорная позиция.
Оплата и как она привязана к результату
Полная предоплата невыгодна заказчику, полная оплата по факту - исполнителю. Обычная схема - разбить сумму на части, привязанные к этапам: аванс на старте, оплата после утверждения дизайна, после сдачи основной функциональности, финальный платёж при запуске. Так у обеих сторон есть стимул двигаться дальше, и ни у кого не заморожена вся сумма целиком. Отдельно стоит прописать, что происходит с уже выплаченными деньгами, если проект останавливается: возвращается ли аванс, передаются ли промежуточные наработки.
Полезный пункт - фиксированный тариф на доработки сверх ТЗ. Не «обсудим по ситуации», а конкретная ставка за час или за типовую задачу. Тогда в момент, когда у вас появится новое пожелание, не придётся заново торговаться: вы просто понимаете, во сколько это обойдётся, и решаете, нужно оно сейчас или потом.
Наконец, договор стоит читать целиком, а не только раздел с ценой. Самые неприятные сюрпризы обычно спрятаны в общих формулировках: чья ответственность за простой сайта, что считается форс-мажором, в какой срок и в каком виде подаются претензии. Полчаса на внимательное чтение до подписи дешевле любого спора после.