Cathedrals Nobody Visits: The Quiet Tragedy of Britain's Abandoned APIs

Let's take a moment to mourn the dead.

Not people — software. Specifically, APIs. More specifically, the kind of lovingly engineered, extensively documented, RESTfully correct, semantically versioned APIs that British software companies have been quietly building and then quietly watching gather dust for the better part of two decades.

They are out there right now. Sitting on servers. Responding to the occasional health check. Maintained by someone who's not entirely sure why they're still maintaining them. They have Swagger documentation that nobody has read since it was written. They have rate limiting configured for a volume of traffic that never materialised. They have OAuth2 authentication for users who never signed up.

They are, in the language of software archaeology, ruins. Expensive, well-built, structurally sound ruins.

How This Keeps Happening

The British software industry has a particular weakness for building things properly. This is, in most respects, admirable. Proper documentation, sensible versioning, clean separation of concerns — these are not bad instincts. The problem is what happens when 'building it properly' becomes the goal rather than the means.

Here is the typical sequence of events:

A company builds a product. The product works. Someone — often an engineer, occasionally a founder who's just been to a conference — has the idea that the product's core functionality could be exposed as an API. Other systems could integrate with it. Partners could build on top of it. A whole ecosystem could emerge.

This is, in principle, a reasonable idea. APIs are genuinely useful things. The question is whether this API, built by this company, for this hypothetical ecosystem, is a reasonable use of the next six months of engineering time.

The answer, in a surprising number of cases, is no. But nobody finds that out until much later.

The Ecosystem That Wasn't

Building an API on the assumption that partners will integrate with it is a particular kind of optimism that the British tech industry has not yet managed to cure itself of. It goes like this: the product exists, the API is built, and then... the partners are discovered to be less enthusiastic than anticipated.

This is not because the API is bad. Often it's excellent. It's because the partners had their own priorities, their own development resources, and their own ideas about what was worth integrating with. The assumption that 'if you build it, they will integrate' turns out to be just as flawed in software as it was in that film about a baseball pitch.

The result is an API that works perfectly and is used by almost nobody. The documentation gets a bit stale. The versioning becomes a historical record of features nobody asked for. The engineering team continues to maintain it because deprecating it feels like admitting defeat, and also because there's always the vague hope that someone will eventually turn up and use the thing.

Sometimes they do. More often, they don't.

The Maintenance Trap

The cruelest part of the unused API is not the initial waste of engineering time — significant as that is. It's the ongoing cost of keeping it alive.

APIs, unlike a document or a static page, require active maintenance. Dependencies need updating. Security vulnerabilities need patching. Authentication standards evolve. The infrastructure underneath needs to keep running. Every year the API sits unused, it's costing money and engineering attention that could be directed at something people are actually using.

British companies are particularly susceptible to this trap because of a cultural tendency towards conscientiousness. You built the thing properly, so you maintain it properly. You don't just switch it off without warning — what if someone's using it? You check the logs. The logs show three external callers in the past six months. Two of them are your own monitoring system. One of them appears to be a developer at a company you've never heard of who made four requests in January and then never came back.

You keep maintaining it. Just in case.

The Cathedral Problem

There's a famous essay in open source circles that distinguishes between 'cathedral' and 'bazaar' approaches to software development — the cathedral being planned, structured, and built to last; the bazaar being organic, chaotic, and responsive to what people actually need.

The abandoned API is a cathedral. It was planned carefully. It was built to last. It was designed to support a community that, as it turned out, had other plans.

The tragedy isn't that cathedrals are bad — they're magnificent things. The tragedy is building one when what the situation called for was a bus shelter. Functional. Modest. Used every single day by actual people who needed to get out of the rain.

A cottage API — one endpoint, one use case, built in a week, deployed and tested with a real integration partner before a line of documentation is written — would have served the purpose better, cost a fraction of the price, and been far easier to deprecate when circumstances changed.

What Proper Looks Like

This is not an argument against building good APIs. It's an argument against building good APIs for hypothetical users.

The distinction matters. A good API built for a specific, confirmed integration partner — one who has agreed to use it, been involved in its design, and has a genuine business reason to connect to your system — is an excellent investment. The quality, the documentation, the versioning: all of it pays off.

A good API built on the assumption that partners will materialise is a cathedral on a road that hasn't been built yet.

The companies that get this right tend to follow a similar pattern. They resist the API conversation until someone actually asks for it. When a potential integration partner appears, they build the smallest thing that satisfies that specific integration. They document what exists, not what might exist. They treat v1 as a real thing people use, not a placeholder for the comprehensive platform they'll build later.

They build cottages. Sturdy, well-made, inhabited cottages. And they only add a second storey when someone needs to sleep upstairs.

A Checklist for the Honest Moment

If you're currently maintaining an API that you suspect might be in the early stages of becoming a cathedral, here are some questions worth sitting with:

• How many external callers have made a request in the past 90 days? Not your own monitoring — actual external systems.
• Could you name those callers? Do you have a relationship with them?
• If you deprecated this API tomorrow, who would you need to notify?
• When was the last time a real user asked for a feature in it?
• What would you build instead if this didn't exist?

If those questions produce uncomfortable answers, you might be maintaining a ruin. And while ruins are historically interesting, they are not, as a rule, a good use of an engineering team's Tuesday.

The Honest Exit

Deprecating an API that nobody uses is not failure. It's information, acted upon. It tells you something true about where the demand actually is, and it frees up resources to go and find it.

Britain's software companies are, on the whole, exceptionally good at building things. The next frontier is getting equally good at not building things — or at least, building them smaller and checking whether anyone's home before commissioning the flying buttresses.

The best idea, as ever, fits on a beermat. If your API documentation doesn't, it might be time to have a quiet word with yourself about what you're actually building — and who, if anyone, you're building it for.