The stack you can walk away from.

Owning your stack does not mean building everything yourself. The teams who think it does usually end up with the opposite problem. It means never being in a position where someone else's decision becomes your emergency, which is a narrower claim than the marketing makes and a far more useful one. Almost everyone runs on other people's platforms; we are no exception. The real question is which parts you can afford to hand over and on what terms.

01What renting costs and when to do it.

There is a good reason we reach for managed services and off-the-shelf products: they are fast. You get a working capability in days rather than quarters, with someone else carrying the operational weight. The convenience is genuine. For most of what an organisation runs, renting is the right call, which is why I reach for it constantly.

What is worth noticing is that the bill for a rented dependency rarely arrives as a line item. It shows up later: as the egress fee that makes moving your data uneconomic, the single-region outage you cannot route around, the pricing change you have no leverage to refuse or the legal ruling that turns where your data sits into a problem overnight. The Schrems II judgment did exactly that to a great many transatlantic setups.¹ None of this is the vendor failing you. It is the cost of a dependency you did not price when you took it on. Price it honestly and renting stops being a gamble; it becomes a clear-eyed choice.

02Why the whole continent is suddenly asking this.

This used to be a niche worry for regulated industries. It is now one of the loudest conversations in European technology. The overwhelming majority of Europe's cloud runs on a handful of American providers, something the past two years have made a lot of people notice. When a foreign legal regime can reach your data or a single pricing decision can reshape your budget, dependence stops feeling like convenience and starts feeling like exposure.

Brussels has responded on every front at once: a Cloud Sovereignty Framework that scores providers from no sovereignty up to a full European supply chain, a sovereign-cloud procurement programme for the EU institutions themselves, a proposed Cloud and AI Development Act and the decade-long EuroStack ambition behind all of it.³ Some of that will work and some of it is politics; the long fight over the EUCS certification scheme shows how unsettled the definitions still are. The direction, though, is unmistakable.

Here is the part I find genuinely useful underneath the geopolitics. The regulation that has actually landed does not tell you to go sovereign. It tells you to be able to leave. Since September 2025 the EU Data Act has required cloud providers to remove the obstacles to switching, from egress fees to contractual lock-in.⁴ DORA already asks financial entities to prove an exit plan. Read together, the law is converging on the same instinct a good operator already had. The goal was never autarky. It is optionality you can prove.

We work across the whole of that line, from a hosted API to a fully sovereign on-premise deployment. I am not a sovereignty maximalist. Most of what we run sits on hyperscaler cloud, exactly where it belongs. The skill is not picking a side in the cloud-versus-sovereign argument. It is placing each workload at the right point on that spectrum, on purpose, with a way back if the ground shifts.

03Sovereignty is just optionality you can prove.

When I strip the word sovereignty back to something I can act on, it comes down to optionality across three layers. You do not have to own all three by building them. You have to be able to decide about each one and act on that decision. A workload I rent but could redeploy elsewhere in a week is more sovereign than one I built but cannot move. The test was never who wrote it; it is whether you can leave.

Three regulations have quietly turned this from good practice into obligation. GDPR governs data residency and lawful processing. DORA, in force since January 2025, formalises operational resilience and third-party dependency for financial entities.² The EU AI Act extends accountability across the AI lifecycle. None of them ask whether you built it. They ask whether you know where it lives and how you would leave.

You own your stack the day you could walk away from any part of it and choose not to.

04Own what is core, rent the rest.

The opposite mistake is just as real and I see it more often than under-owning: rebuilding commodity infrastructure you could rent for a fraction of the cost, then calling the overhead independence. That is vanity dressed as strategy. The real discipline is knowing which is which.

Own the systems that are core to how you operate, that set you apart or that a regulator will ask you to account for. Those are the ones where a dependency you cannot control becomes a risk you cannot manage. Rent the rest freely, but rent it with an exit you have actually used: a data export you have run, portability you have tested, a way out that is more than a clause in a contract.

This is not abstract for us. We have built sovereign, on-premise systems where the data never leaves the client's perimeter. We have moved multi-system workloads between environments because the architecture was designed from the start to let us. The day a vendor changed its terms, it was a line on a planning agenda rather than a crisis. That, in the end, is the whole payoff: not a fortress, but the quiet confidence that you could move if you had to.

I should be straight about one thing: we are a vendor ourselves. We build a platform of our own and we hold it to exactly the test in this piece. The modules we build for a client belong to that client and the data is always theirs, so they can take both and walk away. None of this is anti-vendor; good vendors are how most things get built. It is anti lock-in. A platform worth trusting, ours included, makes the exit easy rather than expensive.

05Knowing you could walk away.

If there is one habit worth taking from all of this, it is to find out, for the handful of systems you could not afford to lose, whether you could genuinely move them, then to prove it rather than assume it. Most teams have never run the export they are quietly counting on. That gap is usually where the real exposure sits. Closing it is more satisfying than any amount of rebuilding.

The fastest path over the next five years is the one that closes the fewest doors. Owning your stack, where it actually matters, is simply how you keep them open.