Договор на доработку сайта чаще всего разваливается не на этапе работы, а на этапе приёмки. Заказчик открывает сайт, видит не совсем то, что представлял, и упирается в формулировку вроде «доработать функционал корзины» - под ней можно понять что угодно, от смены цвета кнопки до переписывания логики расчёта доставки. За несколько лет доработок на Tilda, WordPress и кастомных сервисах я собрал набор формулировок, которые снимают этот риск ещё до старта работ, а не разбирают его постфактум через претензии.
По теме статьи
Готовое решение
AI-чатбот для сайта на Claude - отвечает как ваш менеджер, работает 24/7
Подключу к вашему сайту чат-бота на Claude API. Бот отвечает на вопросы клиентов голосом вашего бренда, знает каталог и условия доставки, забирает лиды в CRM или Telegram.
от25 000 ₽
Техподдержка
Чтобы сайт работал без сбоев
Обновления, доработки, мониторинг, резервные копии. WordPress, Tilda, самопис — всё поддерживаю. Пакет часов в месяц.
от15 000 ₽/мес
Почему договор на доработку сайта редко защищает от спора
Большинство шаблонов договоров, которые гуляют по интернету, описывают процесс, а не результат: «исполнитель обязуется произвести доработку функционала сайта в соответствии с пожеланиями заказчика». Формально пункт есть, юридически он ничего не фиксирует, потому что «пожелания» нигде не перечислены.
На практике это выглядит так: клиент просит доработать интеграцию с СДЭК на Tilda, разработчик реализует расчёт стоимости по индексу получателя и вывод ошибки, если пункт выдачи временно недоступен. Заказчик считает, что в доработку должен был войти ещё и калькулятор веса для крупногабаритных заказов, потому что «это же тоже про доставку». Спор возникает не из-за качества кода, а из-за того, что границы задачи нигде не были прописаны цифрами и сценариями.
Что обязательно прописать в договоре на доработку сайта
Чтобы акт подписывался без обсуждений, в договоре и приложениях к нему должны быть:
- предмет договора со ссылкой на техническое задание как на неотъемлемое приложение, а не общая фраза про «доработку сайта»;
- сроки по этапам, а не единая дата в конце проекта;
- проверяемые критерии приёмки для каждой задачи из ТЗ;
- порядок сдачи-приёмки: кто и в какой срок тестирует, как оформляются замечания;
- условия оплаты, привязанные к этапам, а не к абстрактному «завершению работ»;
- перечень того, что в доработку не входит - например, обучение персонала или техподдержка после сдачи.
Последний пункт часто пропускают, а зря. Когда я подключал приём платежей через T‑Bank в WooCommerce, в ТЗ отдельной строкой шло «настройка вебхуков и тестовые транзакции», а мониторинг платежей и разбор спорных списаний в дальнейшем - это уже отдельная услуга техподдержки, о которой стороны договариваются заранее и отдельно оплачивают.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Техническое задание: описываем результат, а не процесс
Самая частая ошибка формулировки - глагол «настроить» или «доработать» без описания состояния, в котором система должна оказаться на выходе. Разница простая: «настроить бота» ничего не описывает, а «бот на aiogram отвечает на команду /start приветственным сообщением и создаёт запись о новом пользователе в таблице заказов не позднее чем через 2 секунды» можно проверить по секундомеру и логам.
Пример плохой и хорошей формулировки
| Плохая формулировка | Хорошая формулировка |
|---|---|
| Доработать интеграцию с СДЭК | При выборе города получателя виджет рассчитывает стоимость и срок доставки по трём тарифам СДЭК за 3 секунды, при недоступном ПВЗ выводит сообщение с альтернативным списком |
| Настроить сценарий в n8n | По вебхуку от Tilda сценарий в n8n создаёт сделку в CRM в течение 10 секунд, при ошибке API отправляет уведомление в Telegram-чат ответственного менеджера |
| Улучшить работу бота | Бот на aiogram обрабатывает команду /order, сохраняет данные в базу и отправляет клиенту подтверждение без дублирующих сообщений при повторном нажатии кнопки |
Когда задача описана числом секунд, сценарием ошибки и конкретным действием системы, спорить о приёмке почти не о чем: либо сценарий воспроизводится, либо нет. Для наглядности такого уровня детализации можно посмотреть на готовые скрипты с чётко описанным поведением, например скрипт расчёта зон доставки для Tilda - там результат заранее определён до знака после запятой в тарифе, и это снимает почву для разночтений.
Критерии приёмки и акт выполненных работ
Акт без перечня выполненных пунктов - формальность, которая не защищает ни одну из сторон. В акте должны быть те же формулировки, что в ТЗ, плюс отметка о статусе каждой: выполнено, выполнено с оговоркой, не выполнено с указанием причины.
При подключении эквайринга T‑Bank в WooCommerce я всегда фиксирую в приложении к акту три обязательных тестовых сценария: успешная оплата, отклонённая карта, возврат средств. Пока все три не воспроизведены на тестовом или боевом окружении, работа не считается принятой, и это записано в договоре, а не проговорено устно.
Отдельно стоит прописать срок на предъявление замечаний после сдачи - обычно это 5-10 рабочих дней. Если заказчик за это время не присылает возражений и не подписывает акт, работа считается принятой автоматически. Без такого пункта акт можно не подписывать месяцами, формально сохраняя за собой право придраться в любой момент.
Сроки, этапы и оплата: как не увязнуть в бесконечной доработке
Доработки, в отличие от разработки с нуля, особенно подвержены «расползанию» задачи: заказчик по ходу работы вспоминает ещё пару смежных хотелок и пытается провести их как часть исходного пункта ТЗ. Разграничиваю это так:
- в договоре фиксирую, что правки в рамках согласованного ТЗ вносятся без доплаты до момента приёмки, а любые новые пункты оформляются дополнительным соглашением со своей сметой и сроком;
- оплата разбита на этапы: аванс перед стартом, часть после демонстрации промежуточного результата, остаток по подписанному акту;
- для доработок Tilda-скриптов оценка идёт от 3 000 ₽ за точечную правку и от 40 000 ₽ за комплексную интеграцию вроде связки эквайринга, СДЭК и CRM - и это тоже прописывается в приложении, чтобы при расширении задачи было от чего считать доплату.
Отдельно не стоит закладывать в договор бесплатные доработки «на будущее» или бесплатную поддержку после сдачи - это размывает границу между проектом и постоянным сопровождением, и потом сложно объяснить заказчику, почему через полгода правка вдруг стала платной.
Типичные ошибки в договорах на доработку сайта
| Ошибка | Последствие | Как исправить |
|---|---|---|
| ТЗ описывает действия, а не результат | Бесконечные правки «ещё чуть-чуть не то» | Указывать проверяемые сценарии и цифры (время отклика, порядок ошибок) |
| Нет промежуточных актов | Спор о том, что вообще было сдано и когда | Подписывать акт по каждому этапу, а не один в конце |
| Не указан срок на замечания | Акт годами висит неподписанным | Прописать 5-10 рабочих дней и автоматическую приёмку по истечении срока |
| Не разграничены доработка и техподдержка | Заказчик ждёт бесплатных правок после сдачи | Отдельным пунктом исключить постпроектное сопровождение из предмета договора |
Частые вопросы
Нужно ли отдельное техническое задание, если это доработка, а не разработка с нуля?
Нужно, и часто даже более детальное, чем при разработке нового сайта. При доработке приходится описывать не только новое поведение, но и то, что должно остаться без изменений - иначе исполнитель рискует случайно задеть смежный функционал, а заказчик потом спишет это на «недоработку».
Что делать, если заказчик не принимает работу и не подписывает акт?
Если в договоре есть срок на предъявление мотивированных замечаний, по его истечении акт считается подписанным в одностороннем порядке при условии, что исполнитель направил его способом, зафиксированным в договоре (заказным письмом, через ЭДО или на согласованный email). Без такого пункта формально придётся ждать подписи бессрочно.
Можно ли включить в договор бесплатные правки после сдачи?
Лучше не смешивать это с доработкой как таковой. Если заказчику важна возможность донастройки после сдачи, для этого есть отдельная услуга техподдержки с фиксированной стоимостью за период, а не размытое обещание «поправим, если что» внутри проектного договора.
Как оформить доработку, если правки затрагивают код, написанный другим разработчиком?
В ТЗ и договоре стоит прямо указать, что исполнитель не несёт ответственности за ошибки в существующем коде, обнаруженные в процессе доработки, и что оценка сроков и стоимости сделана исходя из текущего состояния кода на момент подписания договора. Это защищает от ситуации, когда за доработку одной функции с исполнителя пытаются спросить за старые баги всего проекта.