Гарантийный период после запуска сайта — что включать
Гарантия после запуска сайта — самая мутная часть договора. У одних «3 месяца на всё, включая хотелки», у других «исправление багов, выявленных в первые 14 дней». Разбираем, что реально стоит включать в гарантию, что вынести в платную поддержку и как формулировать в договоре.
Гарантия — отдельный пункт договора, который обычно пишут в последний момент абзацем «гарантийный период 3 месяца». Через две недели после запуска клиент звонит и просит «поправить блок с услугами и заодно поменять текст на главной». Студия молча правит — потому что отказать неудобно. Через месяц это уже 30 часов «гарантийной» работы, неоплаченных.
Хорошо составленная гарантия закрывает три задачи: защищает клиента от халтуры, защищает студию от бесплатной поддержки и даёт юридическую опору, если до неё дойдёт. Разбираем по пунктам.
Что такое гарантия по сути
Гарантия — это обязательство устранить за свой счёт ошибки в выполненной работе, обнаруженные в течение определённого срока после приёмки. Юридически это статья 723 ГК РФ для договора подряда (для разработки сайтов чаще применяется именно подряд или возмездное оказание услуг).
Ключевое слово — ошибки в выполненной работе. Новые требования, изменения, доработки и хотелки — это не гарантия. Это новая работа.
Что стоит включать в гарантию
- Исправление багов, появившихся не из-за действий клиента. Кнопка перестала отправлять форму, при определённой ширине экрана едет вёрстка, выпала иконка после обновления PHP — это гарантийный случай.
- Несоответствие согласованному ТЗ/макету. В макете хедер занимал 80px, в проде — 120px. Согласовали и забыли проверить — фиксим бесплатно.
- Восстановление работоспособности после собственного релиза. Если ваш патч сломал работающий блок — чините за свой счёт без таймера.
- Совместимость со стартовым списком браузеров. Договорились про последние Chrome, Safari, Firefox, Edge и Яндекс.Браузер — обеспечиваем работу в них в течение гарантии.
- Безопасностные дыры в вашем коде. Если эксплойт был в коде студии (не в чужом плагине, не в библиотеке) — закрываем бесплатно.
Что не стоит включать
- Новые функции и контент. «Добавьте ещё одну форму на сайт» — это новая работа, не гарантия.
- Изменения в дизайне и тексте. Решили перекрасить акцент с красного на синий — оплачивается отдельно.
- Проблемы из-за хостинга, домена, SSL. Если клиент не продлил домен или сменил тариф у хостера — не ваша зона.
- Проблемы из-за обновлений сторонних сервисов. Сменилось API ЮKassa, обновился CDEK, сломалась интеграция с CRM — это поддержка, не гарантия (если только вы прямо не зашили устаревшую версию намеренно).
- Действия клиента в админке. Сам поменял шаблон, удалил блок, перезаписал картинку — чините за деньги.
- Атаки и взломы. DDoS, попытки RCE, утечка паролей админа — это не качество разработки.
- Обновление зависимостей. Через год вышел Node 22, npm пакеты протухли — отдельная услуга.
Длительность гарантии
Рыночные ориентиры по веб-студиям в РФ в 2026:
- 14–30 дней — минимум для лендингов и небольших корпоративных сайтов.
- 60–90 дней — стандарт для большинства сайтов на CMS.
- 180 дней — кастомные интернет-магазины, сложные интеграции.
- 365 дней — крупные веб-приложения с API, мобилки. Обычно с оговорками по объёму бесплатных правок.
Полгода-год гарантии — это сильный аргумент в продаже, но требует резерва на свой бюджет. По нашим наблюдениям, реальный поток гарантийных правок на сайт средней сложности — 8–25 часов в первый месяц и почти ноль начиная с третьего. Если закладывать 5–10% от стоимости проекта в резерв на гарантию, рисков нет.
Формулировка в договоре
Худший вариант: «Исполнитель гарантирует качество работ в течение 3 месяцев со дня подписания акта». Это размытая фраза, из которой клиент может вывести что угодно.
Лучше — конкретный список и срок:
Гарантийный период — 90 (девяносто) календарных дней
со дня подписания акта приёмки.
В течение гарантийного периода Исполнитель обязуется
за свой счёт устранять:
а) ошибки в функционале, не возникшие в результате
действий Заказчика или третьих лиц;
б) несоответствие переданного результата согласованному
техническому заданию (Приложение №1) и макетам
(Приложение №2);
в) проблемы отображения в браузерах последних двух
стабильных версий: Chrome, Firefox, Safari, Edge,
Яндекс.Браузер.
Гарантия не распространяется на:
а) доработки и новые функции;
б) изменения текстов, изображений, дизайна;
в) проблемы хостинга, доменов, SSL-сертификатов;
г) изменения в API сторонних сервисов;
д) последствия действий Заказчика в системе управления
и на сервере;
е) атаки на сайт и компрометацию учётных записей;
ж) обновление версий программного обеспечения и
библиотек, не входящих в код Исполнителя.
Срок реакции на гарантийное обращение — 1 рабочий день.
Срок устранения — 5 рабочих дней с момента подтверждения
Исполнителем гарантийного характера обращения.
Канал для гарантийных обращений
Если клиент пишет в личку дизайнеру в WhatsApp — гарантия превращается в хаос. Зафиксируйте канал:
- Один email или один Telegram-бот для тикетов.
- Обязательная форма обращения: что произошло, на каком URL, в каком браузере, скриншот.
- Срок ответа — 1 рабочий день. Не «в течение часа» — иначе клиенты привыкают писать ночью.
Учёт времени по гарантии
Даже бесплатные работы фиксируйте в трекере. Это даёт две вещи:
- Понимание реальной экономики проекта: «на сайте X мы потратили 28 часов в гарантию — нужно поднять цену похожих проектов на 20%».
- Аргумент в разговоре с клиентом, который начинает запрашивать «ещё и вот это поправьте, и вот это»: «За месяц по вашему сайту мы закрыли 12 обращений на 9 часов работы. Это в рамках гарантии. То, что вы просите сейчас — изменение в макете, выходящее за пределы гарантии. Стоимость такая-то».
Гарантия и интеграции
Самая больная зона. Сайт интегрирован с amoCRM, ЮKassa, СДЭК, Wildberries. Что-то перестало работать. Источников может быть три:
- Ваш код (гарантия).
- Изменения на стороне сервиса (не гарантия).
- Изменения настроек у клиента (не гарантия).
Чтобы не спорить каждый раз, в договоре прописывайте: «Студия гарантирует работоспособность интеграции на момент сдачи. Изменения API на стороне сторонних сервисов и изменения конфигурации Заказчиком устраняются по отдельным заявкам в рамках договора поддержки».
Связка с договором поддержки
Хороший приём — продлевать клиента в платную поддержку сразу по окончании гарантии. Договор поддержки заключается одновременно с основным договором, действует с 91-го дня (если гарантия 90 дней). Тарификация в часах или фиксе.
Это упрощает три вещи:
- Клиент не ищет, кому платить за «маленькую доработку» через 3 месяца.
- Студия не теряет связь с проектом сразу после запуска.
- Снимается давление «всё ещё гарантия?» — есть понятная граница и продолжение.
Грабли, на которые наступают
- «Я уже отдал акт, можете не отвечать». Подписанный акт ≠ окончание гарантии. Игнор гарантийных обращений приводит к минусам в отзывах и иногда в суд.
- «Поправим в гарантии, всё равно мелочь». Каждая «мелочь без счёта» приучает клиента, что всё бесплатно. Через 2 месяца оплачиваемых заявок ноль.
- Размытое «гарантия на качество». В суде такая формулировка не помогает, в переговорах — тоже.
- Гарантия без приёмки. Если акт не подписан, формально работа не сдана и срок гарантии не идёт.
Вывод
Гарантия в договоре веб-студии — не «3 месяца на всё», а конкретный перечень случаев и стоп-список. Длительность — от 30 до 180 дней под объём проекта. В формулировке обязательно: что включено, что нет, канал, срок реакции. Параллельно — договор поддержки, который вступает в силу со следующего дня после окончания гарантии. Это превращает мутную часть договора в управляемый процесс и закрывает половину конфликтов с клиентами.