Audit-first vs build-first: When each approach pays off

Week one, the team starts building, because the release date went out to customers before anyone looked at the repository. Month four, a change to the billing module silently breaks a scheduled job nobody knew existed, written by a contractor who left in 2023. The fix takes eleven files and a fortnight. The two-week audit they skipped in week one is the only reason nobody saw it coming.

This guide is for CTOs and engineering leads inheriting a codebase, taking over from a departing vendor, or restarting a stalled platform. It covers what each approach actually buys you, the point at which auditing first stops paying for itself, a cost model you can run against your own rates, and the signals that tell you you have picked wrong.

TL;DR: which approach fits your situation

We have been inheriting other people's code at Hotovo since 2010: fintech applications handed over with no documentation, decade-old frontends that could not stop shipping, platforms passed to us mid-project after a supplier failed. Our average client partnership runs past six years, so we are still holding whatever we decided in week one long after the decision stops feeling like ours.

The recurring failure mode is treating the audit as a delay to negotiate down, then paying for exactly the same findings later, at a point where three sprints of work already sit on top of them.

The crossover threshold: audit-first pays when the cost of one wrong architectural assumption exceeds the cost of the audit window. Both sides are computable. The audit window is its duration multiplied by your blended day rate, plus the value of the work it postpones. The other side is the share of the codebase you expect to touch, multiplied by the odds it hides something structural, multiplied by what that costs to unpick after you have built on it. At published market rates of $5,000–$30,000 over two to four weeks (MEV, 2026), the audit clears its own cost by preventing roughly three to eight weeks of rework on a 6–10 person team. Your rates will move that range. The shape of it will not.

What audit-first actually means

Audit-first is a time-boxed assessment that establishes what you already own and what it will cost you to touch it, before you commit a roadmap to it.

It is not a discovery phase. Discovery scopes what you intend to build; an audit prices what is already sitting there. It is not a penetration test, though a security workstream usually lives inside it. It is not architecture consulting, which reasons backwards from a target state instead of forwards from the current one.

Where the risk moves: out of unknown-unknowns and into a register with severities, effort estimates and owners. Auditing removes no risk at all. It converts risk into a line item you can argue about with a CFO, which is a different and much more tractable problem.

What build-first actually means

Build-first is a deliberate bet that one thin vertical slice of working software will tell you more about an inherited system than any document review, at a cost you were going to pay anyway.

It is not recklessness and it is not skipping planning. Done properly the first increment is chosen because it exercises what you understand least: the deployment path, the test suite, the auth boundary, at least one integration. You can read the schematic, or you can put current through it. The slice puts current through it.

Where the risk moves: into that first increment, which stops being a feature and becomes an instrument. Small and reversible, the bet is cheap. If the slice is the payments migration, you have not run a diagnostic, you have started the project.

Audit-first vs build-first, head-to-head

The two approaches differ on seven dimensions that can actually change a decision, and the sharpest of them is what you hold at week four: a costed register of everything, or hard evidence about one path.

When audit-first is the right call

Audit-first is the right call in four situations, and in each one the audit is buying something the first increment cannot reach.

Inherited code with no original authors on the team. This is the strongest single trigger, and the cheapest to test. In Avelino et al.'s study of 1,932 projects, 16% had already lost every key developer, and only about 41% of those projects carried on being developed at all. A survey of 269 engineers (Bus Factor in Practice, ICSE-SEIP 2022) found 63% had hit high bus-factor risk in the previous year while only 19% had ever seen it measured on a project they worked on. Everyone knows. Nobody counts.

A vendor handover, where the baseline is your only bargaining position. The moment you ship your first change, every defect afterwards is arguably yours. A documented baseline taken before you touch anything is the difference between a warranty conversation and a shrug.

