Как веб-студии обманом удерживают своих клиентов

Почему некоторые веб-студии не хотят отпускать клиентов

Заказывая разработку сайта, предприниматель рассчитывает получить готовый инструмент для своего бизнеса. Он оплачивает работу, согласовывает дизайн, функциональность и сроки, а после запуска планирует самостоятельно управлять сайтом или при необходимости обращаться к другим специалистам.

Но иногда всё складывается иначе.

Сайт работает, деньги уплачены, а заказчик неожиданно выясняет, что не может поменять разработчика, перенести сайт на другой хостинг, установить новый функционал или даже получить доступ к собственному домену.

Любая попытка что-то изменить заканчивается одинаково:

«Обратитесь к нам. Самостоятельно это сделать нельзя».

Причём проблема далеко не всегда связана с технической сложностью сайта. Иногда зависимость создаётся искусственно, чтобы клиент продолжал оплачивать услуги одной и той же компании.

Важно понимать: не каждая веб-студия использует подобные методы. Многие добросовестно разрабатывают сайты, предоставляют доступы и заинтересованы в долгосрочном сотрудничестве благодаря качеству работы.

Но существуют практики, которые должны насторожить заказчика ещё до подписания договора.

1. Сайт оплачен, но фактически вам не принадлежит

Одна из самых неприятных ситуаций — когда заказчик оплатил разработку, но не получил полноценного контроля над результатом.

Например, веб-студия регистрирует домен на себя, размещает сайт на собственном сервере, создаёт административные учётные записи и не передаёт клиенту основные доступы.

Пока сотрудничество продолжается, всё выглядит нормально.

Проблемы начинаются, когда заказчик решает сменить подрядчика.

В ответ он может услышать:

• «Мы не передаём доступ к серверу».

• «Домен зарегистрирован на нашу компанию».

• «Исходный код является нашей собственностью».

• «Перенос сайта возможен только за отдельную плату».

• «Без нашего обслуживания сайт перестанет работать».

В результате клиент оказывается зависимым от подрядчика, даже если полностью оплатил согласованную разработку.

Кому на самом деле принадлежит сайт?

Здесь необходимо различать несколько вещей:

• Доменное имя — право использования зарегистрированного домена.

• Хостинг — услуга размещения сайта.

• Исходный код — программная часть проекта.

• Дизайн и контент — отдельные результаты интеллектуальной деятельности.

• База данных — информация, необходимая для работы сайта.

• Лицензии — права использования CMS, шаблонов, плагинов и сторонних сервисов.

Оплата разработки не всегда автоматически означает передачу всех исключительных прав. Это зависит от договора, характера созданных материалов и применимого законодательства.

Поэтому ещё до начала работ важно определить, какие права получает заказчик и что именно ему передадут после завершения проекта.

Как защититься: регистрируйте домен на себя или свою компанию, оформляйте хостинг на собственный аккаунт и заранее фиксируйте порядок передачи исходных файлов, базы данных, административных доступов и прав на результаты разработки.

2. Искусственная зависимость от технической поддержки

Представим обычный корпоративный сайт на WordPress.

Заказчику нужно заменить номер телефона, изменить стоимость услуги или добавить фотографию.

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

Но иногда клиенту намеренно оставляют ограниченные возможности.

Например, запрещают редактировать определённые блоки, не предоставляют права администратора или создают систему, в которой даже простое изменение требует обращения к разработчику.

В итоге появляются регулярные расходы:

«Изменить телефон — платно».

«Добавить новый раздел — только через нас».

«Обновить информацию — отправьте заявку в техническую поддержку».

Когда ограничения оправданы

Не всякое ограничение доступа является обманом.

Например, сотруднику, который публикует новости, действительно необязательно предоставлять права на установку плагинов и изменение системных настроек.

Это нормальная практика безопасности.

Но собственник сайта должен иметь возможность получить необходимый уровень контроля и передать обслуживание другому специалисту в рамках условий договора.

Признак недобросовестной практики — не само ограничение, а отказ предоставить владельцу возможность управлять оплаченным проектом без объективной причины.

