And it’s the reason they don’t…
A few years ago, I was on a call with a CTO who was trying to leave his outsourcing partner. The work wasn’t terrible. It was fine. And that was exactly the problem. “Fine” had become the ceiling. Quality was acceptable but he was never impressed. Every time he challenged, the answer was some flavour of “we’ll look into it.”He wanted to move on. But he couldn’t. Not easily, anyway. Non-solicitation clauses meant he couldn’t hire the engineers who actually understood his codebase. The IP sat in a structure he didn’t fully control. The termination clause would leave him exposed for months. He was, for all practical purposes, stuck. And the supplier knew it.
That conversation stayed with me. And probably because it resonated. Almost every CTO I’ve spoken to who’s worked with an outsourcing partner for more than a few years has a version of this story. The details change. The emotion of frustration doesn’t.
What I eventually realised is that this isn’t a failure of individual suppliers. It’s a feature of how the industry is designed. Lock-in isn’t a bug. It’s the business model. Most outsourcing companies build their commercial structure around making it difficult for you to leave, and then they call it partnership.
The moments where lock-in actually hurts
The thing about supplier lock-in is that you don’t feel it when everything’s running smoothly. It surfaces at the exact moments when you need control the most, when the stakes are highest and your options should be widest.
Take a funding round. You’re in due diligence. Investors are pulling apart your engineering function. You explain that 30 engineers sit with an external supplier. The room gets uncomfortable. Someone asks what your contingency plan is if the relationship breaks down. And you don’t have a good answer, because the honest one is: we’d lose six months of momentum, a huge amount of institutional knowledge, and probably the people who know our systems best. That’s not the kind of thing that inspires confidence when someone is deciding whether to write a cheque.
Or you’re in a board meeting, doing the annual risk review. Supplier dependency gets flagged. You talk about SLAs and contracts, and everyone nods, but the people in that room know perfectly well that a contract is only as good as your ability to enforce it without cratering your delivery pipeline in the process.
Or, and this is the one that really frustrates me, you’ve reached a point where you want to bring your external team closer. You want them in your org structure, measured against your KPIs, properly integrated into your culture. But you can’t, because they’re not your people. They’re someone else’s employees. And if you want to change that, you’re staring at transfer fees, restrictive covenants, and a supplier who suddenly becomes a lot less friendly.
These aren’t edge cases. This is how the industry works.
What the SPV actually does
SPV stands for Special Purpose Vehicle. In our context, it’s a separate business entity with its own governance, its own team, and a shareholding structure that can be transferred to the client whenever they want. No penalties, no negotiation theatre, no six-month cooling-off period.
People always assume there’s a catch. There isn’t. The structure exists so that if we stop delivering value, or your strategy changes, or your investors decide they want everything in-house, you take the team. The people who know your code, your domain, your architecture. They come with you because the legal structure was designed to make that possible from day one.
We’ve been running amazing managed teams for over eight years with our longest client. They started with one lead and a small team. Today that team has over 40 engineers and people leaders, including members who hold Director-level positions within the client’s organisation. The client is valued at close to a billion euros.
They could take the whole thing tomorrow. They haven’t. And I think that’s the most important data point in this entire article. When someone genuinely can leave and they choose to stay, that tells you something real about whether the relationship is working.
It changes the board conversation entirely
This is something people don’t fully appreciate until they’re actually in the room having the conversation.
“We outsource to a company in Malta” is a risk line item. Boards hear “outsource” and they immediately think dependency, continuity risk, IP exposure. It doesn’t matter how good the team is. The word itself triggers a particular response.
Now compare that to: “We have a dedicated entity with full transfer rights, governed by a distinct shareholding structure, with team members holding directorial positions in our engineering function.” Same team. Same people. Same output. But the framing transforms how it’s received. That’s not a liability on a risk register. That’s a strategic asset with a built-in contingency.
For investor conversations, the gap is even wider. Due diligence on outsourcing arrangements almost always raises flags. Due diligence on an SPV structure reveals a well-governed, transferable capability that actually de-risks the investment thesis. I’ve watched this happen in real time with our PE-owned client. The reaction in the room is completely different.
What happens when your supplier changes direction
There’s a risk in outsourcing that doesn’t get nearly enough airtime: what happens when your supplier’s own business changes direction?
Agencies get acquired. Management teams turn over. Strategic priorities (think pricing models!) shift. The supplier who was deeply invested in your account last year might be restructuring this year, or chasing a different market, or cutting costs in places you can’t see until the impact hits your team. The people who understand your product, your architecture, your domain, are suddenly caught in someone else’s corporate transition. And with a traditional contract, your options are limited to escalation and negotiation, neither of which gives you actual structural recourse.
With the SPV, you don’t need anyone’s permission. The structure was built from the beginning to let you take ownership regardless of what’s happening on our side. Not as a goodwill gesture or a negotiated exception. As a design feature.
Designing for exit killed our ability to coast
This is the part where other agency founders look at me like I’ve lost the plot.
When your client can take their team and walk away at any point, you cannot coast. There’s no safety net of switching costs to paper over a mediocre quarter. There’s no termination window that buys you three months to “turn things around” while the client absorbs the pain of staying. If you stop delivering value, there is nothing structural keeping the client in the relationship. They can leave, and the people go with them.
That changes how you operate at every single level. Our teams are measured on the client’s KPIs, not our internal vanity metrics. Our engineers get bonuses for solving client problems, and the client doesn’t pay extra for that. Our people leaders sit in client standups, contribute to their planning sessions, operate as part of their structure. We do this because the model forces us to, not because someone put it on a slide about company culture.
Complacency, in our structure, isn’t just a quality issue. It’s an existential one.
And honestly, I think that’s how it should work. If you’re building someone’s product, managing their engineering capacity, holding their IP, you should have to earn that position every day. The fact that most of the outsourcing industry has structured itself specifically to avoid that kind of accountability is, to me, the core problem with the model.
Lock-in has its place. Just not here.
I don’t want to pretend that all lock-in is inherently bad. That’s a lazy argument.
If you build on AWS, you accept a degree of platform lock-in because the value genuinely outweighs the switching costs. If you standardise on Salesforce, you’re making a conscious trade-off between flexibility and capability. Those are tool-level decisions. You weigh them, you make the call, you move on.
But here’s where the analogy breaks down. Tools are replaceable. You can migrate off AWS. You can swap out a CRM. It’s painful, sure, but it’s doable because you’re moving between interchangeable systems.
People are not interchangeable. The engineer who understands your edge cases, who knows where the technical debt lives, who can explain to a new joiner why that particular API is structured the way it is, that person is not a fungible resource. And when your outsourcing contract is specifically designed to make it expensive or impossible to retain those individuals if the relationship ends, you’ve handed someone else leverage over the most critical part of your engineering capability.
That’s not a partnership. It’s a dependency. And for business-critical functions involving key individuals, that kind of structural dependency should never be something you accept.
The counterintuitive bit
Whenever I explain this model to other founders in the services space, the reaction is always the same. “Aren’t you worried about losing clients?”I get why they ask. The whole industry is built on retention through friction. Remove the friction and, logically, you’d expect clients to leave. But the data says the opposite.
We are proud that our clients don’t leave even when they have the freedom to.
Turns out that when people stay with you because they genuinely want to, not because leaving would be too disruptive, you end up building something much more durable. The relationship sits on performance and trust and actual alignment, rather than on contractual friction and inertia.
I know this sounds like the kind of thing someone would say on a panel. But we’ve been doing it for long enough now that the evidence speaks for itself. The client who can leave is the client who stays. And after all these years, the ones who can leave are all still here, eight years later.