Я Максим, веб-разработчик. За свою карьеру я видел немало конфликтов между заказчиками и подрядчиками. В девяти случаях из десяти причина одна и та же — либо договора нет вообще, либо он настолько размытый, что в спорной ситуации от него нет толку. «Разработать сайт в соответствии с пожеланиями заказчика» — это не предмет договора, а приглашение к конфликту.

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

Почему договор необходим даже при работе «по дружбе»

Даже если вы работаете с другом, знакомым или подрядчиком по рекомендации — договор нужен. Особенно если с другом. Потому что когда нет формальных договорённостей, каждый интерпретирует условия по-своему. Заказчик думает, что за оговорённую сумму получит пять раундов правок и дизайн в Figma. Исполнитель думает, что одна итерация — и проект закрыт. Без бумаги, где всё прописано, начинаются обиды, и дружба заканчивается вместе с проектом.

Договор защищает обе стороны: заказчик знает, что получит и в какой срок. Исполнитель знает, что ему заплатят и за что именно. Если что-то пойдёт не так — есть документ, к которому можно апеллировать. В крайнем случае — в суде, хотя до этого лучше не доводить.

Я сам однажды работал без договора — «по знакомству, быстрый проект». Потом три месяца правил мелочи, которые заказчик считал частью работы, а я — дополнительными задачами. С тех пор — только через договор, даже если проект на 30 000 рублей.

Предмет договора: что именно делаем

Первый и самый важный пункт — чёткое описание того, что разрабатывается. Не «сайт для компании», а «одностраничный лендинг для продвижения услуги ремонта квартир, включающий 7 экранов согласно утверждённому техническому заданию (Приложение №1)». Или «интернет-магазин строительных материалов на платформе X с каталогом до 5 000 товарных позиций, корзиной, интеграцией с платёжной системой ЮKassa и сервисом доставки СДЭК».

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

Техническое задание как приложение к договору

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

Без ТЗ результат непредсказуем. Я видел проект, где заказчик устно попросил «простой сайт», а после запуска заявил, что ожидал личный кабинет с историей заказов, онлайн-чат и интеграцию с 1С. «Ну это же само собой разумеется для современного сайта» — сказал он. Нет, не разумеется. Всё, что не прописано в ТЗ — не входит в работу.

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

Сроки и этапы работ

В договоре должны быть конкретные даты, а не абстрактное «в разумные сроки». Я обычно разбиваю проект на этапы с чёткими дедлайнами.

Первый этап — разработка и утверждение дизайн-макета. Срок: две-три недели. Второй этап — вёрстка и программирование. Срок: три-четыре недели. Третий этап — наполнение контентом и тестирование. Срок: одна-две недели. Четвёртый этап — запуск и финальная проверка. Срок: одна неделя.

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

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

Общая сумма, разбивка по этапам и условия оплаты — всё фиксируется в договоре. Типичные схемы оплаты для веб-разработки.

Поэтапная: 50% предоплата перед началом работ, 30% после утверждения дизайн-макета, 20% после запуска сайта. Это самая распространённая схема, которая балансирует риски обеих сторон.

Для крупных проектов: 30% предоплата, далее ежемесячные платежи по факту выполненных этапов. Для небольших проектов: 100% предоплата или 50/50 — половина до, половина после.

Отдельно прописывается, что включено в стоимость, а что оплачивается дополнительно. Например: «В стоимость входит до трёх итераций правок дизайн-макета. Каждая дополнительная итерация — 10 000 рублей.» Это спасает от ситуации, когда заказчик двадцать раз переделывает главную страницу.

Порядок приёмки работ

Один из самых важных разделов, который часто пропускают. Здесь нужно прописать: сколько дней у заказчика на проверку каждого этапа (обычно пять-десять рабочих дней), в какой форме предоставляются замечания (письменно, по email), что считается замечанием в рамках ТЗ, а что — дополнительной работой, что происходит, если заказчик не предоставил замечания в срок (работа считается принятой).

Последний пункт критически важен. Без него проект может зависнуть на месяцы: исполнитель сдал работу, заказчик «не успел посмотреть», финальная оплата не проходит. Автоматическая приёмка при отсутствии замечаний в срок — стандартная практика, которая дисциплинирует обе стороны.

Права на результат: кому принадлежит сайт

Этот пункт регулируется статьёй 1296 ГК РФ. По умолчанию исключительные права на результат интеллектуальной деятельности принадлежат заказчику, если договором не предусмотрено иное. Но «по умолчанию» — ненадёжная конструкция. Лучше прописать явно.

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

Ключевые слова — «с момента полной оплаты». Это защищает исполнителя: пока не заплатили — права не переданы. И защищает заказчика: после оплаты — всё его.

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

Ответственность сторон и расторжение

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

Механизм расторжения — как прекратить сотрудничество, если стороны не могут работать вместе. Кто кому что должен, в какой срок передаются материалы. Без этого пункта расставание превращается в затяжной конфликт.

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

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

Типичные ошибки в договорах на разработку

Договор без ТЗ — невозможно определить, выполнена работа или нет. Неопределённое количество правок — заказчик может вносить бесконечные изменения, и проект никогда не закончится. Права на код не прописаны — разработчик формально может «не отдать» сайт. Нет механизма расторжения — если стороны хотят прекратить сотрудничество, некуда обратиться. Не указан порядок внесения изменений в ТЗ — заказчик меняет требования на ходу, а бюджет остаётся прежним.

Шаблон или индивидуальный договор

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

Для сложных проектов — интернет-магазин с интеграциями, портал, SaaS-платформа — рекомендую привлечь юриста, специализирующегося на IT-праве. Стоимость составления договора — от 10 000 до 30 000 рублей. Это ничтожная сумма по сравнению с потенциальными потерями от плохо составленного документа.

Договор — это не про недоверие. Это про ясность, предсказуемость и защиту для обеих сторон. Хороший договор — основа спокойного проекта.