Making Change Cheap
The thread through everything I build: the expensive part of software isn't writing it, it's changing it — and good systems make the next change smaller than the last.
For a long time I thought my job was building things. Components, features, pipelines, dashboards. After enough years across enough systems, I think it's something narrower and more useful: making the next change cheap.
Almost nothing ships once and stays still. Products grow, brands multiply, rules change, data shifts. The cost that decides whether a system stays healthy isn't the cost of building it — it's the cost of changing it the tenth and hundredth time. Most of the work I'm proud of is really the same move applied to different materials: find where change keeps happening, and make that spot cheap to change.
It took writing several of these down to notice they were one idea.
The same problem, wearing different costumes
In a shared component platform, the expensive thing was changing one element across three apps. The fix was to stop keeping three copies and keep one definition with consumers — so a change lands once instead of three times. I wrote about that in One Component Library, Three Applications.
Serving many brands had the same shape one level up. Each new brand looked like a reason to fork, and forks make every future change N times more expensive. Treating brand differences as configuration rather than code keeps it one codebase — Serving Many Brands from One Codebase.
Then the question moves from "what should be shared?" to "what should be code at all?" When the business keeps changing the same rules, moving that behaviour into configuration makes those changes cheap — though only up to a point, which is the real subject of Every System Eventually Wants to Become Configurable.
Even the AI work was this idea in disguise. A model shipped once is a liability; what makes computer vision survive contact with changing data is the loop around it — evaluation, review, iteration — so it can improve safely instead of being rebuilt. That's The Problem Is Almost Never the Model. And none of it matters if you can't tell whether a change helped, which is why measuring honestly — Measuring Latency Honestly — belongs in the same family.
The goal was never to make software. It was to make the next change to it smaller than the last.
Why "cheap to change" is the right target
Optimising for cheap-to-build gives you something that ships fast and calcifies. Optimising for cheap-to-change gives you something that keeps moving as the world around it moves. Those are different systems, and you can usually feel which one you're in: in the first, every request turns into an argument with the past; in the second, change is boring, which is the highest compliment a system can earn.
It's also why I'm wary of flexibility for its own sake. Making everything configurable, abstract, or generic is a way of making all change cheap — and that overshoots, because it adds complexity everywhere to buy flexibility you mostly won't use. The skill isn't maximum flexibility. It's locating the few places where change actually keeps happening and spending your complexity budget only there.
The lesson
Across a component library, a multi-brand platform, configurable workflows, an applied-AI loop, and an analytics layer, the through-line is one sentence: good systems make change cheap where change actually happens. Find that spot, invest there, and defend it against the exceptions that would slowly tax every future change. Do that and the system stays soft enough to keep up with the business. Skip it and it hardens — not because anyone wrote bad code, but because nobody made changing it cheap.