Layer or rebuild: the advantage is not in being first

Adopting AI on old processes is optimising a question you should no longer have been asking.

Why do my AI tools produce more, without changing anything?

The first cars drove on dirt roads laid out for horses. They got stuck, burst their tyres, went hardly faster than a carriage, and plenty of people concluded the automobile was a fad.

AI is in that position today. It runs on systems and processes built over thirty years of successive layers: software that does not talk to other software, approval circuits designed for paper, meetings that exist to move information that now moves by itself. It delivers less than it could, not because it is weak, but because the infrastructure was not built for it. A business owner who judges AI on those results is judging the road, not the car.

That is what we call layering: plugging AI into a process you leave untouched. The assistant drafts the monthly report that nobody reads any more closely; it prepares the quote faster, and the quote still goes through the same four sign-offs; it summarises the coordination meeting, which still takes place. More volume, the same product, the same decision.

Bitcoin went through that stage. For years it ran on the banks' rails: you bought bitcoin by bank transfer, left it with an intermediary, and every use felt like a banking transaction, only slower. The results were disappointing. Then it built rails of its own, Lightning, the payment network built on Bitcoin, and uses that had been impossible appeared: a final payment in one second, down to a thousandth of a cent, between two machines, with no account. What had been layered on the old rails disappointed; what was built natively changed what could be done.

If the process has not changed, it is worth asking where it came from.

Why do we do things this way?

Every process answers a constraint from the past. The approval circuit exists because checking was expensive and had to be spread across several people. The monthly report exists because nobody could cross-reference the figures every day. The coordination meeting exists because there was no other way to pass what one team knew to the team next door. These are workarounds, and they were good ones.

AI removes several of those constraints at once: the cost of processing information, the impossibility of cross-referencing broad signals, the cost of passing knowledge between teams. Two simple truths follow. A constraint that disappears makes useless whatever was built to get around it. And optimising a workaround is always worth less than removing the constraint at its source.

That is why AI asks every process an awkward question: why do we do this this way? Often the honest answer is: because ten years ago we had no other choice. The reason has gone. The process has not.

Bitcoin teaches how hard that step is. To understand what it offers, you first have to unlearn things you took as facts: that money must be issued by a state, that falling prices are necessarily bad. An inherited process is a belief of the same kind: you no longer see it, you take it for reality.

Keeping the process still has a price, even when it works.

What does layering cost me?

Software engineers know about technical debt: every shortcut taken to ship faster adds complexity that will have to be paid for later. It stays invisible while the software runs, then gets paid with interest the day the software has to change.

Layering creates the same thing inside the organisation. Call it organisational debt: every process that has been accelerated but not rethought adds a layer of inherited complexity that will one day have to be taken apart. The quote moves faster, but it still goes through four sign-offs, which the tool has now learned and depends on. The day the company truly wants to change how it decides, it will have to undo the old process and the automation it put on top.

That debt has a second side. Everything your teams teach their tools, the rules, the corrections, the reasons behind choices, ends up in those tools, not in the company. It is the crumbling described in our article on intangible capital: every layer is also a piece of knowledge deposited with a third party.

Some nuance is needed. Not all layering is a mistake. A company has customers, legal obligations, real working cycles; a sudden overhaul of everything that runs would cost more than anyone could bear. Layering is often the right choice for most processes. The debt is not in having layered. It is in not knowing where.

So you do not rebuild everything.

Should we rebuild everything?

No. The successful transformations people usually cite did not rebuild everything: they found the point of leverage, rebuilt it, and layered the rest. Total overhaul is a story; targeted overhaul is what actually gets done.

The real question is not “layer or rebuild?” but: which layer carries the strategic break, and which can stay layered without excessive future cost?

The answer, for a business owner, comes in three steps. Start from long-term goals, not from the tools on offer: where do you want to be, and what stands in the way? Then look for the layer where the company's own context makes the difference: how you know your customers, how you set a price, how you decide what you will not do. Rebuild that one, asking what it would look like if you designed it today, with AI, without the legacy. The rest can wait.

