There’s a particular kind of dread that sets in when a business realises it’s stuck with a vendor it’s outgrown, but can’t leave. The pricing has crept up, the roadmap has stalled, or a better option has come along — but switching would mean rebuilding integrations, migrating years of data, and retraining a team, so you stay put and quietly resent it. That’s vendor lock-in, and almost every business ends up with some version of it somewhere in its stack.

The instinctive response is to try to avoid commitment altogether — stay flexible, keep options open, never fully commit to any one platform. In practice, that instinct usually backfires. Total flexibility is slow and expensive to maintain, and most businesses need to make a decision and get on with things. The real goal isn’t avoiding lock-in entirely. It’s understanding where you’re accepting it, why, and making sure you can still move if you genuinely need to.

Why some lock-in is unavoidable, and that’s fine

Every meaningful vendor relationship creates some degree of dependency. Your data lives in their system. Your team learns their interface. Your other tools integrate with their API. That’s not a design flaw — it’s simply what it means to actually use a platform properly rather than hedge against it forever.

Trying to eliminate lock-in entirely is its own trap. Building everything to be maximally portable, avoiding any vendor-specific feature, keeping every option permanently open — that adds real cost and complexity today, in exchange for flexibility you might never need. Most businesses that go down this path move slower, spend more, and still end up locked in somewhere, just less deliberately.

The useful question isn’t “how do we avoid lock-in?” It’s “where are we choosing to accept it, and is that a good trade?”

Where lock-in quietly becomes a problem

Lock-in becomes genuinely risky, rather than just a normal part of doing business, in a few specific situations:

• When it’s in a system you didn’t choose deliberately. 
  • A tool adopted quickly under pressure, without anyone weighing the long-term commitment, can lock you in by accident rather than by decision.
• When your data isn’t portable. 
  • If you can’t get a clean export of your own data in a usable format, you’re not just dependent on a vendor — you’re at their mercy for something that’s fundamentally yours.
• When the switching cost keeps growing invisibly. 
  • Every new integration, every custom workflow built on top of a platform, raises the cost of leaving — often without anyone tracking that the cost has grown.
• When it sits in a system that’s actually core to your business. 
  • Lock-in in a supporting tool is an inconvenience. Lock-in in the system your entire operation depends on is a real strategic risk.
• When there’s no realistic alternative left in the market. 
  • If a vendor knows you have nowhere else to go, pricing and service levels tend to reflect that over time.

How to stay flexible without slowing down

Staying genuinely flexible doesn’t mean hedging on every decision. It means being deliberate about a few things up front, so you retain real options later without paying for them constantly in the meantime:

• Know what “leaving” would actually involve, before you need to. 
  • Understanding the real cost and effort of switching — even for a tool you have no current plans to leave — means you’re never caught out, and you have a clearer sense of your actual negotiating position.
• Prioritise data portability, always. 
  • Regardless of how locked in you are functionally, make sure your own data can be extracted in a usable form. This is one of the cheapest forms of insurance available, and one of the most commonly skipped.
• Separate “core” from “replaceable” early. 
  • Decide deliberately which systems are genuinely load-bearing for the business, and which are more interchangeable. Core systems deserve more scrutiny and more deliberate commitment; replaceable ones don’t need the same level of caution.
• Watch integration depth, not just vendor choice. 
  • The real lock-in often isn’t the platform itself — it’s the dozen custom workflows and integrations built on top of it over time. Being aware of how deep those go is more useful than worrying about the vendor relationship in isolation.
• Negotiate from strength, not from panic. 
  • Vendors price and behave differently toward customers who could plausibly leave than toward customers who obviously can’t. Maintaining a credible alternative — even if you never use it — changes the relationship.

Flexibility is a decision, not a default

The businesses that handle vendor relationships well aren’t the ones who avoided commitment. They’re the ones who committed deliberately, understood the trade-off they were making, and kept a clear enough picture of their own architecture to know exactly what switching would cost if they ever needed to.

That’s not a reason to slow down on vendor decisions — it’s the opposite. Knowing where you stand means you can commit to the right tool confidently, rather than hedging indefinitely out of a vague fear of getting stuck.

---

Ashdown Systems helps UK startups and SMBs make vendor decisions with a clear-eyed view of the trade-offs — committing where it makes sense, and staying genuinely flexible where it matters. If any of this sounds familiar, get in touch.

