A term sheet lands. Somewhere in the next 30 to 60 days, three or four engineers you've never met get read-only access to your repos, your cloud console, and your incident history. What they write in their report adjusts the price. Sometimes by a little. Sometimes it moves a holdback, an earnout, or a "we're going to need to think about this."
The fork you're on: you can spend the next two months making the system tell the story you want it to tell, or you can let it tell the story it currently tells, which — if you're like most companies at this stage — is messier than the pitch deck.
The stakes
Acquisition diligence is not a pass/fail gate. It's a pricing input. A clean technical diligence rarely raises the number. A bad one almost always lowers it — through a renegotiated multiple, a larger escrow, a longer earnout, or key-person retention terms that tie your founding engineer to a desk for two years.
The math is unsentimental. If the acquirer's team finds that the core platform needs a rebuild to support the roadmap that justified the price, they don't walk — they reprice. A finding that reads "12–18 months of remediation, two senior engineers" translates directly into a deduction, because that's labor the acquirer now has to fund post-close. On a deal where the software is the asset, a single load-bearing finding can move the number by a meaningful fraction of enterprise value.
And the cruelest part: most of what they find is fixable in the 60 days before they arrive. You're not being penalized for hard problems. You're being penalized for not having tidied up the easy ones.
What acquirers actually inspect
The diligence team is not grading your code for elegance. They're answering one question for their investment committee: what does it cost to own this after we buy it. That question breaks into a handful of domains.
Ownership and provenance. Who wrote this, and do you have the right to sell it? They check the contributor history, the contractor agreements, the open-source licenses in your dependency tree. A copyleft license (GPL, AGPL) buried in a transitive dependency, used in a way that triggers its terms, is a genuine deal problem — not because the code is bad, but because it clouds what the acquirer is buying. They run a license scan in the first afternoon.
Security posture. Secrets in git history, credentials in plaintext config, no secret rotation, dependencies with known CVEs, an auth system someone hand-rolled. The git-history secret scan takes about a minute with the right tooling and finds the AWS key your second engineer committed in 2023 and "removed" in the next commit. It's still in the history. They will find it.
Architecture and scale headroom. Can this system carry the load the deal model assumes? They're looking for single points of failure, a schema that can't be migrated without downtime, a monolith with no seams, synchronous calls where there should be queues. They don't want microservices. They want evidence that someone understood the load curve.
Operability. Can a team that didn't build this run it? Deployment pipeline, monitoring, alerting, runbooks, incident history. "How do you know when it's down?" is a real question, and "a customer emails us" is a real answer that costs you.
Key-person risk. One engineer who holds the whole system in their head, no documentation, no second person who can deploy. To you that's normal. To an acquirer it's a liability they have to retain at a premium or replace at a risk.
The cleanup that moves valuation
Here's what's worth doing in the runway you have, in rough order of return-on-effort.
Purge secrets from history. This is the single highest-leverage hour you'll spend. Rotate every credential that was ever committed, then rewrite history or migrate to a clean repo so the scan comes back empty. A clean secret scan doesn't impress anyone. A dirty one makes them ask what else you don't know about — and that question is expensive, because now they discount for unknown risk, which is always priced higher than known risk.
Write the architecture document that matches reality. Not the aspirational diagram. The real one: what calls what, where the data lives, where the bottlenecks are, what you'd do differently. A diligence engineer who can read an honest, accurate architecture doc onboards in a day instead of reverse-engineering for a week — and reverse-engineering is where they find the things you'd rather they didn't, in the worst possible framing.
Resolve the licensing. Run the dependency license scan yourself. Find the AGPL package, the unvendored snippet copied from a forum, the contractor whose agreement didn't assign IP. Fix these before someone else finds them, because licensing findings don't get negotiated down — they get escrowed.
Add tests to the critical path. You don't need 80% coverage. You need the payment flow, the auth flow, and the core value-delivery mechanism covered well enough that the diligence team sees the most important code in the company is protected against regression. Coverage on the critical path signals discipline. Zero coverage on the path that makes the money signals the opposite.
Stand up basic observability. Structured logs, an error tracker, alerting on the few signals that matter. If you genuinely can't add real monitoring in 60 days, at minimum produce an honest incident history. "Here's every outage in the last year and how we resolved it" is a far better artifact than a shrug.
The things you can't fake
Some findings can't be cleaned up in 60 days, and pretending otherwise is worse than disclosing.
A schema that mixed multi-tenant data without isolation from day one is a structural fact. A monolith with no internal boundaries doesn't grow seams in two months. A four-year migration history that reads like it was designed sprint-by-sprint tells a story you can't retroactively edit.
For these, the move is not concealment — it's framing and a credible plan. Diligence teams have seen everything. What unnerves them is a team that doesn't know about their own load-bearing problems. A team that says "yes, the tenant isolation is application-level, here's the migration plan, here's the estimate, here's why it hasn't been the priority yet" reads as in control. A team that gets surprised by the finding reads as not.
Honesty here is strategic, not just ethical. The acquirer is pricing risk. Known, owned, planned risk prices lower than risk they had to discover. The worst outcome isn't a bad finding — it's a bad finding the seller clearly didn't know about.
How we'd decide what's worth fixing
With 60 days and a finite team, you triage like a diligence engineer would. For each candidate fix, two questions: will they find it, and what does it cost the deal if they do.
Secrets in history: they will find it, it's cheap to fix, and it poisons their read of everything else. Do it first. License problems: they will find it, fixing it is moderate effort, and the cost of not fixing it is escrow. Do it. Critical-path tests and an honest architecture doc: high signal, moderate effort, and they shape the entire narrative. Do them.
A full schema migration for tenant isolation: real, but not finishable in the window, and they'll find it regardless. Don't start a rebuild you can't finish — write the plan and the estimate, and let the framing do the work. A cosmetic refactor of a stable, ugly module nobody asked about: skip it entirely. It costs you days and changes no one's price.
The failure mode
The classic mistake is the panic rewrite. The term sheet arrives, someone decides the codebase is "embarrassing," and the team launches a two-month cleanup sprint that touches everything. Now you've introduced fresh bugs into a system the acquirer is about to inspect under load, your git history shows a frantic burst of activity that itself raises questions, and the founding engineer is too deep in refactoring to answer diligence questions cleanly.
The other failure mode is the opposite: doing nothing, assuming the relationship and the deck will carry it, and letting the diligence team discover every problem cold, in the framing least favorable to you. Both fail. One through frantic motion, one through neglect.
What fixed looks like
The diligence team gets access and finds a system that tells a coherent story. The secret scan comes back clean. The license report is resolved and documented. There's an architecture doc that matches what they see in the code, so they spend their two weeks confirming rather than excavating. The critical paths have tests. There's an incident history and at least basic alerting.
The hard structural items — the ones that can't be fixed in 60 days — are disclosed up front, with a plan and an estimate, so the acquirer prices known quantities instead of discounting for fear of the unknown.
The diligence report comes back as a list of manageable, expected findings rather than surprises. The price holds. The escrow stays small. Your founding engineer's retention terms are about retention, not hostage-taking. The deal closes on the number you negotiated, not a number the technical team backed into.
This is for you if
You have a signed or imminent term sheet, the software is a material part of what's being bought, and you have 30 to 90 days before the acquirer's technical team arrives. You want the diligence to confirm the thesis, not erode the price.
An acquisition-readiness engagement runs $50k+: we run the same scans the acquirer's team will run — secrets, licenses, architecture, critical-path coverage, operability — and hand you a prioritized remediation plan with what to fix, what to disclose, and how to frame what you can't fix in time. We do the high-leverage cleanup with you and prepare the artifacts diligence will ask for.
This is not for companies a year out from any process — readiness has a shelf life, and prep done too early goes stale. It's not for asset sales where the software is incidental to the value. It's for the founder holding a term sheet, knowing the technical diligence is the part of the deal they're least prepared to defend.