3. Дешёвый сайт, который постоянно дорожает

Ещё одна распространённая схема строится вокруг привлекательной первоначальной цены.

Клиенту предлагают разработать сайт значительно дешевле конкурентов.

Например:

«Корпоративный сайт под ключ — 20 000 рублей».

Предложение выглядит выгодным, особенно если заказчик впервые сталкивается с разработкой.

Но после заключения договора выясняется, что первоначальная стоимость включает только минимальный набор работ.

За остальное предлагают доплатить:

• адаптацию под мобильные устройства;

• настройку форм обратной связи;

• базовую SEO-подготовку;

• дополнительные страницы;

• подключение аналитики;

• перенос на хостинг;

• исправление замечаний;

• обучение работе с сайтом.

Сама по себе дополнительная оплата не является обманом. Например, если заказчик после согласования проекта решил добавить интернет-магазин, это действительно новая задача.

Проблема возникает, когда клиенту обещали полноценный сайт, но необходимые для его работы функции намеренно исключили из сметы или скрыли их стоимость.

Как отличить дополнительные работы от навязанных

Здесь помогает простой вопрос:

Эта работа входила в первоначально согласованный результат или появилась по моей новой инициативе?

Если функция была предусмотрена техническим заданием, но подрядчик требует повторную оплату за её реализацию, необходимо проверить договор.

Если заказчик действительно изменил требования, дополнительная стоимость может быть обоснованной.

В России с 1 сентября 2025 года усилены положения статьи 16 Закона «О защите прав потребителей» о согласии на дополнительные платные услуги. Однако следует учитывать, что этот закон применяется к потребительским отношениям, а не автоматически ко всем договорам между компаниями.

4. Исправление собственных ошибок за деньги клиента

Допустим, студия сдала сайт.

Через несколько дней заказчик обнаруживает:

• форма заявки не отправляет сообщения;

• меню некорректно работает на телефоне;

• изображения выходят за границы экрана;

• кнопки ведут на неправильные страницы;

• часть функций работает не так, как согласовывалось.

Клиент обращается к разработчику.

Но вместо исправления получает предложение оплатить дополнительные часы работы.

Здесь важно разделять ошибку и доработку.

Конкретные обязанности по устранению недостатков зависят от договора, гарантийных условий и применимого законодательства.

Как избежать споров

В договоре и техническом задании необходимо заранее определить:

• какие функции должны работать;

• какие устройства и браузеры поддерживаются;

• как проводится тестирование;

• сколько времени отводится на устранение замечаний;

• какие работы считаются гарантийными;

• что относится к новым пожеланиям заказчика.

Чем подробнее согласованы требования, тем сложнее выдать исправление недоработки за новую платную услугу.

5. Вечная разработка без конкретных сроков

Некоторые проекты действительно сложны и требуют много времени.

Но если разработка небольшого корпоративного сайта постоянно затягивается, а подрядчик не может объяснить причины, это повод насторожиться.

Особенно если в договоре отсутствуют конкретные этапы.

Вместо понятного плана заказчик получает сообщения:

«Работаем над дизайном».

«Программист занимается функционалом».

«Осталось совсем немного».

«Скоро всё будет готово».

Проходит месяц, затем второй, а оценить фактический объём выполненной работы невозможно.

Как должны выглядеть этапы разработки

Например:

1. Анализ требований и техническое задание.

2. Проектирование структуры сайта.

3. Разработка и согласование дизайна.

4. Вёрстка и программирование.

5. Наполнение контентом.

6. Тестирование.

7. Запуск и передача проекта.

Для каждого этапа желательно определить результат, срок, стоимость и порядок приёмки.

Так клиент понимает, за что платит и что уже выполнено.

Отсутствие прозрачных этапов не доказывает обман, но существенно увеличивает риск споров и бесконтрольного роста бюджета.

6. Навязывание дорогой CMS и ненужного функционала

Иногда клиенту предлагают техническое решение, которое значительно превосходит реальные потребности бизнеса.

