The cost of vendor lock‑in
Classic scenario: the agency shipped a project on custom Bitrix with unique components and no documentation. A year later you want to switch — and hear "your build is non‑standard, we'll need 2 months to figure it out, +$20K".
That's vendor lock‑in in action. Direct cost — 20–50% of the new project budget. Indirect — no flexibility, no negotiation leverage, dependency on specific people at the current agency.
Four types of lock‑in
- Custom code lock‑in. Unique components without documentation. Cure: require JSDoc/PHPDoc and a README on every significant feature.
- Infrastructure lock‑in. CI/CD, secrets, cloud accounts — owned by the agency. Cure: everything in your accounts from day one.
- License lock‑in. Code is owned by the agency, you only get a "license to use". Cure: full IP transfer in the contract.
- Platform lock‑in. Closed SaaS with no data export. Cure: open‑core platforms under MIT/Apache.
What to put in the contract
1. IP transfer
Clause: "Exclusive rights to the code, design files and documentation pass to the Customer upon sign‑off of the phase acceptance act." Without it, agency lawyers can later interpret it as a license.
2. Documentation as scope
Documentation is a separate deliverable, not an attachment. Minimum: architecture diagram, API reference, runbook, ADRs (architecture decision records) on key forks.
3. Handoff package
An explicit list of artifacts handed over at project close (see below). No clause, no obligation.
4. Penalty for missing artifacts
If docs are missing at handoff — 10% penalty on the phase fee. Motivates the agency to write docs continuously, not at the last minute.
Handoff artifacts
- All source code in your Git (not the agency's).
- C4 architecture diagram (Context / Container / Component).
- API reference (OpenAPI / GraphQL schema).
- DB schema with ER diagram.
- Infrastructure code (Terraform / Ansible / docker‑compose).
- CI/CD pipelines in your GitHub/GitLab.
- Runbook for common incidents (500s, sync failed, payments failing).
- Knowledge base accessible to your team.
- 30–60 min architecture walkthrough recording by the agency CTO.
Open‑core: what and why
Open‑core is a model where the core of the product is released under an open‑source license (MIT/Apache) and commercial add‑ons are paid. Examples: Medusa, Saleor, our Frontbox.
Why it protects from lock‑in:
- Even if the vendor disappears, your team can maintain and extend the core on their own.
- There are other agencies on the market that know the same open‑core. You can switch teams without "rewriting".
- A community pool of bug fixes and security patches — you don't pay for every update.
Pre‑signing checklist
- ☐ Contract has an IP transfer clause for code and documentation.
- ☐ Full handoff package is listed.
- ☐ Penalty for missing documentation is specified.
- ☐ All infra accounts are yours (not the agency's).
- ☐ Git repo — yours.
- ☐ Platform — open‑source or open‑core under MIT/Apache.
- ☐ There's a backup agency that knows the same platform.
- ☐ You're not paying for a "license to use the code".