In 2025, 52.74% of European companies with ten or more employees paid for cloud computing services, according to Eurostat. Only 13.76% bought cloud as a platform to develop, test or deploy their own applications, and 14.86% used it to run their own business software. Renting infrastructure is now normal. Building on top of it is not.

That gap — from half the business base down to one in seven — tells me more than either figure on its own. Infrastructure stopped being an advantage years ago: you buy it with a card and it arrives in minutes. The scarce part is the layer above it.

What gets shared and what stays inside each company

That layer is what we call Core Technology: capabilities built once and usable by the different companies in the group, which work in telecoms, digital marketing, real estate and artificial intelligence. The operational question is not what can be shared. It is what deserves to be.

  • Identity and permissions, yes. How a person proves who they are and what they are allowed to do is the same problem in a telecoms operator and in a property portal. The data changes; the mechanism does not. Solving it twice means paying twice for the same answer.
  • Traceability, also yes. Knowing who did what and when is an obligation before it is a feature, and it is among the first things a young team sacrifices when it is in a hurry. Once it is built, it stops being a decision somebody can get wrong on a Tuesday afternoon.
  • Business logic, no. How an asset is valued, how a tariff is calculated, what you offer a customer who has been with you three years: that is the knowledge each company exists for. Moving it into a shared core does not improve it, it only makes it slower to change.

The rule we apply before moving anything into the core

No component enters the core because it looks reusable. It enters when a second company asks for it. Until then it lives inside the product where it was born, with its shortcuts and its dirty decisions, and that is fine: most things that look generic on day one turn out to be specific by day three.

The second half of the rule is less pleasant. Whoever pushes something into the core stays accountable for maintaining it for everyone else. There is no neutral team that inherits the work and no budget that shows up on its own. If nobody is willing to pay that price, the conclusion is not that we are short of people: it is that the component was never as shareable as it looked.

The price of sharing

A shared core concentrates risk. A failure in an isolated component affects one product; a failure in the core affects everything depending on it at once, and usually on a Friday. That is why the bar for getting in has to be higher than the bar for staying out: shared code gets tested more, documented more and changed with more ceremony. Anyone who wants speed without that toll is better off outside.

There is a worse risk than an outage, because you do not see it coming: the shared layer ages. When a decision made four years ago is still standing only because half a dozen products assume it, it has stopped being an asset. Switching off costs more than switching on, and in a shared core it costs as many times more as there are companies using it.

Why this cannot be bought

A competitor can sign up tomorrow for the same providers, the same models and the same cloud. What they cannot sign up for is the list of things we already know do not work, which is the expensive part of the learning and the only part that appears on no invoice.

A group’s advantage is not having several companies. It is that the next one starts with less work ahead of it than the first.