Chapter Seventeen · Lessons · 3 min
App Confetti
AI has created a new organisational risk that I did not really have a name for until I started living through it.
AI has created a new organisational risk that I did not really have a name for until I started living through it. I call it app confetti, because once you notice it you start seeing the little digital bits absolutely everywhere.
One small tool for auditing card-payment terminals, another larger tool for feedback. Another for training. Another for forecasting. Another to launch all the other internal tools. Each one defensible. Collectively, potentially ridiculous.
The old world created complexity through giant platforms. The new world can create exactly the same complexity through a thousand inexpensive subscriptions and prototypes. Congratulations, we have democratised technical debt.
This is why pattern matters more than platform. If the same data, workflow or decision keeps appearing across different requests, stop treating every request as a fresh application. Ask whether there is a shared capability underneath them.
But be careful. The answer is not automatically to combine everything into one enormous super-platform. That is how we recreate the thing we were trying to escape, only with nicer typography.
The discipline is to consolidate understanding before consolidating software. Reuse the pattern. Reuse the data. Reuse the lessons. Let the architecture follow evidence rather than ambition.
The moment you build a platform because you fancy owning a platform, you have stopped finding friction and started inventing requirements for yourself.
The launcher joke matters because it contains a genuine warning. When the cost of creating an application was high, architecture was partly enforced by scarcity. You could not casually build twelve systems because twelve systems needed twelve business cases, twelve projects and a queue of developers who already had more work than they could finish. That constraint was frustrating, but it also stopped some nonsense.
Now the constraint is disappearing. A useful internal tool can be created before the meeting that requested it would previously have found a diary slot. That is liberating, but it means the old filter has gone. If we do not replace it with judgement, we can produce fragmentation at extraordinary speed.
I can imagine the ridiculous end state because I am perfectly capable of contributing to it. One login for feedback. One for training. One for forecasting. One for audits. A helpful little launcher to find them all. Then perhaps a database to explain what the launcher contains. At some point somebody quite reasonably asks why we did not buy a platform in the first place, and the only available answer is that we were enjoying the liberation too much.
The answer is not centralisation for its own sake. I have seen giant platforms become museums of features nobody uses. The better discipline is to look underneath the applications. Are several tools relying on the same people data, the same location list, the same permissions or the same operational signal? If so, make those foundations reusable before you make the front ends identical.
That is why I keep coming back to patterns. A platform is a technical shape. A pattern is an understanding of repeated work. If the pattern is real, the right technical shape usually becomes clearer with use. If you choose the platform first, you have a remarkable ability to start discovering requirements that justify the platform you already wanted. Human beings are talented like that.
There probably needs to be a periodic moment where somebody looks across the whole collection and asks whether the little things still make sense together. Not a giant architecture board with ceremonial paperwork for every experiment, but a grown-up look at duplication, ownership and shared foundations. We should be able to tidy our own bedroom.
If that review tells you two tools should merge, merge them. If it tells you one should disappear, let it disappear. If three of them are revealing the need for a proper platform, that may be the evidence that finally earns the platform. The principle stays the same. Architecture should be a response to what has proved useful, not a monument to what we guessed we might need.