Own your stack: why we hand over documented code you control

Between 2015 and 2025, IBM software prices rose by nearly 80%. VMware customers are reporting increases of 150% to 1,200% as perpetual licences are forcibly converted to subscription bundles. Microsoft is implementing M365 increases effective 2026: frontline worker licences are rising 25 to 33%, higher business tiers 12 to 17%. These are not exceptions. They are the direction the entire industry is moving, which is why the question of what you actually own in your technology stack is becoming a strategic one.

What vendor lock-in actually costs

Vendor lock-in is not just the cost of a potential migration. It is a daily cost paid in lost negotiating leverage, the inability to respond to changing requirements, and the risk of disruption when a vendor changes its business model. The migration cost only appears if you actually try to leave. The lost flexibility and the risk you pay regardless of whether you ever think about switching.

Companies most exposed to lock-in are often those who do not realise it until something changes. A vendor announces end-of-life for the version they are running. Pricing changes make the economics unworkable. A competitor builds on an open platform and iterates faster because they control their own tooling. 70% of organisations have already adopted multi-cloud strategies partly to spread the risk of lock-in, and 48% of technology companies cite avoiding vendor dependence as a key reason for using multiple cloud providers simultaneously.

Three dimensions of ownership

Genuine ownership of your software stack means control in three dimensions simultaneously, not just one:

• Code ownership: you have access to the source code, the right to modify it, and the ability to understand it without involving the vendor.
• Data ownership: your data is stored in a format you can read and export, on infrastructure you control or can move without vendor cooperation.
• Infrastructure ownership: you can run the system wherever you choose, scale it to your needs, and move it without rebuilding the application from scratch.

Most companies have some of these, not all three. A SaaS product may give you data exports but no code access. An open-source tool may give you code but require a specific cloud provider for managed hosting. Understanding which dimensions of ownership you actually have changes how you assess risk and what you negotiate for in contracts.

What documented handover looks like in practice

Code that exists but cannot be understood by anyone outside the original team is not much better than code you do not have. When we hand over a project, the deliverable is not just the repository. It is the repository plus enough context for a developer who was not part of the project to run it, understand its structure, debug a problem, and make a change without breaking something else.

This means environment setup that works on a clean machine, not only on the original developer's configuration. Documented deployment procedures that reflect how the system actually deploys. Architecture decisions written where the code implementing them lives, so the reasoning is visible alongside the result. Documentation living in a separate wiki and not actively maintained goes stale within months. Documentation woven into the project stays current because it must be updated alongside the code.

The open door test

A practical way to assess whether you truly own your software: could a competent developer with no prior involvement get it running, understand its structure, and make a meaningful change within a week? If yes, you have something close to real ownership. If the answer requires long onboarding calls, knowledge living only in specific people's heads, or dependence on the original team for any non-trivial change, you have a real problem.

This test matters because teams change. The people who built the system move on. Business relationships end. A system that only a specific group can maintain is a liability disguised as an asset. The goal of good software delivery is a product that serves your company not only when the original team is available, but indefinitely, in the hands of anyone who needs to work with it.