A company calls us with a clear request: “we need to add a new section to the app, how long would it take you?” On paper, two weeks of work. The moment we open the code, two weeks turn into two months. Not because the new section is hard, but because the ground it has to stand on is in far worse shape than anyone imagined.
This happens more often than it seems. The product works, people use it every day and, from the outside, everything looks fine. On the inside, though, each change costs a little more than the last. That's the point where it makes sense to stop and really look at what's underneath.
What a technical audit is (and what it isn't)
A technical audit is a thorough review of the real state of a software product: how it's built, what it rests on, which parts are solid and which are about to cause trouble. It's not an opinion on whether the code is “pretty”, it's a diagnosis of whether it can hold what you want to build on top of it.
The result isn't a list of complaints. It's a map: what's fine, what needs watching, what should be fixed before moving on and, above all, how much risk sits behind every decision you make from here.
What gets analysed
Every product is different, but there's a set of areas that almost always tell the truth about the state of a project. We review the dependencies (the external libraries the software relies on), the architecture (how the pieces are organised and whether that holds up as it grows), the database, security, test coverage and the documentation that exists, or is missing.
None of these is a minor detail. They're exactly what decides whether adding the next thing takes two weeks or two months.
The surprises that show up almost every time
Some findings repeat project after project, regardless of the sector or the size of the company:
Accumulated technical debt. Shortcuts that made sense at the time to hit a deadline, but that nobody ever revisited. Each one, on its own, is harmless. Together, they turn any change into a delicate operation.
Outdated dependencies. Libraries that haven't been updated in years, sometimes with known vulnerabilities, sometimes simply abandoned by whoever maintained them. The day you need to update one, you find it drags ten others along.
Code nobody understands. More and more often we find AI-generated code that got accepted because "it worked", but that nobody ever fully understood: huge, repetitive blocks with no clear logic behind them. While everything runs fine it bothers no one; the trouble starts the day you have to touch it and find there's no one (no person, no document) who can explain why it's built that way.
Architecture that doesn't scale. Decisions that worked perfectly with a hundred users and start to creak at ten thousand. They weren't wrong, they were built for a different moment.
Missing documentation. The project's knowledge lives in the head of one person who may no longer be around. Without documentation, every new hire spends weeks understanding something that should have been written down.
Why do it before building more
When a product already works, the temptation is to keep stacking things on top. More features, more screens, more integrations. The problem is that each new layer rests on the previous one, and if the base isn't healthy, all you're doing is building higher on something that was already shaking.
Running an audit before that next step gives you something you usually don't have: information to decide with. Sometimes the answer is “all good, go ahead”. Other times it's “fix this first, it'll save you months”. Either way, you stop moving forward blind.
The problem isn't always adding, sometimes it's knowing
It's easy to assume that progress always means building more. But there are moments when the most profitable step isn't writing a single line of code, but understanding precisely the state of what you already have.
Knowing where you stand doesn't slow the project down: it's what lets you move forward confident that it won't all come crashing down at the worst possible time.
At Liquid we run these audits on products we didn't build ourselves. Not to rewrite everything, but to give you an honest diagnosis and a clear plan for what to do next.
