Гарантийный период после запуска сайта — что включать

Гарантия после запуска сайта — самая мутная часть договора. У одних «3 месяца на всё, включая хотелки», у других «исправление багов, выявленных в первые 14 дней». Разбираем, что реально стоит включать в гарантию, что вынести в платную поддержку и как формулировать в договоре.

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

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

Что такое гарантия по сути

Гарантия — это обязательство устранить за свой счёт ошибки в выполненной работе, обнаруженные в течение определённого срока после приёмки. Юридически это статья 723 ГК РФ для договора подряда (для разработки сайтов чаще применяется именно подряд или возмездное оказание услуг).

Ключевое слово — ошибки в выполненной работе. Новые требования, изменения, доработки и хотелки — это не гарантия. Это новая работа.

Что стоит включать в гарантию

  1. Исправление багов, появившихся не из-за действий клиента. Кнопка перестала отправлять форму, при определённой ширине экрана едет вёрстка, выпала иконка после обновления PHP — это гарантийный случай.
  2. Несоответствие согласованному ТЗ/макету. В макете хедер занимал 80px, в проде — 120px. Согласовали и забыли проверить — фиксим бесплатно.
  3. Восстановление работоспособности после собственного релиза. Если ваш патч сломал работающий блок — чините за свой счёт без таймера.
  4. Совместимость со стартовым списком браузеров. Договорились про последние Chrome, Safari, Firefox, Edge и Яндекс.Браузер — обеспечиваем работу в них в течение гарантии.
  5. Безопасностные дыры в вашем коде. Если эксплойт был в коде студии (не в чужом плагине, не в библиотеке) — закрываем бесплатно.

Что не стоит включать

  1. Новые функции и контент. «Добавьте ещё одну форму на сайт» — это новая работа, не гарантия.
  2. Изменения в дизайне и тексте. Решили перекрасить акцент с красного на синий — оплачивается отдельно.
  3. Проблемы из-за хостинга, домена, SSL. Если клиент не продлил домен или сменил тариф у хостера — не ваша зона.
  4. Проблемы из-за обновлений сторонних сервисов. Сменилось API ЮKassa, обновился CDEK, сломалась интеграция с CRM — это поддержка, не гарантия (если только вы прямо не зашили устаревшую версию намеренно).
  5. Действия клиента в админке. Сам поменял шаблон, удалил блок, перезаписал картинку — чините за деньги.
  6. Атаки и взломы. DDoS, попытки RCE, утечка паролей админа — это не качество разработки.
  7. Обновление зависимостей. Через год вышел 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 рабочий день. Не «в течение часа» — иначе клиенты привыкают писать ночью.

Учёт времени по гарантии

Даже бесплатные работы фиксируйте в трекере. Это даёт две вещи:

  1. Понимание реальной экономики проекта: «на сайте X мы потратили 28 часов в гарантию — нужно поднять цену похожих проектов на 20%».
  2. Аргумент в разговоре с клиентом, который начинает запрашивать «ещё и вот это поправьте, и вот это»: «За месяц по вашему сайту мы закрыли 12 обращений на 9 часов работы. Это в рамках гарантии. То, что вы просите сейчас — изменение в макете, выходящее за пределы гарантии. Стоимость такая-то».

Гарантия и интеграции

Самая больная зона. Сайт интегрирован с amoCRM, ЮKassa, СДЭК, Wildberries. Что-то перестало работать. Источников может быть три:

  1. Ваш код (гарантия).
  2. Изменения на стороне сервиса (не гарантия).
  3. Изменения настроек у клиента (не гарантия).

Чтобы не спорить каждый раз, в договоре прописывайте: «Студия гарантирует работоспособность интеграции на момент сдачи. Изменения API на стороне сторонних сервисов и изменения конфигурации Заказчиком устраняются по отдельным заявкам в рамках договора поддержки».

Связка с договором поддержки

Хороший приём — продлевать клиента в платную поддержку сразу по окончании гарантии. Договор поддержки заключается одновременно с основным договором, действует с 91-го дня (если гарантия 90 дней). Тарификация в часах или фиксе.

Это упрощает три вещи:

  • Клиент не ищет, кому платить за «маленькую доработку» через 3 месяца.
  • Студия не теряет связь с проектом сразу после запуска.
  • Снимается давление «всё ещё гарантия?» — есть понятная граница и продолжение.

Грабли, на которые наступают

  • «Я уже отдал акт, можете не отвечать». Подписанный акт ≠ окончание гарантии. Игнор гарантийных обращений приводит к минусам в отзывах и иногда в суд.
  • «Поправим в гарантии, всё равно мелочь». Каждая «мелочь без счёта» приучает клиента, что всё бесплатно. Через 2 месяца оплачиваемых заявок ноль.
  • Размытое «гарантия на качество». В суде такая формулировка не помогает, в переговорах — тоже.
  • Гарантия без приёмки. Если акт не подписан, формально работа не сдана и срок гарантии не идёт.

Вывод

Гарантия в договоре веб-студии — не «3 месяца на всё», а конкретный перечень случаев и стоп-список. Длительность — от 30 до 180 дней под объём проекта. В формулировке обязательно: что включено, что нет, канал, срок реакции. Параллельно — договор поддержки, который вступает в силу со следующего дня после окончания гарантии. Это превращает мутную часть договора в управляемый процесс и закрывает половину конфликтов с клиентами.