There's a pattern playing out across energy, manufacturing and geopolitics.
For years, we optimised for efficiency. Centralise everything. Outsource complexity. Hand responsibility to specialists who promised scale, speed and simplicity. It worked, until it didn't.
In physical supply chains, the risks are now obvious.
Supply chain fragility has resulted in some pretty dramatic headlines in recent years: the Suez Canal blockage, global semiconductor shortages, Ukraine war and grain / fertiliser supply, and JLR supplier cyber attacks, to name a few. The list is getting longer in 2026... silver shortages and export bans from China. Not to mention the impact of global trade wars and tariff tantrums that make disruption business as usual.
Digital infrastructure is going through the same reckoning to de-risk supply chains where possible. When something breaks, you discover very quickly how little control you actually have - often being locked into service contracts and SLAs where you're never the priority (particularly on SaaS platforms).
Most organisations can list their physical suppliers without much effort. Few can do the same for their digital ones.
Your digital supply chain is everything your organisation depends on to operate online. Not just the obvious infrastructure, but the services woven into day-to-day operations. Hosting, content management, analytics, identity, payments, marketing tools, search, AI services. The list is usually longer than expected.
Over time, these dependencies accumulate quietly. A commercial plugin here, a SaaS contract there, a "temporary" integration that becomes permanent. Individually they seem harmless. Collectively, they shape who really controls your online business.
The risk is not that these services exist. It is that many organisations no longer have a clear view of which ones are critical, which ones are interchangeable, and which ones would be painful or impossible to replace.
When something changes upstream - a price increase, an outage, a policy shift, or a breach you discover how tightly coupled your operations have become.
However, don't rush to pull everything back in-house. It's about knowing where the points of dependency are, and designing platforms so no single decision made elsewhere can put the business on pause.
Leadership teams we speak to are not anti-cloud. Quite the opposite. Cloud is here to stay, and few would argue for a return to racks of servers humming away in a cupboard (although with the advent of AI, the business case for running local AI models on sensitive business data is having a renaissance, but that's a topic for another day!)
There is growing discomfort with how much critical knowledge, process and IP has quietly drifted out of the organisation's direct control. CRMs, product management, ERP systems and the like are typically cloud based these days. What's the impact to your business when these systems have outages, technical issues, data loss or leaks? The responsibility of these risks has been outsourced, but they haven't been eliminated altogether. Even 'low probability events' have a tendency to occur more frequently than we'd like. And the impacts have very real financial and reputation impacts for your business.
It's rarely one dramatic failure that triggers this thinking (although it can be). More often it's death by a thousand paper cuts. Rising platform costs that feel hard to challenge especially when they're deeply embedded. SaaS platforms that change without much notice can leave you chasing your tail when things break. Data that technically belongs to you but lives inside someone else's operations. Add AI tooling layered on top of these systems that you no longer fully understand, then data leaks of all kinds are possible and, to be honest, are increasingly more likely as time goes on.
At some point, wise leaders start asking a different set of questions. Not "how do we move everything back", but "how exposed are we really?" And "what would it take to change direction if we had to?" Good risk management questions.
This is where the idea of digital sovereignty is re-entering the conversation. Not in a political sense, but a practical one. Who ultimately owns the system? Who can run it? Who decides how it evolves? Does it really fit our business needs? Is it future fit for what we will need?
Open source software plays a quiet but important role here. Platforms like Drupal aren't interesting because they're trendy. They're interesting because they're open and afford the highest level of sovereignty possible. The code is inspectable and the data models you build are yours. The skills to run it are not locked inside a single vendor. That changes the balance of power in a very real way.
The same applies to digital infrastructure choices. We're seeing renewed interest in platform-as-a-service models that deliberately avoid tying clients to one hyperscaler (AWS/Azure/GCP). Using a multicloud PaaS like Upsun makes switching underlying cloud infrastructure very easy. It means designing in the option to move, rebalance, or respond when the landscape changes. Optionality becomes part of the architecture, rather than an afterthought.
There's a reason so many organisations moved quickly towards SaaS platforms and managed cloud services. They're fast to adopt, predictable on day one, and reduce the immediate burden on internal teams. When time is tight, budgets are constrained, or the problem isn't strategically important, buying something ready-made can be the sensible choice.
Building sovereign, open-source systems flips that equation. You gain flexibility, control and the ability to shape the platform around how the business actually works. But you also bring responsibility back inside the organisation. Product decisions, technical direction, prioritisation and long-term maintenance all become things you need to own, either directly or through trusted partners.
That trade-off is not good or bad in isolation. It depends on context. Budget, urgency, regulatory exposure, and how critical the system is to competitive advantage all matter. So does internal capability. Custom platforms work best when there's clarity about who steers them, how decisions get made, and how development teams are supported over time.
Working with external development partners (such as Pivale) can remove much of that burden, but only if those partners are around for the long haul. Teams that understand the business, aren't spread thin across dozens of short-term projects, and value continuity over churn. Equally, hiring internal development teams can be the right move, but it comes with real cost, management overhead, and the ongoing challenge of retaining skills in a competitive market.
There's no single right answer. Many organisations end up with a hybrid approach: SaaS where it makes sense, and bespoke systems where differentiation, scale or control really matter.
Where growth and competitive advantage are central to the strategy, investing in systems built specifically for the business is often a wise decision. Done well, they streamline operations, adapt as the organisation changes, and become an asset rather than a constraint. Done poorly, they can create just as much risk as over-centralisation elsewhere.
The hard part isn't choosing between buy or build. Rather, it's being honest about which parts of the business are worth owning deeply, and making sure the people building them will still be there when the initial excitement has worn off.
What's important is that this doesn't need to be a big bang "return home" moment. That framing misses the point. The goal isn't nostalgia for internal IT teams manually patching servers. The goal is clarity, clear ownership, and navigable exit routes so you end up with a clear understanding of what is genuinely strategic and what can safely be commoditised or outsourced.
At Pivale, this is where most of our work now sits. We help organisations rebuild confidence in their websites and digital platforms. That usually starts with replacing fragile, over-engineered setups with open-source systems that the client fully owns and understands.
We build web platforms to last, not to be re-built every few years. Content, integrations and workflows are structured so teams stay in control as the organisation changes.
Ultimately, it's about putting solid digital foundations back under the business.
In a world that is slowly waking up to the risks of over-centralisation, this kind of thinking is becoming less niche and more about awareness and responsibility. Leaders aren't trying to predict the next crisis. They're accepting that change is constant, but also that too much third party dependency is a risk in itself. It's a balancing act that needs careful consideration and continual review.
The organisations that will fare best are not the ones chasing the newest platform. They're the ones quietly rebuilding agency into their digital foundations.
If that sounds like a conversation worth having, it usually is.
