When do you need a tech audit

The symptoms are almost always the same. A vendor keeps quoting six-month timelines for changes that sound simple. The engineering team is busy, always, but nothing ships. A new hire cost more than expected and still does not understand the codebase six months in. The founder makes technical decisions because there is nobody else to make them.

None of that is normal. **All of it points to a system that has grown past the people managing it.** A tech audit does not fix the system. What it does is name the problem precisely enough that you can decide whether to fix it, sell it, or work around it.

We have done over a hundred of these across EU companies of all sizes. The findings are rarely surprising to the people inside. What the audit gives them is permission: to cancel the vendor contract, to restructure the team, to tell the board what has been quietly obvious for two years.

Code quality matters, but it is rarely the root problem. The questions that drive the most valuable findings are commercial: **What would it cost to migrate off this vendor? How long would it take to rebuild this system if the contractor disappeared? Why is this taking eight months instead of two?**

In practice, a thorough audit covers: architecture (how systems connect, where the single points of failure are, what the migration cost would be for the major dependencies), team and process (how decisions get made, how work gets scoped, where accountability lives), security and compliance posture (access controls, dependency vulnerabilities, data residency, GDPR exposure), and vendor contracts (what you are actually committed to, what the exit clauses say, whether the pricing is in line with what the market would charge).

The output is not a scorecard. It is a prioritised list of risks with commercial context: here is what this costs you today, here is what it will cost you if you let it run another year, here is what it would cost to fix it. You decide what to do with that.

The range is driven by scope, not day rate. A single-system audit (one vendor relationship, one platform, one integration) is at the low end. A full-stack assessment across infrastructure, code, team structure, vendor contracts, and compliance exposure takes longer and costs more. Both are flat-fee engagements: you know the number before we start.

**The benchmark question is always the same: what is the risk we are auditing against?** A six-figure vendor retainer that has been renewing for three years without review is worth auditing at the €8,000 level. A pre-investment technical due diligence where a bad finding could move the valuation by 20% is worth spending €15,000 on. The audit is not the cost. The exposure it uncovers is the cost.

We cancelled a vendor contract worth €480,000 per year for one client in two weeks of audit work. The total cost of the engagement was under €10,000. We are not suggesting that result is typical. We are suggesting that the math is usually in the same direction.

A report that sits in a folder has no commercial value. The best-run audits we have been part of ended with a clear set of prioritised actions, a named owner for each, and a 90-day follow-up to check progress. In some cases we stay involved in implementation: negotiating with the vendor, leading the migration, restructuring the team setup. In others, the client takes the findings and runs with them internally. Either works.

What does not work is commissioning an audit because a board member asked for one and then shelving it when the findings are uncomfortable. If you are not ready to act on what you find, wait until you are. The right time for a tech audit is when you are prepared to use the information.

If you have a specific situation in mind, the scope call is the right next step. Thirty minutes, no deck. We ask what decision you are trying to make, assess whether an audit is the right tool for it, and tell you what the engagement would look like and what it would cost.