Pre-transaction or pre-certification, where the finding has a hard date. In an M&A process the assessment is a deliverable in its own right, and it lands inside an exclusivity window you do not control. The same holds for regulated timelines. The EU AI Act moved in 2026, so state it precisely: under the Digital Omnibus, Regulation (EU) 2026/1744, in force 27 July 2026, standalone high-risk Annex III obligations shifted from 2 August 2026 to 2 December 2027, and Annex I product-embedded systems to 2 August 2028. Article 50 transparency duties did not move (2 August 2026), GPAI obligations have applied since 2 August 2025, and the Article 5 prohibitions since 2 February 2025. Separately, DORA, Regulation (EU) 2022/2554, has bound roughly 22,000 financial entities and their critical ICT providers since 17 January 2025. NIS2, SOC 2 Type II, ISO/IEC 27001 and ISO/IEC 42001 all require documented assessment ahead of certification.

Chronic missed delivery where the cause is disputed. When engineering says the estate is unmaintainable and the business says the team is slow, both sides are arguing from anecdote. An assessment settles it with evidence, and it is considerably cheaper than another two quarters of the same meeting.

When it isn't

A small codebase with the authors still present. Under roughly 20,000 lines with an original author on the team, an audit will mostly write down what they already know, and charge you two weeks for the transcription. Book them a whiteboard instead.

Genuine greenfield. There is nothing to assess. Reviewing a specification is a design review, and it is a cheaper, shorter meeting with a different name.

A live production incident. Stabilise, then assess. An audit commissioned during an outage produces a document nobody reads and an invoice nobody wanted.

When build-first is the right call

Build-first is right when the code is recent, the people who wrote it are still reachable, and your binding constraint is the calendar rather than your confidence.

Greenfield or near-greenfield with a stable team. Institutional knowledge sitting in people's heads is fragile and should be written down, but it is not the same risk profile as an orphaned system. Write it down as you go rather than commissioning someone to reconstruct it.

The first increment is small and reversible. If you can ship it behind a flag and roll it back inside an hour, you have a cheap probe. Use it as one, and choose it for what it touches rather than for what it delivers.

The decision the audit would inform is a month away anyway. Commissioning a finding you cannot act on until next quarter buys you an older finding. Time the assessment to the decision, not to the anxiety.

We build first more often than our own positioning implies. On PolyAPI we opened with two developers to validate the core RAG concept rather than to assess it, and scaled to a four-person pod only after the client raised. "The biggest benefit has been time to market," their CEO and co-founder Darko Vukovic told us. An assessment first would have been a well-documented way to arrive later.

When it isn't

Regulated environments. In fintech, insurance, healthcare or GRC the documented assessment is a compliance artefact rather than an engineering preference. Building first does not remove the requirement, it relocates it to a worse moment.

Anything you would rather not explain in a data room. Black Duck's 2026 OSSRA report, covering 947 commercial codebases across 17 industries, found 68% carried open-source licence conflicts, up from 56%, the largest year-on-year move in the study's history. Only 54% of organisations assess AI-generated code for IP and licensing risk at all. One copyleft dependency in a transitive tree can force disclosure of proprietary source, and it will be found by someone eventually. Better it is you.

Nobody can describe the release process. If the path from commit to production cannot be explained in five sentences, your first increment is not a diagnostic. It is an incident with a ticket number.

The third path: audit in parallel

For anything non-trivial, run a time-boxed assessment alongside a thin vertical slice instead of choosing between them.

The slice answers whether the system is safe to change. The assessment prices what the slice will never touch: licence exposure, architectural coupling, key-person concentration, security posture. Running them together turns six weeks of sequential caution into three weeks of concurrent work, and gives you two independent readings on the same system rather than one deep one.

This works when the slice runs through a subsystem you already partly understand. It fails when the slice is the exact thing you are uncertain about, because then you are building on the assumption the assessment exists to test.

What follows is incremental, not a rewrite. Route through a facade, migrate slice by slice, decommission the old path behind you. Martin Fowler's strangler fig is still the pattern of record because every step ships value and every step reverses. Big-bang rewrites suit systems that are genuinely unmaintainable, and most systems described that way are not.

What each approach costs

