Гарантия на сайт — это не холодильник с двухлетним сроком. Разбираемся, за что реально отвечает веб-студия, что входит в техподдержку, как защитить свои права и не остаться один на один с кодом после сдачи проекта. Конкретика без воды.
«Доверяй, но проверяй — особенно когда речь идёт о технологиях»
— переосмысление народной мудрости
😰 Страх остаться один на один с кодом
Звонок раздался в пятницу вечером. Голос в трубке — уставший, с нотками отчаяния: «Ваш телефон единственный, который я нашёл. Сайт лежит третий день, а тот, кто его делал, просто исчез. Телефон недоступен, почта не отвечает».
Честно говоря, таких звонков за 15 лет было немало. И каждый раз — одна и та же история. Человек заплатил деньги, получил сайт, какое-то время всё работало. А потом что-то пошло не так, он потянулся к подрядчику за помощью — а там тишина. Номер не существует. Контора по юрадресу не значится. Классика жанра.
По данным отраслевых исследований, страх остаться без поддержки входит в топ-3 болей заказчиков веб-услуг. И это не паранойя — это здравый смысл. Потому что статистика неутешительная: в 80% случаев при небольших бюджетах исполнители просто «испаряются» после сдачи проекта. Получили деньги, закрыли задачу, пошли дальше. А клиент остаётся один на один с кодом, в котором ничего не понимает.
Так вот, давайте разберёмся: что на самом деле должна гарантировать веб-студия, где заканчивается её ответственность, и как защитить себя от ситуации «подрядчик исчез, а сайт сломался». Без воды, по существу.
🔍 Что такое гарантия на сайт в реальности
Миф о «вечной гарантии»
Знаете, что меня всегда удивляло? Люди почему-то думают, что гарантия на сайт работает как гарантия на холодильник. Купил, получил талон, два года спишь спокойно — что бы ни случилось, приедут и починят бесплатно.
А дело в том, что сайт — это не бытовая техника. Это живой организм, который взаимодействует с десятками внешних систем: хостингом, платёжками, службами доставки, поисковиками, браузерами. И каждая из этих систем постоянно меняется. Обновился браузер — что-то может поехать. Хостинг сменил настройки PHP — часть функций отвалилась. Яндекс поменял API карт — виджет перестал работать.
Так что реально покрывает гарантия? Исправление ошибок, допущенных при разработке. Баги в коде, которые мы сами написали. Функционал, который работает не так, как было описано в техническом задании. Вот это — да, это гарантийный случай. А вот если что-то сломалось из-за внешних факторов или ваших собственных действий — это уже другая история.
Стандарт рынка по срокам: от одного до трёх месяцев после сдачи проекта. Некоторые дают больше, но тут важно смотреть, что конкретно входит в эту «расширенную гарантию». Иногда за красивыми цифрами скрывается пустота.
Гарантия на лицензию и гарантия на работы — это разные вещи
И вот тут начинается самое интересное. Если вы покупаете сайт на базе готового решения (например, на 1С-Битрикс), то гарантий у вас фактически две. И они разные.
Первая — гарантия от вендора. Компания, которая создала CMS или шаблон, отвечает за работоспособность своего продукта. Обновляет его, исправляет уязвимости, добавляет функции. Это их зона ответственности.
Вторая — гарантия от студии на работы по настройке и доработке. Мы установили систему, настроили под вас, подключили платёжку, сделали индивидуальные доработки. Вот за это отвечаем мы.
Аналогия простая: вы покупаете машину (это лицензия на CMS) и оплачиваете тюнинг под себя (это работы студии). Если через год у машины отзывная кампания по подушкам безопасности — это к производителю. Если после тюнинга что-то стучит — это к тем, кто тюнинговал. Разные гарантии, разные ответственные.
Можно ли получить гарантию на год? Технически — да. Но что именно она будет покрывать — вот в чём вопрос. И этот вопрос нужно задавать до подписания договора, а не после.
⚖️ Границы ответственности веб-студии
За что студия отвечает железобетонно
Давайте по-честному. Есть вещи, за которые любая нормальная веб-студия несёт полную ответственность. Без отговорок и виляний.
Работоспособность функционала согласно техническому заданию — если в ТЗ написано, что корзина должна считать скидку при заказе от трёх товаров, а она не считает, это наш косяк. Исправляем бесплатно, без разговоров.
Исправление багов, допущенных при разработке — криво работает фильтр, съезжает верстка на определённых разрешениях, форма отправляет пустые письма. Всё это — гарантийные случаи.
Корректность установки и настройки системы — если мы что-то неправильно сконфигурировали и из-за этого возникают проблемы, это тоже на нас.
Передача доступов и документации — клиент должен получить все пароли, доступы к хостингу, админке, FTP. Плюс базовую документацию по работе с сайтом. Это не бонус, это обязанность.
За что студия НЕ отвечает (и это нормально)
А теперь — момент истины. То, за что студия не несёт ответственности. И это не попытка съехать с темы, это объективная реальность.
Контент, который добавляет сам клиент. Загрузили картинку весом 15 мегабайт — сайт тормозит. Написали текст с ошибками — посетители морщатся. Удалили случайно важный раздел... ну, вы поняли.
Знаете, что меня реально выводит из себя? Когда клиент сам удаляет половину каталога, а потом звонит с претензией: «Ваш сайт сломался!» Нет, друзья. Сайт работает ровно так, как должен. Просто теперь в нём нет половины товаров. Потому что кто-то нажал не туда.
Проблемы хостинга, если его выбирал клиент самостоятельно. Мы рекомендуем определённые хостинги, проверенные годами. Если клиент решил сэкономить и взял что-то своё — окей, это его право. Но если потом сервер падает каждую пятницу вечером, мы тут ни при чём.
Изменения алгоритмов поисковиков. Яндекс обновил алгоритм, позиции просели — это не поломка сайта. Это SEO, отдельная история.
Взлом сайта при несоблюдении рекомендаций по безопасности. Мы говорим: «Поменяйте пароль админа, не используйте 123456». Клиент кивает и оставляет 123456. Через месяц сайт взломан. Ну... как бы это сказать помягче.
Если здраво смотреть на вещи, разделение ответственности — это не способ студии снять с себя обязательства. Это способ выстроить честные, понятные отношения. Когда каждый знает, за что отвечает, — меньше конфликтов и недопонимания. А это в интересах обеих сторон.
🛠️ Техническая поддержка — что входит, что нет
Гарантийная поддержка (бесплатная)
Итак, сайт сдан, акт подписан, деньги получены. Что дальше? Дальше начинается гарантийный период. Обычно это от одного до трёх месяцев — в зависимости от сложности проекта и договорённостей.
Что входит в эту бесплатную поддержку? Исправление багов, которые мы допустили при разработке. Мелкие корректировки — поправить текст в шапке, заменить номер телефона, подкрутить цвет кнопки. То есть всё, что относится к «доводке» уже сданного проекта.
А вот чего в гарантийной поддержке нет — это нового функционала. Если через месяц после запуска вы решили, что вам нужен личный кабинет или интеграция с CRM — это уже отдельный разговор и отдельный бюджет. Гарантия покрывает то, что было в техническом задании. Не больше.
Платная техподдержка (абонемент)
Гарантийный период закончился. Сайт работает, всё хорошо. Но... CMS нужно обновлять. Резервные копии делать. Следить, чтобы сертификат безопасности не протух. Мониторить, что сайт вообще доступен и не лёг посреди ночи.
Вот для этого и существует платная техподдержка. По сути, это абонемент на спокойствие. Вы платите фиксированную сумму в месяц, а мы следим за здоровьем вашего сайта.
Что обычно входит: регулярное обновление CMS и модулей, резервное копирование (чтобы было что восстанавливать, если что), мониторинг работоспособности, консультации по работе с сайтом и мелкие доработки в рамках оговорённого лимита часов.
Ценовой диапазон на рынке — от 5 до 30 тысяч рублей в месяц. Зависит от сложности проекта. Простой сайт-визитка — одна история. Интернет-магазин с тысячей товаров и интеграциями — совсем другая.
Разовые работы или абонемент — что выбрать
Я вот для себя решил так: если клиент планирует активно развивать сайт, добавлять функционал, регулярно что-то менять — абонемент выгоднее. Потому что разовые работы каждый раз требуют времени на «вникание» в проект. А на абонементе мы и так в курсе всех дел.
Если же у вас сайт-визитка, который обновляется раз в год (новый прайс загрузить, фотографию директора поменять) — разовые работы дешевле. Нет смысла платить каждый месяц за то, что нужно раз в году.
| Тип поддержки | Что входит | Стоимость | Для кого |
|---|---|---|---|
| Гарантийная | Исправление багов разработки | Бесплатно | Все проекты (1-3 мес.) |
| Базовая | Обновления + бэкапы + мониторинг | 5-10 тыс/мес | Небольшие сайты |
| Расширенная | + доработки + консультации + приоритет | 15-30 тыс/мес | Интернет-магазины, порталы |
Честно говоря, большинство наших клиентов после первого года работы переходят на абонемент. Просто потому что понимают: дешевле платить за профилактику, чем потом за экстренный ремонт.
🔄 Готовые решения vs кастомная разработка — разница в гарантиях
И вот тут начинается то, о чём редко говорят. Гарантии на сайт сильно зависят от того, как этот сайт сделан.
Если вам разрабатывают проект с нуля — индивидуальный дизайн, уникальный код, всё под вас — то вся ответственность за этот код лежит на разработчике. Он написал, он и отвечает. После полной оплаты вам передают исключительные права на результат, исходники, всё дела. Звучит хорошо. Но есть нюанс.
Нюанс в том, что если этот разработчик исчезнет (а мы помним статистику — 80% исчезают), то вы остаётесь с кодом, который понимает только он. Новому специалисту придётся разбираться в чужой логике, чужих костылях, чужих решениях. Это время и деньги.
С готовыми решениями на базе 1С-Битрикс история другая. Вы покупаете лицензию на CMS и шаблон — это продукт от вендора (Аспро, Интек, другие). Вендор его поддерживает, обновляет, исправляет уязвимости. Это первый уровень защиты.
Второй уровень — студия, которая этот продукт устанавливает и настраивает под вас. Мы отвечаем за корректность настройки, за доработки, за интеграции. Но базовый код — типовой, документированный, понятный любому специалисту по Битриксу.
Что это даёт на практике? Двойную защиту. Вендор исчез — код остался, он стандартный. Студия закрылась — другая подхватит без проблем, потому что решение типовое. Никакой привязки к конкретному программисту, который «один знает, как оно работает».
Плюс вы видите продукт до покупки. Все демо доступны, можно пощупать, покликать, понять — ваше или нет. Не кот в мешке, а конкретный товар с понятными характеристиками.
📋 Права заказчика — как защитить свои интересы
Что должно быть в договоре обязательно
Договор — это не формальность. Это ваша страховка. И есть вещи, которые там должны быть прописаны железобетонно.
Сроки гарантийного периода — конкретные даты, а не «в разумные сроки». С какого числа по какое. Чтобы потом не было разночтений.
Перечень работ, входящих в гарантию — что именно будет исправляться бесплатно. Чем конкретнее, тем лучше. «Исправление ошибок разработки» — это одно. «Любые изменения по желанию заказчика» — совсем другое (и второго в гарантии быть не должно, это уже доработки).
Порядок обращения и сроки реагирования — куда писать, если что-то сломалось. И в какие сроки вам ответят. Один рабочий день? Три? Неделя? Это важно понимать заранее.
Условия передачи доступов — когда и какие доступы вы получаете. К хостингу, к домену, к админке сайта, к FTP. Всё это должно быть у вас, а не только у подрядчика.
Чек-лист при приёмке сайта
Момент сдачи проекта — это когда нужно быть особенно внимательным. Вот что стоит проверить перед тем, как подписывать акт:
✅ Получены все доступы (хостинг, домен, админка, FTP)
✅ Есть акт приёма-передачи с описанием функционала
✅ Сделан бэкап на момент сдачи
✅ Получена документация по работе с сайтом
✅ Зафиксированы контакты для гарантийных обращений
✅ Понятен порядок продления лицензий
Простое правило, которое работает: нет доступов — нет оплаты последнего этапа. Это не жадность и не недоверие. Это здравый смысл. Потому что если подрядчик добросовестный — ему несложно передать доступы. А если начинает юлить и откладывать — это первый звоночек, что что-то не так.
По данным исследований, именно отсутствие доступов становится главной проблемой, когда приходится менять подрядчика. Сайт есть, а войти в него не можете. Домен на чужом аккаунте. Хостинг оплачен с чужой карты. И начинается квест по выцарапыванию того, что по праву ваше.
💡 Заключение — честный разговор о реалистичных ожиданиях
Знаете, на что похожа гарантия на сайт? На страховку. Важно не то, что она есть. Важно, что конкретно она покрывает. Можно купить КАСКО за копейки, а потом выяснить, что оно не распространяется на угон, ДТП и царапины. Формально страховка есть. Практически — бумажка.
С гарантиями на сайт та же история. Кто-то обещает год поддержки, но при ближайшем рассмотрении оказывается, что это год ответов на вопросы по почте. А реальные исправления — за отдельные деньги.
За 15 лет я понял простую вещь: хорошая гарантия — это не когда много обещают. Это когда чётко понимают, за что отвечают. И вы это тоже понимаете. Когда обе стороны на берегу договорились о границах — потом нет конфликтов, нет разочарований, нет ощущения обмана.
Поэтому мой совет: задавайте неудобные вопросы до подписания договора, а не после запуска. Что входит в гарантию? Что не входит? Какие сроки реагирования? Что будет через год, когда гарантия закончится?
Нормальный подрядчик на эти вопросы ответит спокойно и конкретно. А если начинает уходить от ответа или обещать золотые горы без деталей — ну, вы поняли. Это маркетинг, а не гарантия.