Например, небольшой компании нужен информационный сайт с десятью страницами и формой обратной связи.

Но подрядчик настаивает на дорогой платформе, сложной инфраструктуре и индивидуальных модулях.

Аргументы могут звучать убедительно:

«Это профессиональная система».

«На обычной CMS серьёзные сайты не делают».

«Вам обязательно нужна индивидуальная разработка».

«Без этой лицензии сайт будет небезопасным».

В действительности выбор платформы должен зависеть от задач проекта.

WordPress, 1С-Битрикс, готовый SaaS-сервис или индивидуальная разработка могут быть правильным решением в разных обстоятельствах.

Почему это выгодно недобросовестному подрядчику

Чем сложнее и специфичнее система, тем выше потенциальные расходы на разработку, сопровождение и дальнейшие изменения.

Если архитектура плохо документирована, клиенту дополнительно становится трудно найти нового специалиста.

Но сложная технология сама по себе не означает навязывание.

Подрядчик должен объяснить, какие конкретные задачи невозможно или нецелесообразно решить более простым способом.

Если такого объяснения нет, стоит получить альтернативное техническое предложение.

7. Специально запутанный код и закрытые решения

Это менее заметная, но потенциально серьёзная проблема.

Заказчик не обязан разбираться в PHP, JavaScript или структуре базы данных.

И этим иногда пользуются.

Вместо понятной архитектуры проект может содержать:

• нестандартную организацию файлов без документации;

• жёстко прописанные адреса и настройки;

• зависимости от серверов подрядчика;

• собственные модули без инструкций;

• изменения стандартных файлов CMS;

• код, который трудно сопровождать.

Не стоит автоматически считать плохой код результатом умысла. Чаще причиной бывают спешка, недостаток квалификации или технический долг.

Но последствия для клиента могут быть одинаковыми.

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

Как распознать проблему

Перед приёмкой сложного проекта полезно заказать независимую техническую проверку.

Она поможет оценить:

• возможность переноса сайта;

• наличие исходного кода;

• структуру проекта;

• безопасность;

• использование лицензий;

• качество документации;

• наличие критических зависимостей от подрядчика.

Это особенно важно для интернет-магазинов, каталогов и нестандартных веб-приложений.

8. Обязательное обслуживание, без которого сайт якобы перестанет работать

После запуска клиенту предлагают ежемесячную техническую поддержку.

Это нормальная услуга.

Сайту действительно могут требоваться обновления, резервное копирование, мониторинг безопасности, исправление ошибок и обслуживание сервера.

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

Например:

«Если перестанете платить, сайт отключится».

«Без нашей подписки сайт не будет работать».

«Только мы можем обновлять систему».

Что нужно проверить

Необходимо понять, за что именно клиент платит.

Одно дело — обслуживание сайта, размещённого на собственном хостинге заказчика.

Другое — аренда сайта или SaaS-платформа, где работоспособность действительно зависит от активной подписки.

Оба варианта могут быть законными и удобными.

Проблема возникает, когда клиенту продают сайт как собственный готовый продукт, а ограничения и обязательные платежи раскрывают только после запуска.

9. Красивые SEO-отчёты без понятного результата

В сфере продвижения сайтов встречается другая проблема — подмена результата активностью.

Клиент ежемесячно получает отчёт:

«Оптимизировано 30 страниц».

«Проверено 500 запросов».

«Подготовлено 15 рекомендаций».

«Проведён технический аудит».

Сами по себе эти работы могут быть полезны.

Но заказчику важно понимать, что изменилось благодаря им.

Например:

• вырос ли целевой органический трафик;

• улучшилась ли видимость по важным запросам;

• увеличилось ли количество качественных заявок;

• устранены ли технические ошибки;

• какие страницы стали приносить больше обращений.

Почему нельзя верить гарантиям первого места

Google прямо предупреждает: никто не может гарантировать первое место в поисковой выдаче. Поисковые системы используют множество факторов ранжирования, а подрядчики не контролируют их алгоритмы.

Поэтому обещания вроде «гарантируем ТОП-1 за месяц» должны вызывать вопросы.