That layer is almost always where your intangible capital lives: what the company knows about its customers, its craft, its decisions and the reasons behind them. Rebuilding around AI therefore starts with writing down what the AI needs to read. An AI that knows only what it has picked up from your tools can only speed up your habits; an AI that reads what you know can serve a different way of deciding.

And to know where you stand, forget the number of tools deployed. Maturity is measured by the ratio of processes rethought to processes merely accelerated. A company with three tools and one process truly rebuilt is further ahead than one with twenty tools placed on top of what already existed.

If rebuilding is what counts, does being first still matter?

Does it matter that we were not first?

There are two competitions, and they do not last as long.

Early adoption gives a real but temporary advantage: a few months of learning, then the tool becomes ordinary and the edge disappears. That gap closes in months.

Reorganising around the tool gives a structural advantage: ways of working and deciding that a competitor cannot copy in a few quarters, because they rest on what the company knows and on new habits, not on a subscription. It takes time: our estimate is that an organisation needs more than a year to truly change how it works. That gap, once it opens, is paid for in years.

The first movers clear the ground and pay for the exploration: the trials, the mistakes, the abandoned tools. Those who come next can jump straight to reorganising, using what others have learned. Google was not the first search engine, Apple did not make the first smartphone, Netflix did not launch the first online video service. Each arrived after others, and redrew the field.

Two limits, honestly stated. In markets where the advantage comes from accumulated data, where each new customer makes the service better, being first matters more: the useful question is which kind of market you are in. And “waiting to do it properly” can be nothing more than a rationalisation of being late. The line between deliberate strategy and procrastination is hard to draw from the inside, and nobody inside the company really has an interest in drawing it.

What remains is to know what to rebuild on, and where we are in the story.

Where are we, and on what infrastructure should we rebuild?

Great transitions follow a sequence, described for electricity, the telephone, the internet, and for Bitcoin itself. First, the new technology crawls along the old infrastructure, and disappoints. Then an infrastructure of its own is built. Then comes the inversion: the old world starts running on the new infrastructure, and uses appear that nobody could have imagined before. Finally, the old becomes a deliberate choice. The telephone is the example: calls now travel over the internet, so clean that a faint background hiss is added so they sound like the calls of old.

Your processes will follow the same path. The monthly report will not necessarily disappear: it will become an option you choose, not a constraint you endure. So will the meeting.

We are at the first stage. And it is at the first stage that architecture decisions open or close: whatever gets put in place by default today will still be there in ten years. Bitcoin shows this in its own way. It drastically cuts some costs, the cost of trusting a third party and the cost of verifying scarcity, and not others; hence complementary layers, Lightning among them, built on top. You rebuild only the layer where the new infrastructure changes the game, and you build on it.

But AI's infrastructure belongs to a handful of providers. Rebuilding around it also means choosing your dependency. A company does not build that infrastructure; it chooses which one to lean on, and that is a different decision. Hence the one to make now: decide what, in the rebuild, stays yours. The corpus, meaning what the company knows, written down in files readable by a person and by any model, kept in-house. That is what keeps the ability to move from one model to another, from one provider to another, without redoing everything.

The layer to rebuild is the one you own; the others, you rent.

The advantage is how you come out of the turn

The advantage is not having had AI before the others. It is having changed what you produce and how you decide, because you have it. That is not decided by starting from the next tool, but from the way out of the turn: your long-term goals, and the layer that gets you there.

If your teams have already put AI to work, the VIRAGE workshop (French for “the turn”) checks what serves your goals, what scatters them, and what is missing; it separates what must be rebuilt from what can stay layered. For the layer to write down, intangible capital sets out what it contains and how to keep it in-house. And if you are wondering who is best placed to rebuild, large groups or smaller companies, read why the SME lag is a window.