Does Your Tech Stack Spark Joy? A Ruthless Beermat Audit for the Genuinely Overwhelmed

There's a particular kind of horror that visits senior developers in the small hours. Not the horror of a failing deployment or a corrupted database — those are at least honest emergencies. No, this is the horror of opening a repository you haven't touched in eight months and discovering that what was once a tidy little web app has quietly become a lurching Frankenstein of npm packages, abstraction layers, and something called a "universal micro-kernel event bus" that nobody can explain but everyone is too frightened to remove.

This is technical debt wearing a very convincing costume. And the costume, if you look closely, is made entirely of decisions that seemed sensible at the time.

The Beermat Test doesn't care about what seemed sensible at the time. It asks a simpler, more brutal question: can you explain why this exists in one sentence? If the answer requires a whiteboard, a twenty-minute preamble, or the phrase "it's complicated," you already know what you're dealing with.

The Audit Starts With Honesty (Which Is the Hard Part)

Before you open a single config file, you need to do something deeply uncomfortable: write down what your product actually does. Not what it could do, not what the roadmap says it will do in Q3, not the version you described to that investor in the pub. What does it do right now, for actual users, on a Tuesday afternoon?

Fit that on a beermat. Seriously, try it. If your product's core value proposition requires more than three lines of cramped biro scrawl, you've either got a genuinely complex product (rare) or you've lost the plot somewhere between the initial idea and the current codebase (extremely common).

Once you've got that sentence — that single, honest, slightly humbling sentence — you have your audit framework. Every piece of your stack now has to justify itself against it.

The False Economy of 'Flexible' Frameworks

British developers have a particular weakness for frameworks that promise flexibility. We love optionality. We love the idea that we could pivot, could scale to ten million users, could support seventeen different database backends if the business ever demanded it. This is how you end up with an ORM configured for three different database types when your product has used PostgreSQL since 2019 and will continue to do so until the heat death of the universe.

Flexibility, in the abstract, costs you nothing. Flexibility, implemented in code, costs you everything — in complexity, in onboarding time, in the cognitive overhead of every developer who has to hold the entire abstraction in their head before they can change a button colour.

A useful heuristic: if a framework's primary selling point is that it "doesn't constrain you," treat that as a warning label. Constraints, applied thoughtfully, are what make software shippable. Rails was opinionated and half the internet was built on it. Your bespoke event-sourced CQRS architecture is very flexible and has been in development for fourteen months.

What UK Teams Found When They Actually Looked

The pattern repeats itself with remarkable consistency across British tech companies that have been honest enough to talk about it publicly. A fintech startup in Leeds spent three months ripping out a service mesh they'd implemented because a conference talk made it sound essential — their team of four developers was maintaining infrastructure complexity designed for organisations with dedicated platform engineering teams of thirty. Shipping velocity doubled within six weeks of removing it.

A SaaS company in Bristol discovered, during a routine audit, that they were running eleven different logging and monitoring tools across their stack. Not eleven dashboards — eleven separate tools, many of them overlapping almost entirely in functionality, several of them no longer actively maintained. The reason? Each one had been added by a different developer, each of whom had a strong personal preference and hadn't checked what was already there. The audit took an afternoon. Consolidating to two tools took a week. The annual infrastructure saving was enough to fund a junior hire.

These aren't cautionary tales from reckless cowboys. These are competent teams who got busy, made reasonable-seeming decisions in isolation, and never stepped back to look at the whole picture.

How to Actually Run the Audit

Start with dependencies. Pull up your package.json, your requirements.txt, your Gemfile — whatever your poison — and go through it line by line. For each entry, ask: what does this do, and what breaks if we remove it? If you can't answer the first part, that's a problem. If the answer to the second part is "honestly, we're not sure," that's a bigger one.

Next, look at your architectural decisions. Every abstraction layer, every service boundary, every "we'll need this later" interface — hold each one up to the beermat. Does this serve the product as it exists today? If the answer is "it serves the product we were planning to build," schedule a conversation about whether you're still planning to build that.

Then look at your infrastructure. Cloud services are particularly prone to accumulation. That Lambda function running on a cron job that nobody's checked in two years? The S3 bucket with a name that suggests it was created during a hackathon? The RDS instance that appears to contain data from a product you discontinued? These things cost money and, more importantly, they cost attention — the finite, precious resource that determines whether your team ships things or maintains things.

Finally, and most importantly, look at your processes. Technical debt isn't only in code. It's in the eleven-step deployment checklist that grew one step at a time over three years. It's in the Slack channels nobody uses but everyone's still in. It's in the weekly meeting that was originally called to solve a problem that no longer exists.

The Beermat Isn't About Minimalism — It's About Clarity

It would be easy to misread this as an argument for building everything from scratch with the bare minimum of tools. It isn't. Some products genuinely require complexity. Some architectural decisions that look like over-engineering are actually load-bearing walls that will matter enormously when you need them.

The beermat audit isn't asking you to strip everything back to nothing. It's asking you to be able to explain everything you have. If you can write down why a piece of your stack exists, what problem it solves, and what the cost of removing it would be — and that explanation fits on a beermat — then it earns its place.

The things that can't pass that test? They're not your tools. They're your technical debt in a very convincing trench coat, standing at the door of your codebase, eating your velocity one sprint at a time.

Get the beermat out. Start writing. Be honest about what you find.

Your future self, six months from now, staring at a codebase that actually makes sense, will be insufferably grateful.