Гарантия на разработку сайта - это обязательство исправить то, что не соответствует техзаданию или сломалось из-за моей ошибки в коде, а не бессрочная бесплатная доработка проекта по любому новому запросу. Путаница между этими вещами - главная причина конфликтов после сдачи сайта, и разбираться в ней приходится почти на каждом проекте, будь то лендинг на Tilda или интернет-магазин на WordPress.
Что покрывает гарантия на разработку сайта
Когда я сдаю проект, в акте фиксируется список функций из ТЗ: форма заявки отправляет заявку, калькулятор считает стоимость, каталог фильтруется по параметрам, интеграция с СДЭК возвращает стоимость доставки. Гарантия распространяется именно на это - на соответствие сданного функционала тому, что было согласовано и оплачено.
Если форма после сдачи вдруг перестала отправлять письма, калькулятор на Tilda считает неверно из-за моей ошибки в формуле, или скрипт зон доставки начал выдавать некорректные тарифы при том же наборе входных данных - это гарантийный случай, я исправляю без дополнительного счёта. Срок такого исправления у меня обычно 1-3 дня для простых доработок и до 5 дней для комплексных интеграций.
А вот если через месяц после запуска клиент решает добавить в ту же форму новое поле, калькулятору нужно учитывать ещё один параметр, которого не было в ТЗ, или в каталог нужно добавить фильтр по бренду - это уже другая работа, и она оценивается отдельно, даже если делается в том же файле, что и гарантийная правка.
Баг: как я его определяю на практике
Баг - это расхождение между тем, что написано в ТЗ или показано на приёмке, и тем, что происходит на сайте сейчас. Проверяю это так: беру акт сдачи или переписку с описанием функционала, воспроизвожу сценарий и сравниваю с ожидаемым результатом. Если расхождение есть и оно не вызвано действиями клиента - это баг.
Примеры из практики:
- После сдачи заказа на WooCommerce с оплатой через T‑Bank платёж проходит, но заказ не переходит в статус «оплачен» - баг в вебхуке, чиню бесплатно.
- Telegram-бот на aiogram отвечал на команду /start корректно на приёмке, а через две недели стал падать с ошибкой из-за необработанного исключения в конкретном сценарии, который уже был в ТЗ - это баг, а не новая функция.
- Сценарий в n8n, который должен был раз в сутки подтягивать заказы и класть их в таблицу, перестал срабатывать из-за смены формата ответа от API - если формат менялся не по вине клиента и сценарий был согласован заранее, разбираюсь и чиню в рамках гарантии.
- Скрипт расчёта НДС для Tilda в какой-то момент начал округлять суммы неправильно при тех же входных данных, что были на тестах - баг.
Общий признак: тот же ввод, что раньше давал верный результат, теперь даёт неверный, а требования не менялись.
Новая задача: где заканчивается гарантия
Новая задача - это любое изменение требований, даже небольшое. Не важно, насколько мелкой кажется правка клиенту, если её не было в исходном ТЗ, оценивается она отдельно.
Примеры из практики
Ограничитель промокодов в Tilda я делал для проекта с одним правилом - код действует только на первый заказ. Через два месяца клиент попросил добавить второе правило - лимит по количеству использований одного кода. Формально это тот же скрипт, но новая логика, новые тесты, новая цена, потому что задачи такого рода я оцениваю от 3 000 ₽ за простую доработку скрипта.
Другой случай: интеграция с СДЭК считала доставку по одному складу. Клиент открыл второй склад в другом городе и попросил переключать точку отправления в зависимости от региона покупателя. Это не баг в существующей интеграции, а новый функционал, требующий пересмотра логики выбора точки отправки - оцениваю как отдельную задачу, комплексные интеграции у меня от 40 000 ₽.
С ботами похожая история. Бот на aiogram, который отвечал на вопросы по FAQ, стабильно работал полгода. Потом заказчик захотел, чтобы бот собирал заявки и передавал их в CRM. Это не починка старого сценария, а добавление нового модуля - оценивается отдельно, как и любой Telegram-бот с новой функциональностью, от 30 000 ₽.
То же самое с автоматизацией в n8n: если сценарий изначально обрабатывал заказы из одного источника, а потом нужно подключить второй источник данных с другой структурой полей, это расширение сценария, а не исправление существующего.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Баг или доработка: как быстро проверить
Я пользуюсь простой таблицей, когда клиент присылает описание проблемы. Если хотя бы один пункт указывает на «новая задача» - это не гарантийный случай.
| Признак | Баг (гарантия) | Новая задача |
|---|---|---|
| Соответствие ТЗ | Функция была описана и принята на сдаче | Функции не было в исходном ТЗ |
| Поведение | Раньше работало верно, сейчас нет при тех же входных данных | Требуется новое поведение, которого не было изначально |
| Причина | Ошибка в коде или логике, допущенная при разработке | Изменение бизнес-процесса или требований клиента |
| Объём изменений | Точечное исправление существующего кода | Новая логика, новые сценарии, новые интеграции |
| Оплата | Бесплатно в рамках гарантийного срока | Оценивается и оплачивается отдельно |
Пограничные случаи все равно бывают, и тут решает не формальный признак, а то, что зафиксировано в переписке и актах на момент сдачи. Поэтому я всегда прошу подтверждать финальный список функций текстом, а не устно на созвоне.
Сколько длится гарантия на разных типах проектов
Срок гарантии у меня зависит от сложности проекта и типа работ:
- Лендинг или сайт на Tilda - 30 дней с момента сдачи на функционал, который был протестирован на приёмке.
- Кастомный скрипт для Tilda (промокоды, зоны доставки, конвертер валют и подобное) - 30 дней на логику скрипта при неизменных входных условиях.
- Сайт на WordPress - 60 дней, поскольку там больше точек, где может проявиться конфликт с обновлением плагинов или темы.
- Комплексные интеграции (эквайринг, CRM, СДЭК и подобные) - 90 дней на код самой интеграции, но не на работу стороннего сервиса-партнёра, если у него меняется API или условия без предупреждения.
- Telegram-боты и автоматизация в n8n - 30 дней на сценарии, зафиксированные в ТЗ.
После окончания гарантийного срока сайт не остаётся без поддержки, просто она переходит в платный режим: почасовая оплата за конкретные правки или абонентское обслуживание, если нужно регулярное сопровождение. Для проектов, где такие обращения случаются часто, обычно выгоднее техническая поддержка сайта на абонентской основе, чем оплачивать каждую правку отдельным счётом.
Что писать в договоре, чтобы не спорить постфактум
Большинство споров о гарантии возникает не из-за жадности одной из сторон, а из-за размытых формулировок в ТЗ. За несколько лет практики я выработал минимальный набор пунктов, которые снимают почти все вопросы:
- Точный список функций с примерами ожидаемого поведения, а не общие фразы вроде «удобный каталог».
- Срок гарантии и что именно в него входит - конкретные разделы сайта, скрипты, интеграции.
- Условие, что гарантия не распространяется на последствия изменений, внесённых клиентом или третьими лицами после сдачи.
- Порядок обращения по гарантийным случаям - куда писать, в какой срок жду ответа на диагностику.
- Отдельно прописанное условие, что изменение требований оформляется как новая задача с отдельной оценкой сроков и стоимости.
Это не бюрократия ради бюрократии - когда список функций зафиксирован письменно, конфликтных ситуаций почти не возникает, потому что обе стороны сверяются с одним документом, а не с памятью о разговоре месячной давности.
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Что делать, если баг проявился в последний день гарантии?
Обращение, отправленное до истечения срока гарантии, я рассматриваю как гарантийное, даже если само исправление займёт несколько дней уже после формального окончания срока. Важна дата обращения, а не дата, когда починка была завершена.
Считается ли багом ситуация, когда сайт не работает из-за хостинга или домена?
Нет, если причина не в коде, который я писал. Проблемы с хостингом, продлением домена, SSL-сертификатом или сторонними сервисами (платёжный шлюз, СДЭК, почтовый сервис) не входят в гарантию на разработку, потому что это зона ответственности провайдера услуги, а не разработчика.
Можно ли расширить гарантию, если сайт сложный?
Срок гарантии фиксируется в договоре на этапе согласования проекта и обычно связан со сложностью и объёмом тестирования перед сдачей. Для крупных проектов вроде веб-сервисов на React или API-бэкендов на Laravel я закладываю более длительный срок гарантии заранее, а не продлеваю его постфактум.
Что если непонятно, баг это или новая задача?
Присылаю оценку в течение 1-2 дней после диагностики: либо подтверждаю гарантийный случай и чиню бесплатно, либо объясняю, почему это выходит за рамки исходного ТЗ, и называю стоимость и сроки как для отдельной задачи. Спорные случаи разбираю по переписке и актам сдачи, а не по устным договорённостям.