A scoped technical due diligence runs $5,000–$30,000 over two to four weeks for SMB and mid-market codebases, and $50,000–$250,000 or more over two to six weeks for enterprise and regulated targets.

Ask for a severity-rated issue log, a remediation roadmap carrying effort and cost estimates, an architecture and security assessment, an SBOM with licence analysis, and a bus-factor reading. The engagement should close on a decision record. A PDF is not a decision.

Then there are the line items procurement never sees:

1. Internal stakeholder time. Access, interviews and context consume your architect and your ops lead. Budget 15–20% of one senior person across the window, and more if documentation is thin.
2. Velocity dilution during remediation. Findings arrive as work. The roadmap you approved before the assessment is not the roadmap you hold after it, and nobody rebaselines the quarter.
3. Knowledge transfer on handoff. An assessment run by a party who then leaves gives you a document instead of a capability. Where you can, have it run by the team that will do the remediation.
4. The cost of a decision deferred. Reliably the largest number in the exercise, and the only one that never reaches a spreadsheet.

Running the threshold against your own rates. Left side of the crossover: audit duration multiplied by your blended day rate, plus the value of the work the window postpones. Right side: the share of the codebase you expect to touch, multiplied by the odds it hides something structural, multiplied by what unpicking it costs once you have built on top. For scale on that right side, issues in low-quality code take 124% longer to resolve and show 9 times longer maximum cycle times, measured across 39 proprietary production codebases (Tornhill and Borg, Code Red, 2022). The second figure is the expensive one, because it means your forecasts stop working. On a 6–10 person team, a mid-market assessment clears its own cost by preventing three to eight weeks of that.

What we find when we audit first

The finding is almost never the bug the client called about, which is why the call rarely describes the actual engagement.

No process behind a working product. At ACE Solutions, then 2opus, the presenting problem was one misbehaving application for a major European fintech client. The real finding was structural: no defined development process and no documentation anywhere in the estate. We wrote user and technical guides for every application, moved projects off Mercurial onto Git with enforced GitFlow, standardised configuration and logging, and enforced semantic versioning against the core product. That partnership has run since 2018.

Documentation discipline priced at exit. Custom Charts for Jira, built with Old Street Solutions, scaled past 400,000 users and was ultimately acquired by Tempo. The architecture and documentation work that made it legible to an acquirer was done years before anyone opened a data room. Nobody does that work under deal pressure.

A foundation good enough for AI to accelerate. At Protecht we migrated hundreds of screens to React with AI-assisted workflows, using context engineering, MCP integration, custom personas and human approval gates on every generated artifact, and recorded a 60%+ gain in developer efficiency with feature delivery continuing on a parallel track. That gain was available because a mature codebase, a refined component library and clear migration patterns already existed underneath. Without them the same tooling produces faster garbage.

Red flags in either direction

Five signals predict a bad engagement regardless of which approach you picked, and all five are observable before you sign anything.

The estimate arrives before the questions. A vendor who quotes before asking about your deployment frequency, your test coverage or your dependency tree is pricing a shape rather than your system. The variance reappears as change requests in month three.

Audit scope grows mid-engagement. A fixed-fee assessment that starts requesting extensions was either scoped badly or is being farmed. Agree the deliverable list before the NDA, and agree in advance what happens to findings that fall outside it.

Findings arrive as a raw list. A severity-sorted scanner export is not a roadmap. If the report does not sequence remediation against your delivery plan, you bought data and you still owe someone the analysis.

Build starts before anyone can name the deployment process. Covered above as a build-first disqualifier, and worth repeating as a vendor signal: a partner who begins committing before they can describe your release path is not managing your risk, they are inheriting it silently.

Speed is quoted without a review story. DORA's 2025 report, published 23 September 2025 across roughly 5,000 technology professionals, found AI adoption related positively to throughput and negatively to delivery stability, and framed the mechanism plainly: AI amplifies whatever system it lands in. On an inherited codebase that is a warning, not a benefit. Anyone selling you velocity should be able to describe how the output gets reviewed before it merges.

