Что такое vendor lock-in и как не попасть в зависимость
Основы3 минРедакция Innovialabs
Коротко
Vendor lock-in — ситуация, когда уйти от подрядчика или платформы слишком дорого или невозможно, потому что код, данные или доступы контролирует не вы. Защита простая: аккаунты на вашем имени, код в вашем репозитории, данные в открытых форматах и документация.
Коротко: что такое vendor lock-in
Vendor lock-in (привязка к поставщику) — состояние, при котором смена подрядчика, сервиса или платформы обходится настолько дорого, что вы фактически не можете её сделать. Вы продолжаете работать с текущим поставщиком не потому, что он лучший, а потому, что уйти слишком сложно.
Зависимость сама по себе нормальна: любой бизнес опирается на внешние сервисы. Проблема начинается, когда вы не контролируете ключевые активы — код, данные и доступы.
Как формируется зависимость
От подрядчика
- Код не у вас. Репозиторий на аккаунте подрядчика, исходники не передаются, есть только работающий сайт или приложение.
- Аккаунты на чужом имени. Домен, хостинг, облако, App Store, Google Play, платёжные системы зарегистрированы на подрядчика.
- Закрытая разработка. Продукт построен на внутреннем фреймворке или конструкторе подрядчика, с которым никто больше не умеет работать.
- Нет документации. Архитектура, настройки серверов и интеграции существуют только в голове одного разработчика.
- Договор без прав. Не прописано, кому принадлежат исключительные права на код.
От платформы
- Закрытые данные. Сервис не даёт выгрузить данные целиком или отдаёт их в неудобном формате.
- Проприетарные функции. Логика завязана на специфичные возможности одного облака или SaaS, у которых нет аналогов.
- Стоимость переезда. Перенос больших объёмов данных, переобучение сотрудников и перенастройка интеграций.
Признаки, что вы уже в зависимости
- Вы не можете сами зайти в админку хостинга или облака.
- Для любой мелкой правки нужно обращаться только к одному человеку.
- Вы не знаете, где лежит исходный код и как его собрать.
- Подрядчик повышает цены, а сравнить с рынком невозможно: никто другой не возьмётся.
Как защититься: чек-лист
| Актив | Что сделать |
|---|---|
| Домен и DNS | регистрировать на компанию, доступ у владельца бизнеса |
| Хостинг и облако | аккаунт и платёжный метод ваши, подрядчику — отдельный доступ |
| Код | репозиторий в вашей организации на GitHub, GitLab или аналоге |
| Сторы и платежи | аккаунты разработчика и мерчанта на вашу компанию |
| Данные | регулярные бэкапы и проверенная выгрузка в открытых форматах |
| Документация | README, схема архитектуры, инструкция по развёртыванию |
| Договор | передача исключительных прав и порядок передачи дел |
Дополнительно помогает выбор распространённых технологий. Если продукт написан на популярном стеке, найти другую команду проще, чем для редкого или самописного решения.
Как работать с облачными платформами
Полностью избегать специфичных сервисов облака не всегда разумно: они экономят время. Подход проще — осознанно выбирать, где зависимость допустима:
- Держите бизнес-логику в своём коде, а не в настройках закрытого сервиса.
- Используйте стандарты там, где это не дорого: контейнеры, SQL-базы, открытые протоколы.
- Перед подключением сервиса проверьте, как из него выгрузить данные.
- Записывайте, какие компоненты сложнее всего заменить, и пересматривайте этот список.
Частые ошибки
- «Подрядчик всё сам зарегистрирует» — удобно на старте, дорого при расставании.
- Доверие вместо договора: хорошие отношения не заменяют пункт о правах на код.
- Бэкапы, которые никто не проверял: копия, из которой нельзя восстановиться, не защищает.
- Отказ от любой зависимости: самописные решения вместо проверенных сервисов создают зависимость уже от своих разработчиков.