Это не означает, что SEO невозможно прогнозировать. Специалист может оценивать потенциал, ставить цели и отвечать за качество выполненных работ.

Но гарантировать конкретную позицию по любому запросу он не может.

10. Накрутка трафика и сомнительные заявки

Одна из самых неприятных ситуаций в интернет-маркетинге — когда показатели растут, а реальных клиентов больше не становится.

Например, подрядчик показывает:

«Посещаемость увеличилась в три раза».

Но при проверке выясняется, что значительная часть посещений не относится к целевой аудитории.

Или заказчик получает много заявок, но люди не отвечают на звонки, оставляют некорректные контакты либо вообще не интересуются услугой.

Причины могут быть разными: некачественная настройка рекламы, боты, ошибочная аналитика, случайные обращения или намеренная накрутка.

Нельзя автоматически считать каждый некачественный лид мошенничеством.

Но если подрядчик отказывается показывать источники трафика, рекламные расходы и данные о заявках, это серьёзный повод проверить работу.

Что должен видеть заказчик

Желательно иметь собственный доступ к:

• рекламным кабинетам;

• системам веб-аналитики;

• Google Search Console и Яндекс Вебмастеру;

• CRM и истории заявок;

• статистике рекламных расходов.

Отчёт подрядчика не должен быть единственным источником информации о результатах продвижения.

11. Рекламные кабинеты и аналитика оформлены на студию

Ещё одна форма зависимости возникает, когда вся цифровая инфраструктура бизнеса создаётся на аккаунтах подрядчика.

Студия управляет рекламой, аналитикой, поисковыми инструментами и другими сервисами.

Пока сотрудничество продолжается, это удобно.

Но при смене подрядчика может выясниться, что заказчик не имеет административных прав.

В результате он рискует потерять доступ к накопленной статистике, настройкам рекламных кампаний или связанным ресурсам.

Например, Google Search Console предусматривает разные уровни доступа, включая подтверждённых владельцев и пользователей с ограниченными правами.

В официальной документации Google также описан порядок удаления пользователей и токенов подтверждения собственности.

Правильный подход: ключевые аккаунты принадлежат заказчику, а подрядчик получает необходимые права для работы.

12. Удержание домена как способ давления

Домен — один из важнейших активов сайта.

Именно на него могут быть завязаны:

• корпоративная почта;

• поисковый трафик;

• реклама;

• ссылки;

• репутация компании;

• клиентские обращения.

Если домен зарегистрирован на подрядчика, а не на заказчика, возникает серьёзный риск.

При конфликте компания может столкнуться с трудностями при управлении доменом или его переносе.

Для международных доменов, подпадающих под правила ICANN, предусмотрены процедуры смены регистратора и получения кода переноса Auth-Code.

Однако эти правила не следует автоматически переносить на все национальные доменные зоны: у них могут быть собственные регламенты.

Самый надёжный вариант — с самого начала регистрировать домен на фактического владельца бизнеса и сохранять контроль над аккаунтом регистратора.

13. Давление через страх и технические угрозы

Иногда клиенту пытаются внушить, что смена подрядчика обязательно приведёт к серьёзным проблемам.

Например:

«Другие разработчики сломают сайт».

«После переноса пропадут все позиции в поиске».

«Мы используем уникальную технологию, никто другой в ней не разберётся».

«Без нашего сервера сайт станет небезопасным».

В отдельных случаях предупреждения могут быть обоснованными.

Например, неправильный перенос действительно способен привести к недоступности сайта, потере данных или ошибкам SEO.

Но добросовестный специалист объяснит конкретные риски и предложит способы их уменьшения.

Недобросовестный подрядчик использует страх, не предоставляя технических доказательств.

Разница принципиальная:

предупреждать о рисках нормально, использовать их для давления на клиента — нет.

14. Что происходит, когда клиент решает уйти

Представим, что предприниматель несколько лет работал с одной веб-студией.

В какой-то момент он решил сменить подрядчика.

И только тогда обнаружил:

• домен зарегистрирован не на него;

