Build vs buy: redistribution of responsibility

The deepest argument of this site lies in a phrase: redistribution of responsibility. It is the lens that resolves the apparent paradox of why Europe has competitive cloud infrastructure (4.8× better price-performance in some benchmarks) yet only 15 % of its home cloud market.

Hyperscalers sell integration; European providers sell infrastructure

Hyperscalers bundle integration and operation of hundreds of services into a single commercial contract. The customer pays a premium and receives a finished product. AWS, Azure, and Google Cloud do not just provide compute and storage — they provide managed databases, observability, identity, AI/ML platforms, serverless orchestration, security tooling, and the integration glue between all of them. The customer's job is to write their application; the cloud handles the operational substrate.

European providers — OVHcloud, Scaleway, STACKIT, Hetzner — sell infrastructure. Compute, storage, networking, basic managed services, and a thinner integration layer above. The integration glue is the customer's responsibility, supplied by the customer's own engineers or by a system integrator hired for that purpose.

This is not a quality difference. It is a different economic distribution.

Why this plays to Europe's structural advantage

Europe has one uncontested advantage that this site has discussed but not yet operationalised: higher technical-talent density per capita than the U.S. or China. ETH Zurich, EPFL, TU Delft, KU Leuven, the French grandes écoles, German Technische Universitäten — these institutions produce engineering talent at a scale that is globally rare, and Europe's overall tech workforce grew to 4.6 million in 2025.

That talent is, in the current cloud-buying pattern, partly underemployed. It works on projects, but the deep operational expertise — building and running production systems, integrating distributed databases, operating Kubernetes at scale, designing observability — is consumed via the hyperscaler's product, not built in-house.

Migrating to a European provider redistributes the value of that talent. Instead of paying a premium for the hyperscaler's operational team to run the substrate, the organisation pays its own engineers to build and operate it. The cost structure shifts from "vendor margin" to "internal salary"; the strategic position shifts from "consumer of integrated product" to "operator of own platform."

Concrete: a typical mid-size European organisation moving non-trivial workloads from a hyperscaler to OVHcloud or Scaleway will need to add 2–4 full-time DevOps/SRE engineers in the first 18 months. At European salary levels (€70–110k loaded cost per engineer), that is €140–440k per year. Against a typical hyperscaler bill in the same range or higher, the math often works — and the additional engineers produce in-house know-how shared with the organisation rather than with the vendor.

The build-vs-buy spectrum is not binary

The framing above is intentionally schematic. In practice, the choice is a spectrum, not a binary. Most organisations end up somewhere in the middle:

• Pure-buy: entirely on hyperscaler, deep use of proprietary services (Lambda, SageMaker, Power Platform). Lowest upfront effort, highest exit cost, deepest vendor lock.
• Pure-build: on bare-metal or basic VM infrastructure, building everything in-house. Highest upfront effort, lowest vendor lock, requires significant team capability.
• Hybrid pragmatic: the realistic mode for most organisations in 2026. Workloads where the European catalogue is sufficient (VM, object storage, managed Kubernetes, managed PostgreSQL, basic observability) move to European providers; workloads dependent on deep proprietary services remain at hyperscalers, with contractual exit clauses that satisfy the DORA exit-strategy requirements.

The hybrid pragmatic mode is what the 24-month roadmap operationalises — not as a preference, but as the most realistic path for an organisation that wants to build leverage without disrupting current operations.

When pure-buy is the right answer

It is worth being honest: not every organisation should redistribute responsibility. Pure-buy on a hyperscaler is the right answer for organisations that:

• have small or non-existent internal IT operations capacity
• operate in regulatory environments where the hyperscaler's certifications matter more than the architecture
• have business models where vendor lock-in is acceptable because the workload is not strategic
• cannot, for hiring or location reasons, sustain a 2–4 person DevOps/SRE team

Acknowledging when pure-buy is rational is part of the discipline. The redistribution model is not a moral imperative; it is an option that makes sense for organisations with the talent, scale, and time horizon to operate it.

What this implies for procurement

Three procurement implications follow:

1. Contract terms matter as much as catalogue choice. Whatever sits where, the contractual checklist (next chapter) is what creates leverage and exit options.
2. Total cost of ownership is the right comparison metric, not list price. A €10k/month hyperscaler bill is not directly comparable to a €5k/month European bill plus €25k/month in additional engineers. But once that calculation is correctly done, the redistribution is often financially competitive — and produces capability that the pure-buy mode does not.
3. Build the team before migrating, not during. The most common failure mode is underestimating the operational investment, migrating, then panicking at the operational complexity. The 24-month roadmap addresses this through sequenced steps where capability building precedes architectural change.