The rule was about cost all along

Nobody taught me this one in a lecture. I'm self-taught, and most of what I know about architecture I learned by watching projects succeed or struggle. This rule came from the struggles.

Integration is where projects go to die. Every system you connect needs an adapter. Someone has to build it, and someone has to keep it working long after the project that needed it has finished. So you buy a platform, accept its limits, and keep the custom glue to a minimum.

I've written some version of that into architecture standards myself. At Oxfam I designed integration around a hub and spokes, so each new system meant one new connection rather than one for everything it touched. And I've argued it in public: my own Wanating CMS Core write-up warns against the bespoke build that works beautifully until the person who built it leaves.

I still think the rule was right. I'm less sure it still is.

Over the last two months, the private console behind this site has broken that rule more times than I can count.

The bus data alone arrives in three different transport standards, each its own flavour of XML. Road closures come in a fourth. Flood warnings, weather, the council's bin schedule, my energy supplier, the trains: every one has its own API, its own quirks and its own idea of what a date looks like. Fifteen pollers run on a schedule, fed by around twenty small adapters, each turning one outside format into the same simple shape.

The version of me writing architecture standards would have pushed back hard. Each of those adapters is the slow, unrewarding part of any project: read the specification, find where the real data disagrees with it, write the parser, chase the edge cases. Pairing with Claude Code, that leg work became the quick part.

The integration layer was still necessary. It just stopped being the part I dreaded, and I started building it on purpose.

Once the glue is cheap, a different kind of design starts to look sensible. Instead of one big platform, lots of good single-purpose tools, each with an API, and a thin layer I own on top.

Take the speakers. The house has speakers from three different makers, each with its own app, and they don't agree on much. Music Assistant, an open-source server, already speaks most of their languages. What it didn't have was a place in the rest of my life. So the console gained a Media section: one page for music, audiobooks, films and TV, playing to whichever speaker I choose, with my own library behind it. The speakers didn't change at all, only the thing in the middle.

Or the films. I own Blu-rays that were never ripped. They now sit in the same Films and TV view as everything on Plex, entered from photos of the shelf, with their details found through Plex's own metadata rather than another lookup service. It replaced the films half of Armarium, an app I'd built for exactly this only a few months earlier. A few years ago I'd have struggled to justify throwing away something that new.

And the history is mine now. The data service keeps everything it collects, in my own database. Energy use goes back to July 2024, from the supplier's own data. The live bus feed forgets where each bus was a minute ago, so I keep it, and after a few months I can tell which routes actually turn up. None of it needs a subscription or lives on someone else's server.

I'd started down this road for privacy and cost. I hadn't expected it to change how I thought about design.

It took me a while to see this, but I think "keep integration to a minimum" was really shorthand for two costs, and I'd stopped noticing they were separate.

The first was the cost of building it: the leg work above. That one has collapsed.

The second was the cost of owning it. Every adapter is something someone has to understand when it breaks at the worst possible moment. Outside APIs change without asking. The person who built it moves on, and the understanding goes with them. That cost has barely moved. If anything, cheap building makes it easier to pile up things nobody understands.

So I don't think the rule goes away. But it's protecting something different now.

I try to hold this setup to the standard I'd want at work, which mostly means boring habits.

I write things down a lot more than I used to. Every part of the code has a note next to it saying why it's like that and what I tried first, mostly so that whoever opens it next, me in a year or an agent next week, isn't left guessing. The tests sit where outside data comes in (the transport parsers, the flood and energy clients, the bin schedule), because when a supplier changes a format I'd rather a test told me than a blank page did. And the server has a runbook for rebuilding it from a blank disk, with backups that get restore-tested every week.

I also delete things more than I used to. An AI-powered sheet music reader, half of Armarium, a sprawl of separate websites folded into one. If it's cheap to build, it's cheap to throw away, and I'm still getting used to that.

If I were writing that architecture principle today, I think it would say something closer to:

Build only what the next person, or agent, can understand, test and take over.

I'm not sure that's the final wording. It still rules out plenty: the clever one-off nobody documented, the adapter with no tests that only works because nothing has changed yet. But it lets in a lot the old rule kept out, like small, well-described bits of glue that let good tools work together, instead of one big platform you bend to fit.

It doesn't mean stop buying. The core systems an organisation runs on should usually still be bought, and supported by people whose job that is. What I think has moved is the line between what you buy and what you build around it.

I learned the first rule from projects that struggled. I'm still working out how far this one goes.