The decision framework

Four criteria, each with a hard threshold rather than a sliding scale, so the output is a recommendation instead of a qualified maybe.

1. Bus factor. At or below 2 with no documentation, audit. At 3 or above with original authors present, build.
2. External date. Any M&A process, certification cycle or regulatory deadline inside twelve months means audit, and it overrides the other three.
3. Delivery signal. Manual deployment, unknown test coverage and unmeasured change failures mean audit. Deploy on demand with recovery inside a day means build.
4. Provenance. If a material share of the code was AI-generated by people who could not have written it unaided, audit. If your team can explain every subsystem, build.

Whichever way you lean, run the two cheapest activities this week, before the argument is settled: an automated licence and SBOM scan, and a bus-factor computation from your version-control history. Both take hours rather than weeks. Either can force the decision on its own.

Common questions about auditing an inherited codebase

How long does a codebase audit take?

A targeted assessment of one subsystem runs one to two weeks. A full technical due diligence covering architecture, code quality, security, dependencies and team risk runs two to four weeks for mid-market systems and two to six weeks for enterprise or regulated targets. The pacing variable is rarely codebase size. It is access readiness: repositories, CI/CD, cloud accounts and monitoring, agreed under NDA before anyone starts reading.

What does a code audit cost?

Published market rates run $5,000–$30,000 for a two-to-four-week mid-market technical due diligence, and $50,000–$250,000 or more for enterprise confirmatory diligence across two to six weeks. A licence and SBOM scan costs tooling fees and takes hours. Scope the engagement by risk rather than buying full depth across a system where most modules will never be touched.

Can we audit and build at the same time?

Yes, and for anything non-trivial it is what we recommend. Run a time-boxed assessment in parallel with a thin vertical slice that exercises your deployment path, your tests and one integration. The slice tells you whether the system is safe to change; the assessment prices what the slice cannot reach. The approach only holds if the slice avoids the exact subsystem you are most uncertain about.

What access does a vendor need to start?

Read-only access to source repositories, CI/CD pipelines, cloud accounts, databases, monitoring and whatever documentation exists, agreed under NDA before the review opens. Add 30–60 minutes each with your architect, your ops lead and whoever has been on the system longest. Interviews consistently surface operational workarounds and undocumented dependencies that static analysis alone will not find.

When is auditing first a waste of money?

When the codebase sits under roughly 20,000 lines with an original author still on the team, when the work is genuine greenfield, when you are mid-incident, or when no finding will change a decision for another quarter. In those cases the assessment produces a document confirming what someone in the room already knew, and charges you two to four weeks of delivery for it.

How do audit findings turn into a roadmap?

A usable report sequences findings against your delivery plan rather than sorting them by severity alone. Every finding needs an effort estimate, a blast radius, and a note on whether it blocks upcoming roadmap work. Findings that block nothing and cost nothing to defer belong in a backlog, not a remediation plan. If the report skips the sequencing, you bought data and still owe someone the analysis.

Does AI-generated code change the answer?

It moves the threshold toward audit-first. GitClear's 2026 analysis of 623 million changes found duplicated blocks at record highs while refactoring fell to 3.8% of changes, and Veracode's 2025 testing of over 100 models found 45% of generated samples introducing OWASP Top 10 vulnerabilities, with newer models no safer than older ones. Where nobody on the team could have written the code unaided, comprehension bus factor is zero.

Where to start

A scoped assessment gives you a severity-rated issue log, an SBOM with licence analysis, a bus-factor reading and a sequenced remediation estimate, all of it before you commit a single sprint to a system you did not write. Under Proof of Hotovo you pay only if you are satisfied with what you get, which is the risk reversal we would want if the codebase were ours.

If your question is scope and cost rather than risk, check project fit and we will come back with a stack and an estimate. Either way we will say so if the honest answer is to skip the assessment and ship a slice.

Reach us at sales@hotovo.com.