The lasagna problem: why your website has more technical debt than you think

A client said something recently that made me laugh, because it was so painfully accurate. They described their website’s back end as a “lasagna cascade.” Layer upon layer of code, plugins, patches, and workarounds, stacked on top of each other over the years. Nobody could remember what half of it was for. Nobody wanted to touch it in case the whole thing collapsed.

If you’ve managed a website for more than a few years, you probably recognise that feeling. The one where you’re told “don’t touch that module” or “we’re not sure why that’s there, but it seems to do something.” That feeling has a name: technical debt.

And your website almost certainly has more of it than you think.

What technical debt actually means

In software, technical debt is what accumulates when quick fixes and “we’ll come back to it later” decisions pile up without anyone going back to clean them. It’s the shortcut your previous developer took to meet a deadline. It’s the plugin someone installed in 2019 that hasn’t been updated since. It’s the custom code that worked beautifully at the time but now conflicts with everything around it.

Think of it like a house. You renovate the kitchen. A few years later, you add a bathroom upstairs. Then someone converts the garage. Each project was fine on its own. But nobody checked whether the plumbing could handle all three, and nobody went back to update the wiring when the building code changed. From the street, the house looks great. Behind the walls? A mess.

That’s what most organisational websites look like under the hood.

The problem is not that people made bad decisions. Most of the time, the decisions made sense when they were made. The problem is that nobody went back and asked: what were we trying to do in the first place, and what’s been left behind for no reason?

Why technical debt gets worse, not better

Technical debt compounds. Every new feature you add to a site carrying old debt has to work around that debt. So new code gets written to accommodate old code that should have been removed years ago. The new code becomes harder to maintain. The next developer writes another workaround. Another layer of lasagna.

Here’s what that looks like in practice.

Page load times creep up. Redundant scripts, unused CSS files, and bloated plugins all add weight. Your visitors don’t know why the site is slow. They just leave.

Security vulnerabilities multiply. Outdated plugins and abandoned custom code are the most common entry points for attacks. If your team’s policy is “don’t update it because it might break something,” you’ve got a security problem masquerading as a stability strategy.

Your editors hate the CMS. When the back end is a tangle of legacy decisions, content editors end up fighting the system to publish a page. It looks like something more training would fix, but the cause sits in the structure.

And migration becomes terrifying. The more debt you carry, the harder it is to move to a new platform, redesign, or even upgrade your current CMS. Everything is tangled together, and pulling one thread risks unravelling three others.

For organisations in health research, government, education, and the not-for-profit sector, where websites often run for five to ten years between major overhauls, this is especially common. The longer a site lives, the more layers accumulate.

The audit nobody wants to do

Most organisations don’t discover their technical debt until something breaks. A plugin update crashes the site. A security scan flags a vulnerability. A redesign quote comes back three times higher than expected because the developer took one look at the codebase and added a “complexity surcharge.”

By that point, you’re in reactive mode. And reactive mode is expensive.

A proper website audit is what gets you out of reactive mode, and I don’t mean a surface scan or one of those automated tools that hands you a score out of 100 and tells you your images are too big. Those tools check the symptoms, whereas an audit checks the structure underneath them.

So what does a thorough audit actually cover?

It starts with the technical baseline. Code quality, the plugin and module inventory, server configuration, database structure, third-party integrations, performance bottlenecks. This is where you find out what’s load-bearing and what’s just sitting there taking up space.

Then the security layer. Outdated dependencies, known vulnerabilities, how authentication is set up, SSL configuration, whether your backups actually restore. If you haven’t looked at this in the last 12 months, do it now.

After that, the content and UX layer. Information architecture, content types, user flows, accessibility compliance against WCAG 2.2 AA, editorial workflows. Technical debt isn’t just in the code. It accumulates in how content is structured and managed too.

And finally, a migration readiness check. If you’re considering a redesign or platform change in the next 12 to 24 months, the audit should tell you exactly what’s portable, what needs rebuilding, and what can be retired. This is the difference between a migration that goes smoothly and one that blows out by six months and 40% over budget.

One thing we do, and I’d recommend any agency worth their salt does the same: we never run the audit on the live site. We take a full copy of the database and files, install it in our own development environment, and work from there. It keeps the production site safe. And if the audit leads to a rebuild, that development environment becomes the starting point for the new site. No wasted work.

How to know if you’re sitting on a problem

You don’t need to be a developer to spot the signs. If any of these sound familiar, your technical debt is probably higher than you think.

Your development team tells you “it’s complicated” when you ask for what seems like a simple change. You’ve been told not to update certain plugins because they might break things. Page load time has been getting slower, but nobody can explain exactly why. You’ve had the same website for more than four years without a technical audit. Your last redesign was built on top of the old site rather than starting clean. Different sections of your site look and behave differently because they were built at different times by different teams. Your content editors have quietly developed workarounds to get the CMS to do what they need.

If you ticked more than two of those, it’s worth getting a proper look under the hood.

What to do about it

You don’t necessarily need a full rebuild. That’s the first thing to understand. The instinct when you discover a mess is to rip it all out and start fresh. Sometimes that’s the right call. But often, a targeted cleanup based on a thorough audit is faster, cheaper, and causes far less downtime.

Here’s the order we’d recommend.

Start with the audit. Get an honest, independent picture of where you actually stand, built from a structured review of the codebase, infrastructure, and content architecture rather than from whatever you’ve been told so far. That review is your baseline.

Then prioritise by risk. Security issues come first, performance issues next, structural issues after that. Don’t try to fix everything at once.

From there, build a roadmap. Not a wishlist. A sequenced plan with clear outcomes for each phase. This is especially useful if you’ve got a stakeholder who collects shiny new ideas (we all know one). The roadmap becomes the tool that lets you say, “That’s a great idea. We’ll look at it in month seven.” It validates the idea without derailing what’s already in progress.

And then set up ongoing care. Technical debt doesn’t stop accumulating because you cleaned it up once. Regular maintenance, dependency updates, and periodic reviews are what keep the lasagna from building back up.

Frequently asked questions

How much does a website audit cost?

It depends on the size and complexity of the site. For a mid-sized organisational website of 50 to 500 pages, a thorough audit typically takes two to four weeks. Get in touch for a scoped quote.

Can I just use an automated scanning tool instead?

Automated tools like Lighthouse or SiteGuru are useful for surface-level checks, but they don’t assess code quality, architectural decisions, or content structure. Think of them as a blood pressure reading next to a full medical examination: both have their place, and you wouldn’t swap one for the other.

How often should we audit our website?

At minimum, once every 12 months. If your site is business-critical or handles sensitive data, which is common in health research, government, and education, every six months is safer.

Is technical debt the same as a bad website?

No. Some of the best-looking websites carry enormous technical debt underneath. That’s what makes it dangerous. Everything works until it doesn’t, and by then the fix is expensive.

Do we need to rebuild, or can the debt be cleaned up?

That depends on the audit findings. In many cases, a structured cleanup is enough. If the codebase has been compromised too many times over too many years, a rebuild on a clean foundation might be more cost-effective. The audit tells you which path makes sense.

Stop building on top of the lasagna

Every year you leave technical debt unaddressed, the cost of fixing it goes up. The site gets slower, less secure, and harder to change. Your team develops workarounds for the workarounds. And the next time you need to make a real improvement, the quote will be higher than it should be, because half the work is just undoing what shouldn’t have been there in the first place.

A website audit is where it starts. A redesign or a new CMS might come later, but they only do their job once you know what’s underneath them. Skip that and you’re repainting over the same problems. What you need first is a clear, honest look at what you’ve got and what it’s going to take to get where you need to be.