Tech audit.

Founders book audits because something has started feeling off. The questions sound like operational frustration. The audit translates them into engineering reality.

Why does it take three weeks to ship a simple button? Usually high cyclomatic complexity, no separation of concerns, and a test suite mocked all the way down. The audit names which files have rotted and which still earn their keep.

What happens if our lead engineer leaves? The bus factor question. The answer is in the documentation, the runbooks, and how many people have actually shipped to production this quarter. Most early-stage companies discover their answer the worst possible way.

Is our AI capability real? A 2026 question that cuts deeper than it sounds. The audit distinguishes proprietary IP from a wrapper around an off-the-shelf model. It checks the data pipeline, the training provenance, and whether anyone other than the founder could reproduce the result.

The question I rarely get asked but always answer: how much of your next two years of engineering budget will go to fixing what’s already there? Sixty percent is normal for codebases that have shipped fast for two years without a deliberate cleanup pass. That number lives in board decks. Founders who ignore it discover it the quarter they try to scale.

Three situations bring most founders to the table.

Fundraising and M&A readiness. Six to eight weeks before a term sheet, an audit lets you fix structural gaps before an investor’s technical advisor names them. It moves the negotiating leverage by a clean step. The same applies on the sell side of a small acquisition.

Hyper-growth friction. Delivery has slowed. The platform is buckling under load. A campaign succeeded and exposed something unfortunate about the database. An independent read separates symptom from root cause faster than the team can while it’s shipping the next thing.

Leadership transitions. A new CTO inherits a codebase. A founding engineer leaves. A pivot lands. An audit gives the new leader a baseline, written by a peer, that aligns expectations with the CEO before the first roadmap argument. Same logic before a rewrite: most rewrites are panic responses, and the audit usually surfaces a refactor that lands in twelve weeks instead of a rebuild that drags for twelve months.

The misjudgement is “we’ll do this once we’re bigger.” Technical debt compounds. The audit gets harder, more expensive, and more politically loaded the longer it waits. By the time you can’t avoid it, the findings will be exactly the ones you didn’t want to act on at year two.

The report runs 15 to 20 pages. Density over volume. Page one is the executive summary in plain English. Page two is a one-page risk matrix: Critical, Major, Minor on one axis, effort to remediate on the other. A founder who reads only those two pages walks away with the right picture.

The body is structured around three pillars.

Architecture and scalability. System boundaries, data flows, single points of failure, whether a 10x load needs a rebuild or a refactor. Cloud spend that scales linearly with revenue, or that has an efficiency gap getting wider every quarter.

Code quality and technical debt. Cyclomatic complexity, test coverage on the paths that matter, churn in the core business logic. AI-readiness, where the question is whether the data layer is decoupled enough that LLM integration isn’t an uphill battle.

Security and compliance. Authentication and authorization, encryption, dependency hygiene, the gap between current posture and SOC 2, GDPR, or DORA where relevant. The boring kinds of failure that end careers.

Two cross-cutting concerns sit through all three: team and bench depth (ownership maps, key-person risk, ramp-up time for a new engineer) and AI maturity (whether the AI claim is a real efficiency engine or a fragile demo dressed up for the deck).

Every finding ships with a severity, an effort estimate in engineer-weeks, and a concrete recommendation. The remediation roadmap at the back is just those notes, sorted.

Not a penetration test. I assess your security practices and posture. I don’t spend two weeks actively trying to break in. That’s a different engagement, run by a different kind of specialist.

Not a rewrite plan. The audit identifies whether a rewrite is the right answer. The actual specification for a new system is a separate piece of work.

Not a compliance certification. The report tells you what stands between you and SOC 2 or ISO 27001. The certification itself comes from a licensed auditor.

Not a line-by-line review. I read representative slices of the codebase looking for patterns, not semicolons. Anyone claiming otherwise is either lying or wasting your money.

The honest disclaimer: the report is a point-in-time read. It captures the state of the company on the day I finished writing it. It identifies known liabilities. It does not predict the failure modes you will introduce next quarter. Treat it as a one-shot insurance policy and it will let you down. Treat it as the first chapter of a written engineering practice and it earns its fee for years.

The standard engagement is two weeks.

Week 1 is context. We start with a kickoff and an information dump from CEO and CTO. I read architecture diagrams, API documentation, recent postmortems, and any active engineering OKRs. Then four to six 45-minute interviews: founder for vision alignment, CTO for architectural depth, a lead engineer for ground truth, an ops or DevOps person for release reality. I add a customer success or support voice when one is available. They tend to know things engineering doesn’t.

Week 2 is analysis and synthesis. Directed code review against the questions surfaced in Week 1. Infrastructure cost and usage analysis. A database performance read. The deliverable cadence is deliberate: one final report, preceded by a verbal interim readout mid-Week 2 so nothing in the document is a surprise. The engagement closes with a live walkthrough for the founders or the board.

What’s distinctive: I’m the second engineer in the room, not an external assessor flown in for the week. I write the report myself. No junior packs slides. Every observation lands in language that works for both the technical lead and the non-technical partner. Most early technical mistakes are not code mistakes. They’re decision mistakes made too late. The audit names them while there’s still time to act.

A standard tech audit is fixed-fee, €10,000 to €15,000.

What moves the price inside that band is mostly scope. A monolithic codebase past 300,000 lines takes more time than a modular setup. A 15-plus person engineering org needs more interviews to surface the real silos. Specialized add-ons (AI training-data provenance, hardware-software integration, regulated-industry compliance) extend scope.

Payment is 50/50. Half on signature to lock the calendar, half on delivery of the final report. Once you commit, kickoff lands within 48 to 72 hours. Two weeks later you have the report.

Investor side? See /tech-due-diligence. Same engagement, different lens.