What happens in a software audit (and why it's the smartest €5k you'll spend)

TL;DR: A software audit — the technical kind, not license compliance — is a senior review of your code, architecture, and dependencies that ends as a knowledge base committed into your repository plus an update plan with effort estimates. Ours costs €5,000 flat, takes days to weeks depending on codebase complexity, and starts with a call about your plans, not with the code.

The first thing we ask for in a software audit isn't the code. It's a call about where the product is going — and a screen recording of someone actually using your app.

That surprises people. They expect us to demand repository access and disappear into the source for two weeks. But an audit that starts from the code answers the wrong question. The code can tell you what was built. It can't tell you whether that's dangerous for what you're planning to do next — and that second question is the one you're paying €5,000 to answer. So here's the whole process, step by step, including what you're physically holding at the end.

Which kind of software audit this is

The term needs untangling first, because "software audit" means three different things. In enterprise IT it usually means a license-compliance audit — a vendor like Microsoft or Oracle checking whether you're paying for what you use. In accounting, "audit software" is tooling for financial auditors. Neither is this article.

What we're talking about is a technical software audit (also called a code audit or technical audit): an independent senior review of a product's source code, architecture, dependencies, and infrastructure, done to establish what state the system is really in and what it will take to move it where the owner wants it to go. If you're being audited by a software vendor, this is not your article. If you own a product and don't fully trust what's under the hood, it is.

When you actually need one

Nobody buys an audit for fun. The trigger situations we see, in rough order of frequency: you inherited a codebase — through an acquisition, a departed CTO, or a vendor handover — and nobody on your side can vouch for it. Your roadmap has been slowing for quarters and you want to know whether the cause is the technical debt everyone mentions but nobody has quantified. You're about to commit serious money to a rebuild or a major feature push and want the foundation checked first. Your product was vibecoded to validate demand and now real customers are asking to pay. Or a project has already visibly failed and you need an honest map before deciding what's next.

One thing an audit is not, and this matters if you're a founder whose team will be in the room: it is not a performance review of your engineers. Every codebase we've ever opened carries compromises — ours included. Code is written under deadlines, pivots, and the permanent shortage of time, and it looks like it. The audit's question is never "who wrote this?" It's "what does this mean for the next thing you want to do?"

What actually happens, step by step

I'll walk you through our process as Miro, who leads most of our audits, runs it. Other serious vendors differ in detail, but the shape is a useful benchmark for evaluating anyone's offer.

It starts with a call, not with code

The first session is a call — usually with the whole team on both sides, so everyone hears the same thing. We ask about the short-term and the long-term plan for the product. That's not small talk; it's aim. An audit without a target degenerates into an expensive list of everything that could theoretically be better. Knowing you want to, say, double the customer base, add a mobile app, or hand the system to a new team tells us what "dangerous" means for you specifically.

On that same call we ask for repository access and for a guided video of the app in use — someone walking through the product the way a real user works with it. The video does something code reading can't: it connects what the system does to what the code says, from minute one.

Both entries in the right column deserve their why. Production data: unless your problem is data-related — optimization bottlenecks, for instance — we never request it. There's no reason for an auditor to hold your customers' data, and you should be suspicious of one who wants it by default. Documentation: helpful when it exists, but we don't require it, because documentation routinely describes the system as someone remembered it, not as it is. The code is the only witness that doesn't misremember.

The first sweep: how old is this system, really?

With access in hand, the team's first pass is deliberately unglamorous: package specifications, lock files, configuration. It tells us where the system stands in time — which framework versions, which dependencies, how far behind current releases.

This boring step carries more risk signal than any other single check, and the industry data explains why. In Black Duck's 2025 Open Source Security and Risk Analysis, 86% of risk-assessed applications contained at least one vulnerable open source component, 90% contained components more than ten versions behind the current release, and 79% included components with no development activity in two years. As Fred Bals of Black Duck puts it: "Open source isn't inherently risky – it's how we manage it that matters." Your product almost certainly stands on open source; the sweep establishes how well that ground has been maintained.

The knowledge merge: connecting features to code

Then the real work: cross-checking the application layer by layer, merging what we learned from the usage video and your plans with what the code actually does. Miro calls it the knowledge merge, and the name is accurate — the goal is a complete understanding of the project, because even a small omitted detail can hide a small service with a big impact. The forgotten scheduled job that quietly reconciles your invoices is exactly the thing a partial audit walks past.

If you came with specific worries, we target those first. If not, the aim is general: mapping the technical debt and what closing it would take.

Everything converges on one practical question: how dangerous is change? For each part of the system — how risky is it to touch, and what does that risk translate to in manhours? That's the number your decisions actually need. "The code is messy" is an observation. "Changing the billing flow is high-risk and costs three senior-weeks to make safe" is something a CEO can plan around.

How long all this takes depends less on codebase size than on codebase diversity. Miro's heuristic: count how many times one piece of information gets changed or repurposed as it moves through the system — that's your complexity multiplier. A large but uniform codebase audits faster than a smaller one where a dozen specialized services each run their own logic loops. In practice the process runs days to weeks, and we tell you which before we start.

What you're holding at the end