• доступа к хостингу нет;

• резервной копии сайта нет;

• исходный код не передан;

• рекламные кабинеты принадлежат агентству;

• часть функционала зависит от сторонних платных сервисов;

• технической документации не существует.

Теперь вместо простой смены разработчика приходится решать целый набор проблем.

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

Именно поэтому зависимость от подрядчика опасна не только дополнительными ежемесячными расходами.

Она может поставить под угрозу работу бизнеса.

15. Как проверить веб-студию перед заказом сайта

Необязательно быть программистом, чтобы снизить риски.

Достаточно заранее задать несколько конкретных вопросов.

Особенно настороженно стоит относиться к подрядчикам, которые отказываются обсуждать эти вопросы до оплаты.

16. Что делать, если студия уже удерживает сайт

Если конфликт уже возник, действовать лучше последовательно.

Сначала соберите документы

Подготовьте договор, техническое задание, приложения, акты, счета, подтверждения оплаты и переписку.

Важно установить, какие работы были заказаны, что фактически оплачено и какие обязанности по передаче результатов предусмотрены договором.

Проверьте, что находится под вашим контролем

Установите, на кого зарегистрированы домен и хостинг, кто владеет административными аккаунтами и какие резервные копии существуют.

По возможности обеспечьте сохранность доступных вам данных. Не удаляйте учётные записи и не меняйте критические настройки без понимания последствий.

Направьте письменный запрос

Попросите подрядчика передать предусмотренные договором материалы и доступы.

Лучше указать конкретный перечень и разумный срок ответа.

Если подрядчик отказывается, попросите объяснить причины со ссылкой на условия договора.

Получите независимую техническую оценку

Другой специалист сможет определить, можно ли перенести сайт, какие данные доступны, существуют ли технические ограничения и насколько сложной будет миграция.

Это помогает отделить реальные проблемы от необоснованных требований.

При необходимости обратитесь за юридической помощью

Права заказчика зависят от договора, применимого законодательства и статуса сторон.

Особенно важно учитывать, что договор между двумя компаниями не равнозначен потребительскому договору с физическим лицом.

Поэтому универсального правила «студия обязана немедленно передать абсолютно всё» не существует.

Но и утверждение подрядчика «мы разработали сайт, значит всё принадлежит нам» не следует принимать без проверки документов.

17. Как выглядит честная работа с разработчиком

У добросовестного сотрудничества есть простой признак: заказчик понимает, за что платит и что получает.

Ему не приходится гадать, кому принадлежит домен, где размещён сайт и сколько будет стоить следующая доработка.

Нормальная работа предполагает:

• прозрачную стоимость;

• согласованное техническое задание;

• понятные сроки;

• заранее определённые условия дополнительных работ;

• доступ к результатам разработки;

• понятные правила гарантийного обслуживания;

• документированные технические ограничения;

• возможность передать проект другому специалисту в рамках согласованных прав.

При этом честная веб-студия не обязана работать бесплатно, бесконечно исправлять новые пожелания или раскрывать собственные внутренние инструменты, не входящие в договор.

Суть не в том, чтобы переложить все риски на разработчика.

Суть в том, чтобы обе стороны заранее понимали свои обязательства.

Вывод: хороший подрядчик не боится потерять клиента

Самая опасная зависимость возникает тогда, когда бизнес не может самостоятельно распоряжаться своим сайтом.

Заказчик платит за разработку, обслуживание и продвижение, но постепенно теряет контроль над технической инфраструктурой.

И чем дольше продолжается такое сотрудничество, тем сложнее и дороже бывает сменить подрядчика.

Поэтому при выборе веб-студии я рекомендую смотреть не только на портфолио, стоимость и обещанные сроки.

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

Хороший разработчик удерживает клиентов качеством работы, а не отсутствием у них возможности уйти.

Если заказчик доволен результатом, ему не нужно запрещать менять подрядчика, скрывать доступы или создавать искусственные сложности.

Он продолжит сотрудничество добровольно.

Именно такие отношения я считаю основой профессиональной разработки сайтов.