Renting Capability: How to Avoid Being Trapped by the Software You Depend On

There is a version of software procurement that used to feel like a trap. You bought a licence, got it installed, trained your team on it, and then spent the next decade unable to leave because the migration cost was too painful to contemplate. Enterprise software vendors built entire business models on that inertia.

Then the subscription model arrived and it seemed like the answer. No more massive upfront costs. No more being stuck. Just pay monthly, and if you do not like it, cancel and move on. Flexibility sold as a feature.

What nobody said loudly enough is that subscriptions replaced one kind of lock-in with several subtler ones. The cage got smaller and harder to see.

What lock-in actually looks like now

Nobody signs a five-year contract for their project management tool anymore. The friction is different now. It lives in your data, your integrations, and your team's muscle memory.

Your CRM holds three years of contact history and deal notes in a proprietary format. Your workflow automation tool has dozens of connected triggers that would take weeks to rebuild elsewhere. Your team has shaped their entire process around the quirks of one platform. None of that is contractual lock-in. All of it is real.

API-dependent businesses face an additional layer. When your product is built on top of someone else's API, you are not just a customer. You are a dependent. The provider changes pricing, deprecates endpoints, or shifts usage terms, and your options are: comply, rebuild, or shut down. Plenty of startups have learned this the hard way when a platform shifted the rules mid-game.

The three switching costs nobody prices in

When evaluating a new tool, most teams think about the subscription cost. Few properly price in the three costs that actually matter when something goes wrong.

Data portability. Can you get your data out, in a usable format, without paying someone to extract it? Some tools offer export as an afterthought. Others make it genuinely difficult. A CSV of your contacts is not the same as a full export of your history, relationships, and custom fields.

Workflow reconstruction. The automations you have built, the templates your team relies on, the integrations with other tools. None of that migrates automatically. Every connection has to be rebuilt from scratch in the new environment.

Institutional knowledge. Your team knows how to work around the tool's limitations. They know what breaks if you do X before Y. That knowledge lives in people's heads and undocumented habits. A migration does not transfer it. You lose it and have to rebuild it.

Together, these make switching genuinely expensive even when the contract says you can leave anytime. That is not an accident.

A short history of vendor lock-in (optional, click to expand)

Vendor lock-in is not a new problem. In the 1960s and 70s, IBM's mainframe dominance was built partly on proprietary hardware and operating systems that made switching ruinously expensive. If you ran on IBM, you stayed on IBM. Competitors had to offer near-total compatibility just to be considered.

Microsoft repeated the trick with Windows and Office through the 1990s. The file formats (before OOXML and widespread PDF) were proprietary enough that sharing documents with non-Microsoft users was genuinely awkward. The network effect and format dominance combined into something that kept enterprises locked in for decades.

The late 1990s and early 2000s saw a wave of enterprise software (SAP, Oracle, Siebel) that took lock-in to an art form. Implementations took years and cost millions. Once you were live, the system had become so embedded in your processes that leaving was effectively impossible. The joke was that the switching cost was roughly equal to the GDP of a small country.

Open-source movements from the 1990s onward were partly a direct response to this. The argument was simple: if you control the source code, no single vendor can hold you hostage. Linux, Apache, MySQL and later OpenOffice (forked in 2010 as LibreOffice) were all driven at least partly by a desire to escape proprietary dependency.

SaaS changed the terms but not the underlying dynamic. The upfront costs disappeared. The data gravity and integration complexity quietly replaced them. Now the era of AI APIs and agent platforms is adding another layer: not just your data but your workflows, prompts, fine-tuned models and agent logic may all live on infrastructure someone else controls.

Keeping leverage without becoming paranoid

The answer is not to avoid subscriptions or APIs. That would mean avoiding most of the best tools available. The answer is to be deliberate about where you accumulate dependency and where you stay light.

A useful mental model: separate your core from your periphery. Core is the data, logic, and processes that define how your business works. Periphery is the tooling that helps you do it faster. Be more careful about lock-in at the core. Be more relaxed about it at the periphery.

Your customer data is core. The email tool you send it through is periphery. Your proprietary process for delivering a service is core. The project management software you track it in is periphery. That distinction changes how you evaluate every new tool you adopt.

Practical things worth doing

You do not need to architect your entire stack around exit scenarios. But a few habits make a real difference.

Check the export story before you sign up. Seriously. Try the export function on day one, before your data matters. If it produces a garbled mess or locks key fields behind a higher tier, that tells you something important about how the vendor thinks about your relationship.

Keep your own copy of critical data. Automated exports on a schedule, stored somewhere you control, mean that even if a vendor disappears overnight (it happens) or triples their pricing (it happens more), you have something to work with.

Treat integrations as technical debt. Each connection between tools is a dependency you will have to unwind if either side changes. That does not mean avoiding integrations. It means being conscious of how many you are accumulating and which ones sit close to your core.

Document what you have built, not just how to use it. The automation you built in one tool can be rebuilt in another if you have a clear description of what it does and why. Without that documentation, the knowledge walks out the door with the tool.

The AI layer is worth paying attention to

Most of the above applies to software you have been using for years. But there is a newer version of this problem worth naming.

AI-powered tools are becoming deeply embedded in workflows faster than most organisations realise. Teams are building processes around specific LLM behaviours, storing prompt libraries in proprietary platforms, and training internal assistants on company knowledge within closed systems.

The model providers are aware of this. OpenAI, Anthropic, Google and others are all competing to become the platform your workflows depend on, not just a commodity API you could swap out next month. That is a rational strategy for them. It requires a bit of thought from you.

None of this means avoiding AI tools. It means asking the same questions you would ask of any other platform: where does my data live, can I get it out, and what would I do if the pricing changed dramatically tomorrow?

Planning an exit you will probably never need

The goal is not to have a fully tested migration plan for every tool in your stack. That would be an enormous and largely wasted effort. The goal is to avoid the situation where you find out the exit cost only when you desperately need to leave.

A rough rule of thumb: the more critical the tool and the more data it holds, the more worth spending an hour thinking through what moving away would actually involve. For most peripheral tools, the answer is "annoying but manageable." For a few core ones, the answer might surprise you, and that surprise is worth having now rather than under pressure.

The businesses that handle this well are not the ones who never get locked in. They are the ones who know where they are locked in, have made a conscious decision that it is worth it, and have at least a rough idea of what they would do if circumstances changed.

That is not paranoia. It is just good housekeeping.

How AI with Ash can support you

If you are building AI-powered workflows or agent systems, the tooling decisions you make now will shape how much flexibility you have in two years. Getting the architecture right from the start is a lot cheaper than unpicking it later.

If you want a clear-eyed look at where your current stack creates dependency and where you have more freedom than you think, book a call and we can work through it together.