You're about to buy a company whose value is its software. The financials check out, the customers are real, and the founder is credible. What you don't know — what nobody on the deal team can tell you — is whether the thing you're buying is an asset that keeps producing or a liability that needs a rebuild the day after close. You have two weeks of diligence access and a price that assumes the former.
The fork: trust the demo and the deck and price the deal on revenue alone, or send a technical team in to find out what you're actually buying before the wire goes out. The first path is how acquirers inherit a rewrite they didn't budget for. The second is a two-week investment that routinely changes the number.
The stakes
In a software-driven acquisition, the code is the asset, and an asset you haven't inspected is a guess. The downside is concrete: you close, integrate, and discover in the first quarter that the platform can't carry the roadmap that justified the price, that the security posture is a breach waiting to happen, or that the entire system lives in the head of one engineer who's now vested and looking at the door.
The cost of that miss is the rebuild — typically $150k–$300k and six to eighteen months for a system of any real complexity — plus the opportunity cost of a team that's remediating instead of building, plus, in the worst case, a breach or outage that lands on your reputation now that it's your software. None of that was in the model. All of it was findable in two weeks.
A technical audit is the cheapest insurance in the deal. It either confirms the thesis and lets you close with confidence, or it surfaces a finding that moves the price, the escrow, or the structure — and either outcome is worth far more than the audit costs.
The audit framework
A real codebase audit covers five domains. Each answers a specific question about what it costs to own this after you buy it.
Architecture. Can this system carry the load the deal assumes, and can it evolve into the roadmap you're paying for? You're looking at the data model, the single points of failure, the seams (or absence of them), what happens at 10x scale, and whether the architecture supports the product direction in the thesis or contradicts it. The deal-relevant question is not "is this elegant" — it's "does this need a rebuild to do what we're buying it to do."
Security. Secrets in git history, how authentication and authorization actually work, data encryption at rest and in transit, dependency vulnerabilities, access controls, and whether there's any history of incidents. The git-history secret scan takes minutes and finds credentials the seller forgot they committed. In a regulated or data-sensitive domain, the security findings can be the whole deal.
Scalability and reliability. How does it behave under real load, how do they know when it breaks, how fast do they recover, and what's the incident history. A system with no monitoring isn't necessarily broken — but it means nobody actually knows how reliable it is, including the seller, and you're buying that uncertainty.
Team and key-person risk. Who wrote this, who understands it, and what happens if they leave after close. This is where many software acquisitions quietly fail. If the system runs on the knowledge of one or two people and that knowledge isn't written down, you're not buying a system — you're buying a retention problem, and the audit needs to surface exactly which people are load-bearing.
Documentation and operability. Can a team that didn't build this run it, extend it, and onboard onto it? Architecture docs, runbooks, a coherent migration history, a README that means something. Documentation isn't a nicety in an acquisition — it's the difference between an integration that takes a quarter and one that takes a year.
The deal-killers
Most findings are negotiable — they adjust the price or the escrow. A few are different. These are the ones that should make you reconsider the deal itself, not just the number.
Clouded IP ownership. Contractors who didn't assign their work, an open-source component under a copyleft license used in a way that triggers its terms, code of unclear provenance. If you can't establish a clean chain of ownership for the asset you're buying, the asset isn't fully yours, and no price adjustment fixes that. This is the first thing to check and the fastest to kill a deal.
An architecture that can't support the thesis. If the reason you're buying is a roadmap the current system fundamentally can't carry without a ground-up rebuild, you're not buying a head start — you're buying a customer list and a rewrite, and you should price it as exactly that or walk.
Tenant data with no isolation, in a multi-customer product. A system that mixed every customer's data without a real isolation boundary is one query bug away from a cross-tenant breach. Retrofitting isolation across a populated production schema is a major project, and until it's done, you're carrying breach risk you can't fully mitigate.
Single-person dependency with zero documentation. A system that exactly one human understands, with nothing written down, where that human is about to vest and leave. You can sometimes solve this with retention terms — but if the person won't stay and the knowledge isn't extractable in time, you may be buying something you can't operate.
The pattern: deal-killers are the findings that can't be converted into a price adjustment because they cloud whether you can own, operate, or scale the thing at all. Everything else is a negotiation.
How we'd run it in two weeks
With two weeks and read access, you sequence for the deal-killers first. Day one is ownership and security scans — license audit, git-history secret scan, dependency vulnerabilities — because these are fast, automatable, and the most likely to surface something that ends the conversation before you spend the rest of the window.
The first week is the map: read the architecture as it actually runs, interview the engineers, trace the critical paths, and locate the single points of failure and the key-person dependencies. The second week is depth on whatever the first week flagged — the schema that worried you, the auth system that looked hand-rolled, the scale question the thesis hinges on — and the assembly of the report.
Throughout, you're calibrating to the deal, not to perfection. A two-year-old startup's codebase will have debt; that's normal and priceable. The audit's job is to separate the normal, expected, negotiable debt from the structural facts that change whether you buy and at what number. An auditor who flags everything equally is as useless as one who flags nothing.
We've run exactly this kind of structural read on live systems where the question was whether the code was an asset or a liability — see the Legacy Rescue engagement for what it looks like when the answer is the hard one.
The report that sets the price
The deliverable is not a list of every imperfection. It's a decision document for the deal team, and it has a specific shape.
It opens with a verdict: asset, asset-with-remediation, or liability — and the one-paragraph reason. Then the findings, ranked not by technical severity but by deal impact — what each one costs to fix, how long it takes, and whether it adjusts the price, the escrow, the structure, or the go/no-go. The deal-killers, if any, are at the top, stated plainly. The normal, expected debt is named and explicitly set aside as priced-in, so nobody mistakes ordinary startup debt for a problem.
The most useful section is the remediation estimate: for every material finding, what it costs to fix in dollars and months post-close. That's the number that feeds directly into the deal — into a price reduction, an escrow holdback sized to the remediation, or an earnout that keeps the founding engineer accountable through the fixes. A finding without a cost is gossip. A finding with a credible cost is a negotiating position.
The failure mode of the audit report is the 200-item findings dump with no prioritization and no dollar figures — technically thorough, commercially useless, because the deal team can't tell which three findings matter and which 197 are noise. The report has to do the triage, or it hasn't done its job.
What fixed looks like
You go into the close knowing what you're buying. The audit either confirms the thesis — the architecture carries the roadmap, the IP is clean, the security is sound, the system is operable by a team that didn't build it — and you close with confidence at the negotiated number. Or it surfaces something real, with a dollar cost and a timeline attached, and you adjust the price, size the escrow to the remediation, or structure an earnout around the fixes.
Either way, there are no first-quarter surprises. You don't discover the rewrite after the wire clears. The remediation work, if any, is budgeted, scoped, and reflected in the deal terms instead of landing as an unfunded emergency on a team that's supposed to be integrating, not rebuilding. The code was an asset or a liability before you signed — and you knew which.
This is for you if
You're an acquirer, a PE firm, or a strategic buyer about to purchase a company whose core value is its software, with a window of diligence access and a price that assumes the code is sound. You want to know whether you're buying an asset or a liability before the wire goes out.
A pre-acquisition codebase audit runs $50k+ and scales with the size and complexity of the target — for a substantial platform with a real integration thesis, $100k+: we run the full framework — architecture, security, scalability, team and key-person risk, documentation — surface the deal-killers first, attach a dollar-and-timeline remediation cost to every material finding, and deliver a report your deal team can price against and your lawyers can structure around.
This is not for an acqui-hire where you're buying the team and discarding the code — the audit there is about people, not architecture. It's not for a tiny, simple system where the risk is immaterial to the deal. It's for the acquisition where the software is the asset, the price assumes it works, and the two weeks before close are your only chance to find out cheaply whether that assumption holds.