A good hundred and fifty years ago, a suit was something someone built for you. The tailor took your measurements, noted shoulder width and arm length, and what came out of it fitted exactly one person on earth. Then came ready-to-wear. Size 50, size 52, sewn identically a thousand times over, and suddenly almost anyone could afford one.
Notice what that sentence does not say. Ready-to-wear did not fit better. It was cheaper. We learned to get used to size 52, to have the sleeve shortened and to leave it there, because the alternative was unaffordable.
That is precisely the story of enterprise software over the past thirty years. And it is being rewritten right now.
What we actually bought
The make-or-buy question always sounded like competence: can we do this better than the vendor? In truth it was a question of price. Your own application cost developers, months and an operating risk. A standard solution cost licences, a rollout and a bit of customising. Anyone who could do arithmetic bought.
The price of that calculation simply never appeared on the invoice. It read: you adapt to the software. Processes were rebuilt so they would fit a field schema someone else had designed for a different industry. We called that standardisation and consoled ourselves that it was “best practice”.
Best practice is by definition what everyone does. And what everyone does differentiates nobody.
I say that without resentment, because the decision was usually right. You do not want a special variant in payroll, you want it to be correct. But at some point you notice that a company is adapting to outside specifications in exactly those processes where it wanted to be distinctive. The off-the-peg suit sits well at the sleeve and wrong at the shoulder — and the shoulder was the reason you wanted a tailor in the first place.
What happens when taking measurements gets cheap
Now imagine the tailor’s hourly cost falls by ninety per cent.
That is roughly what is happening to software, and the reason is AI. The part that used to be expensive, writing and testing code, has collapsed. Over the past year I have watched a series of small tools appear that nobody would previously have written a business case for: a calculator for an awkward pricing model, a checking routine for lists someone otherwise reconciles by hand, a dashboard for exactly one recurring question. One or two days of effort each instead of six weeks.
And straight away the first asterisk. That collapse holds for things that are small, new and well described. For changes to large, grown systems the evidence is a good deal less uniform; there are clean measurements in which experienced developers were slower with AI support, because context and rework cost more than the typing saves. This does not weaken the thesis, it sharpens it — what gets cheap is the part that used to sit below the threshold.
So the interesting number is not the saving. It is the threshold. Let us do the arithmetic. A checking routine saves five people two hours a week each, which is roughly five hundred hours a year, call it sixty person-days. If the tool costs fifty person-days, it just about washes its face in year one. Nobody files that request; it does not survive the approval round. If it costs two, it is finished on Friday and has paid for itself by February.
What lies between those two worlds is not an efficiency gain. It is a decision that was never on the table before. And there are thousands of them. What falls below the threshold is not the big systems but the small ones — the ones that irritate the business every single day.
The second effect is subtler and, to my mind, the more important one: willingness to change goes up. When an adjustment costs six weeks and a change request, an organisation learns not to wish for adjustments. When it costs two days, the business asks again. And a business function that asks again is an early warning system that had been switched off for three decades.
The tailor needs your measurements
And here is the part almost everyone underestimates.
A bespoke suit for someone who does not know their own measurements does not turn out better than off-the-peg. It just turns out more expensive. Taking measurements was never the sideshow, it was the actual work.
Translated: software that fits your process presupposes agreement inside your company on what a customer is, when an order counts as complete, and which machine belongs to which plant. That is exactly the part that does not get cheaper. The code effort falls; the effort for a shared data model stays where it was.
So the bottleneck shifts. For years it sat with development capacity. In future it sits with the question of whether your company can describe itself. Technology is no longer the bottleneck, your measurements are. Anyone who builds twenty small applications on twenty different definitions of “customer” has not achieved customisation but twenty new data silos, in record time. A data and AI strategy sounds like a grand phrase for this problem, but it means something very concrete: a shared language before anyone starts cutting.
The AI half makes that more urgent, not more relaxed. AI does not only lower the price of sewing, it will also be working inside your processes itself. An agent needs the same clarity as an application; it simply behaves differently when that clarity is missing. The application throws an error, the agent invents a plausible-sounding intermediate state. And an agent that finds twenty definitions of “customer” will settle on one. It just will not tell you which.
That leads to a test I find uncomfortably concrete, which is why I like it: would a competitor who copied your process exactly become better for it? If yes, it is off-the-peg, and standard software remains the right answer. If no, you have found a place where bespoke work actually changes something. The test earns its keep because you cannot answer it with a vendor comparison: it requires someone in the room to say out loud what sets this company apart.
Who sews, and who looks after it
Which leaves the question that comes last in these conversations and belongs first: who builds all of this?
The comfortable answer is “the business itself”. It is half right. The business knows the measurements, which is why the sums work at all. But a tool that takes two days to build gets used for the next three years, and at some point the colleague who built it moves on.
Building gets cheap, owning does not. Every application wants to be operated, updated, secured and eventually switched off. Those costs have barely fallen. Convert the whole building saving into volume and in three years you will have a wardrobe full of suits and nobody to look after them.
So the answer is not a question of roles but the old division of labour in a new situation: business leads, people and technology enable. The business says which process deserves bespoke work. People means something very concrete here: who is allowed to build, who reviews, who takes the thing over when its maker moves on. And technology provides the workbench: environments, access, reusable building blocks and one place where the twenty tools are visible instead of scattered across twenty drives.
And now the asterisk under the asterisk: the maths only works with discipline. The efficiency does not come from someone clicking something together quickly. It comes from building, checking and operating surviving as a craft. Cheap code without review is not a bespoke suit, it is a piece of cloth with sleeves.
The real question gets sharper
The encouraging part: the shift forces a better question.
As long as building was expensive, the question was “what can we afford?” Now it is “what are we actually special at?” That is more uncomfortable, because you cannot buy the answer in.
So my recommendation is a modest one: before you launch a wave of internal tools, work out which two or three processes genuinely set you apart. That is where bespoke pays off, and it pays off immediately.
Ready-to-wear never fitted better. It was merely affordable. That is changing.
Measurements first. Then the fabric.