Сколько стоит vendor lock‑in
Классический сценарий: студия закрыла проект на кастомном Битриксе с уникальными компонентами, документации нет. Через год вы хотите сменить подрядчика — и слышите «у вас нестандартная сборка, разбираться будем 2 месяца, это +2 млн ₽».
Это vendor lock‑in в действии. Прямая стоимость — 20–50% бюджета нового проекта. Косвенная — несвобода в выборе, отсутствие рычага переговоров, зависимость от конкретных людей в команде подрядчика.
Четыре типа lock‑in
- Lock‑in через кастомный код. Уникальные компоненты без документации. Лечится: требованием полной JSDoc/PHPDoc и README на каждую крупную фичу.
- Lock‑in через инфраструктуру. CI/CD, секреты, доступы в AWS/Yandex Cloud — у подрядчика. Лечится: всё в ваших аккаунтах с самого начала.
- Lock‑in через лицензию. Код принадлежит подрядчику, вы получаете только «право использования». Лечится: полная передача IP в договоре.
- Lock‑in через платформу. Закрытый SaaS, откуда нельзя экспортировать данные. Лечится: open‑core платформы с MIT/Apache‑лицензией.
Что писать в договоре
1. Передача IP
Пункт: «Исключительные права на созданный код, дизайн‑макеты и документацию переходят Заказчику в момент подписания акта приёмки этапа». Без этого юристы подрядчика могут потом трактовать как «лицензию».
2. Документация как часть скоупа
Документация — отдельный deliverable, не «приложение». Минимум: архитектурная схема, API‑reference, runbook, ADR (architecture decision records) по ключевым развилкам.
3. Handoff‑пакет
Явный список артефактов, которые передаются по окончании (см. ниже). Если пункта нет — нет обязательства.
4. Штраф за отсутствие артефактов
Если на handoff нет документации, штраф 10% от стоимости этапа. Это мотивирует подрядчика писать доки параллельно, а не в последний день.
Артефакты handoff
- Весь исходный код в вашем Git‑репо (не в подрядчика).
- Архитектурная схема C4 (Context / Container / Component).
- API‑reference (OpenAPI / GraphQL schema).
- Схема БД с ER‑диаграммой.
- Инфраструктурный код (Terraform / Ansible / docker‑compose).
- CI/CD пайплайны в вашем GitHub/GitLab.
- Runbook по типовым инцидентам (ответ 500, sync упал, платежи не проходят).
- Knowledge base с доступом для вашей команды.
- Видеозапись обзора архитектуры (30–60 мин) с CTO подрядчика.
Open‑core: что это и почему важно
Open‑core — модель, когда ядро продукта публикуется под open‑source лицензией (MIT/Apache), а коммерческие add‑ons платные. Пример: Medusa, Saleor, наш Frontbox.
Почему это защищает от lock‑in:
- Даже если компания‑разработчик исчезнет, ваша команда сможет поддерживать и развивать ядро самостоятельно.
- На рынке есть другие подрядчики, которые умеют работать с тем же open‑core. Вы можете сменить команду без «переписывания».
- Community‑пул багфиксов и security‑патчей — вам не нужно платить за каждое обновление.
Чек‑лист перед подписанием
- ☐ В договоре есть пункт о передаче IP на код и документацию.
- ☐ Указан полный handoff‑пакет.
- ☐ Штраф за отсутствие документации прописан.
- ☐ Все аккаунты инфраструктуры — ваши (не подрядчика).
- ☐ Git‑репо — у вас.
- ☐ Платформа — open‑source или open‑core с MIT/Apache.
- ☐ Есть запасной подрядчик, который умеет работать с той же платформой.
- ☐ Вы не платите за «лицензию на использование кода».