A Solutions Architecture Approach to Cost Optimisation

If your AWS or Azure bill has started arriving with a slight sense of dread, you’re not alone. It’s one of the most common conversations we have with growing tech-focused businesses: the cloud spend crept up gradually, nobody quite knows why, and the instinct is to assume you just need to “use less cloud” — which usually isn’t the actual answer.

Cloud cost problems are rarely about usage being too high. They’re almost always about architecture that was never designed with cost in mind — because early on, it didn’t need to be. The good news is that this is one of the more fixable problems a scaling business will face, provided you’re solving the right problem.

Why cloud costs spiral

Cloud pricing is built to reward planning and punish improvisation. That’s not a criticism of AWS, Azure, or GCP — it’s just the nature of pay-as-you-go infrastructure. A few patterns show up again and again in growing businesses:

• Over-provisioning “just in case.” 
  • Resources sized for a traffic spike that happens twice a year, running at that size the other 363 days.
• Orphaned resources. 
  • Test environments, old databases, and unused storage volumes that were spun up for a project that finished months ago and never got switched off.
• No visibility into what’s actually driving spend. 
  • Without proper tagging and cost allocation, nobody can say which feature, team, or customer is responsible for which part of the bill — so nobody can prioritise fixing it.
• Architecture that made sense at a smaller scale. 
  • A design decision that was cheap and simple at low volume can become the single biggest line item on the bill once usage grows 10x, without anyone noticing the shift happened.
• Default settings left untouched. 
  • Many services default to convenient, not cost-efficient. Nobody revisits those defaults once the system is live and working.

None of these are exotic problems. They’re the predictable result of infrastructure decisions made under time pressure, by a team focused — rightly, at the time — on shipping rather than on the invoice.

Why “just cut costs” isn’t the right frame

The instinctive response to a high cloud bill is to go looking for things to switch off. That can help at the margins, but it treats the symptom, not the cause — and it risks cutting something that turns out to matter, or missing the structural issue that will just regenerate the same costs in six months.

A Solutions Architecture approach starts from a different question:

Not “what can we cut?” but “does the architecture match how the system is actually being used?”

That reframing usually surfaces bigger, more durable savings than a line-by-line audit of what to switch off.

Where the real savings usually are

In our experience, the biggest wins tend to fall into a small number of categories:

• Right-sizing, properly done. 
  • Not just picking a smaller instance, but matching compute and storage tiers to real, observed usage patterns rather than the original guess made at launch.
• Committing to savings plans or reserved capacity — but only once usage is stable. 
  • These can offer meaningful discounts, but committing too early, before your architecture has settled, can lock in inefficiency rather than remove it.
• Re-architecting for elasticity. 
  • Systems that scale down as well as up — rather than running at peak capacity permanently — can be one of the largest single savings available, particularly for workloads with predictable quiet periods.
• Storage lifecycle management. 
  • Data that’s accessed constantly and data that’s accessed once a year shouldn’t be sitting in the same (expensive) storage tier. This is often one of the simplest fixes with an outsized impact.
• Visibility and ownership. 
  • Proper tagging and cost allocation so that spend is attributed to the team, product, or feature responsible. You can’t optimise what you can’t see, and you can’t hold anyone accountable for a bill nobody can attribute.

Cost optimisation as an ongoing discipline, not a one-off clean-up

The other trap is treating cost optimisation as a single project: do a big review, fix what’s obviously wasteful, move on. That works once. Then the same drift starts again, because the underlying architecture and habits that created the problem the first time are usually still there.

The more durable fix is building cost awareness into how architecture decisions get made going forward — so that “what will this cost at scale?” is part of the design conversation from the start, not a question asked eighteen months later when the bill has become impossible to ignore.

The commercial case for getting this right

For a tech-focused SMB, infrastructure cost isn’t a back-office line item — it’s a direct input into your margins, your runway, and how much room you have to reinvest in the product. A well-architected system doesn’t just perform better; it’s usually the cheaper one too, because most cost inefficiency and most technical fragility come from the same root cause: architecture that wasn’t given the chance to be deliberate.

Getting a proper architectural view of your cloud spend, before deciding what to cut, tends to save more money and cause far less disruption than starting with the axe.

---

Ashdown Systems helps UK tech-focused startups and SMBs get their cloud architecture — and their cloud bills — under control. If any of this sounds familiar, get in touch.