Here's where our audit deliberately breaks with the industry habit. The standard deliverable in this market is a PDF: an executive summary, a findings table, a severity ranking. You read it, you nod, and six months later it's a file nobody opens.

What you get from us is a knowledge base committed into your repository, as files, living where the code lives. It contains libraries of the system's features and their meanings, tech specs, structures and connections between services, the gotchas — the non-obvious behaviors that cost the next developer a week each to rediscover — and update plan suggestions. The principle is "the more information, the better": the time spent investigating your system shouldn't evaporate into a summary. It becomes a permanent asset that onboards your next engineer, whether or not that engineer is ours.

The handover is progressive, not a single reveal — findings arrive over the engagement through calls and commits, or presented at once if you prefer it that way. And if you want to go one step further, we deliver a direct plan: concrete tasks with a specified execution process, ready for whoever does the work.

That deliverable is also why the audit is safe to buy from a company that sells development. Everything is in your repository, in the open. If you take the update plan to your internal team or a different vendor, it works exactly as well. We obviously hope the audit convinces you we know your system better than anyone else who could quote on it — that's the honest business model behind the flat price — but nothing in the deliverable locks you to us.

What it costs, and the honest small print

The audit costs €5,000, flat. For very large or unusually diverse codebases the scope grows and we say so before starting — never after. Flat pricing is possible because the process is the same shape every time; only the multiplier changes, and the multiplier is visible early.

Against the scale of what audits routinely surface, the price is the smallest number in the conversation. CISQ put the cost of poor software quality in the US at $2.41 trillion in 2022, including roughly $1.52 trillion of accumulated technical debt. Your share of that iceberg is what the audit measures — before you commit a rebuild budget, a funding round, or two more years of roadmap on top of it.

One honest expectation to set: we've delivered more than seven of these audits, and every single one was a challenge. That's not bad luck, it's selection. Simple problems get solved by internal teams; the systems that reach an external auditor are the ones carrying real complexity. One engagement earned the internal label "caution — this may be a greater challenge than expected." Nobody has ever paid us €5,000 to hear "everything is fine." If your system were fine, you wouldn't be reading this article.

Do we turn projects away? Miro's answer, verbatim: "We don't turn anyone away — all the projects need love." I'd add one exception from my side: if the business case for the product is gone, the kindest thing an audit can do is say so early. What happens after the audit — rescue, rebuild, or walking away — is a decision the knowledge base exists to make honest.

FAQ

What is a software audit?

In the technical sense, a software audit (or code audit) is an independent senior review of a product's source code, architecture, dependencies, and infrastructure. Its output is an evidence-based picture of the system's real state and what planned changes will cost and risk. It's distinct from license-compliance audits run by software vendors and from audit tools used in accounting.

How much does a software audit cost?

Ours costs €5,000 flat, with scope agreed upfront for very large codebases. Market prices for comparable technical audits typically run from about €2,000 for narrow reviews to €20,000+ for investment-grade due diligence. Suspiciously cheap audits are usually automated scans with a logo on top.

How long does a software audit take?

Days to weeks. The driver is code diversity rather than raw size: the more specialized services with separate logic — the more times one piece of information is changed or repurposed across the system — the longer the understanding takes. A serious auditor tells you the expected duration before starting.

What do I get at the end of the audit?

From us: a knowledge base committed into your repository — features and their meanings, tech specs, structures and connections, known gotchas — plus update plan suggestions with effort estimates, and optionally a task-level execution plan. Findings are handed over progressively through calls and commits, not dumped in a single PDF.

Does an auditor need access to production data?

Usually no, and you should question one who asks by default. We request repository access and a guided video of the app in use; production data only becomes relevant when the problem under investigation is data-related, such as performance bottlenecks.

What's the difference between a software audit and technical due diligence?

Same toolbox, different buyer. Technical due diligence serves an investor, acquirer, or incoming CTO evaluating someone else's system before a transaction. A software audit serves the owner: you already have the system and need to know what your next euro spent on it should do.

Will the audit just tell me to rebuild everything?

No. The output is a danger-of-change map with effort estimates, and the recommendation follows the evidence: sometimes targeted fixes, sometimes a staged rebuild of specific components, occasionally the honest advice to stop investing in the product at all. A vendor whose every audit ends in "full rebuild, conveniently by us" is running a sales funnel, not an audit.

Do I need an audit if my product was vibecoded?

If real customers are about to rely on it, yes — that's exactly the situation where a working demo hides unexamined security and architecture decisions. The audit tells you what stands between your validated PoC and a production system, with numbers instead of anxiety.

The smartest €5k, spent before the expensive decisions

Every big product decision — rebuild or patch, scale or stabilize, invest or stop — is made either on evidence or on hope. The audit is how you buy the evidence: a complete understanding of your system, committed into your own repository, with every change priced by its danger. It's the smallest cheque in the sequence, and it's the one that keeps the bigger ones honest.

If you're sitting on a system you can't fully vouch for — inherited, outgrown, vibecoded, or just quietly slowing down — book a free 30-minute kick-off on the audit page. We'll tell you what the audit would target in your case, how long it would take, and whether it's worth buying at all.