What the read is actually for
Technical diligence usually gets commissioned late, scoped as "have someone look at the code," and delivered as a memo with a red-amber-green table. The memo lands in the data room, nobody prices anything off it, and the deal closes on the commercial work. The engineering cost shows up anyway, twelve to eighteen months later, as a roadmap that slipped two quarters and an integration that needed four engineers instead of one. The memo was not wrong. It just was not denominated in anything a deal team could use.
The output of a technical read is a cost model with evidence behind it. Three questions produce that model. Can somebody other than the current team operate this system. Can it absorb the roadmap the deal thesis assumes. Does it cost what the financial model says at the volume the model assumes. Everything else in the workstream exists to answer one of those three with evidence rather than with an interview.
Two framing errors make the work useless before it starts. The first is looking for good code. Every codebase in a company with revenue has debt, and quality in the abstract is not a finding. The question is whether the debt is priced and who pays it. The second is treating the read as a search for a reason to walk away. Most deals close. A read scoped to find a killer produces a document that gets skimmed for the killer, does not find one, and gets filed. A read scoped to produce a number gets used in the negotiation, which is the only place a technical finding has ever changed an outcome.
You are probably here because
- The last technical read you paid for came back as a red-amber-green table, and nobody priced a single line of it.
- You have three weeks, a data room somebody else organized, and no way to tell which parts of it are worth opening.
- You asked for repository access and got a management walkthrough instead.
- A deal you closed two years ago is still absorbing engineers you had budgeted for the roadmap.
The artifact request in the next section and the table further down on turning findings into deal terms address all of it, and these usually share one root cause: the read was never denominated in money, so there was nothing in it anybody could negotiate.
Scope the read before the data room opens
The seller controls the data room. What arrives is what someone chose to upload, organized the way it was convenient to organize. So send a written artifact request early, with named items, and treat the response as data. What does not arrive, and the reason given, is a finding of its own.
- Read-only access to the source repositories with full history, not a zip of the current tree
- CI configuration and the last ninety days of build results, including failures
- Twelve months of cloud spend at line-item granularity, not the summary invoice
- A resource inventory of what is actually running, alongside whatever architecture diagram exists
- Every third-party service with its contract, renewal date and annual cost
- Dependency manifests and lockfiles for every deployable artifact
- Twenty-four months of incident records with timestamps, duration and customer impact
- The on-call schedule and paging volume from the alerting system itself
- The last two penetration tests and the remediation status of every finding
- The full SOC 2 or ISO 27001 report, including scope and the exceptions section, plus any bridge letter
- Data processing agreements and the current subprocessor list, plus any customer contract with security terms negotiated into it
- IP assignment agreements covering every person who wrote code, employees and contractors both
- A list of customer-specific code paths, branches, flags or configuration
Sellers push back on repository access, and at an early stage that is sometimes reasonable, particularly if the buyer is a competitor. There are workable answers: a clean-team arrangement where named individuals under a separate confidentiality regime get access and report conclusions rather than content, or an independent third party who runs the measurements and hands over findings without transferring code. What is not workable is a diligence process that never sees the code and still prices the engineering. If access is refused outright while the deal is under exclusivity, that is information about how the rest of integration will go.
The clone-to-running test
Nothing else in week one produces this much signal per hour. Take one engineer who has never seen the system, a clean machine, and the README. Time how long it takes to reach a running local instance with a seeded database and a passing test suite. Write down every step that was not in the documentation.
Under four hours means the team has onboarded somebody recently and the setup path is exercised. A day or two is normal for a system with real infrastructure dependencies, and the gap list is the useful output. If it cannot be done at all without a specific engineer joining to fix it live, that engineer has just become a deal term, and the onboarding cost for every future hire is now measurable rather than assumed.
Extend the test twice. Build the deployable artifact from a clean checkout, twice, and compare. If two builds of the same commit produce materially different artifacts, the build depends on something nobody has pinned. Then deploy that artifact to a scratch environment created from configuration. If a new environment can only be produced by hand, then every environment in the company is a one-off, the disaster recovery plan is aspirational, and standing up an isolated environment after close is a project rather than a command.
Reading a repository you will not read
Nobody reads four hundred thousand lines in three weeks, and nobody needs to. Measure the repository, then read the twenty files the measurements point at.
Ownership concentration. Walk the last twenty-four months of history, attribute surviving lines per file, and compute each author's share by component. Any component where one person owns more than about seventy percent of surviving lines is a concentration finding. If that person is staying, it is a retention question. If they left last year, it is an unowned component, and the first change anybody makes to it will cost several times what the roadmap assumes.
Churn hotspots. Rank files by change frequency over twelve months, then intersect with size. Files that are both large and constantly edited are where next year's defects come from and where roadmap work will run slow. That intersection is usually ten to thirty files, and those are the ones worth actually reading.
Test suite honesty. Coverage percentage on its own means very little. Three questions do better. Does CI block a merge when a test fails, or is red the normal state of the main branch. How many tests are currently skipped, and what is the commit date on the skip. And does the suite assert on behavior or on snapshots that were regenerated the last time they broke. The cheap experiment: delete a line of production logic at random in a core module and run the suite. If it passes, the number on the coverage badge is measuring execution, not verification.
Release mechanics. Look at commit cadence around releases. A cluster of direct-to-main commits in the hours after every release means the release process does not work and the team compensates by hand. That is not a code quality problem. It is an operational cost that repeats every release.
Dead code. Endpoints nobody calls and modules nothing reaches still get read, tested, patched and migrated. Production coverage or route hit counts will size it in a day. It is common to find a quarter of a codebase that has not executed in a year, and removing it is one of the few first-year wins that is safe to promise.
How Much We Trust Each Source
Weighting we apply when two sources disagree. Systems that emit their own record outrank documents written about them.
Dependencies, licenses and end of life
Generate a software bill of materials rather than trusting the manifest. Syft or cdxgen will produce CycloneDX or SPDX output from the built artifacts, and Trivy, grype or osv-scanner will resolve that against known vulnerabilities. Run it against the container image, not the source tree, because the image is what ships and it contains an operating system nobody has thought about in two years.
Three classes of finding carry money. Runtimes past end of support are a dated remediation project, not a preference. CentOS 7 reached end of life on 30 June 2024, Python 2 on 1 January 2020, and each Node.js LTS line is maintained for roughly thirty months from release. A customer contract that requires supported software turns an unpatched base image into a breach of contract rather than a backlog item.
Copyleft in a hosted product is the finding most likely to involve outside counsel. GPL-family obligations attach on distribution, and AGPL section 13 extends the source-provision obligation to users who interact with the software over a network, which is exactly the shape of every hosted product. One transitive AGPL dependency deep in a build is not fatal, but the resolution is replacement or compliance, and both take time you would rather not spend after close.
Abandoned packages matter more than vulnerable ones, because vulnerable and maintained is a patch while abandoned is a migration. Sort direct dependencies by last release date and maintainer count. A package with one maintainer and no release in three years is a project you will schedule at the least convenient possible moment.
Secrets, keys and what rotation costs after close
Scan the full history, not the current tree. Gitleaks and TruffleHog both walk every commit, and a credential deleted in a later commit is still in the history and still valid unless somebody rotated it. Assume nobody did. The finding is not that a key leaked once. It is that the company has no process that notices, which means the next one will sit there too.
Then build the credential inventory, and pay attention to the entries outside the cloud console. Domain registrar. DNS. Certificate issuance. The email domain and its DMARC records. App store publisher accounts. The payment processor. These get missed because they are held by whoever set them up years ago, and they are the highest-leverage credentials in the company. If the registrar login belongs to a founder who is not staying, that is a closing condition, not a to-do.
Post-close rotation is real work. Every credential rotated, every service account re-keyed, every departing person's access removed and the removal proven. Two weeks of one engineer is a fair planning figure for a small estate. It runs longer where credentials are hard-coded into client-side configuration that customers hold, because then rotation is a coordinated release with people outside the company.
What a SOC 2 report does and does not tell you
Two pages carry most of the information. The scope section names which trust services criteria were in scope and which systems were covered, and it is common for the covered system to be narrower than the product a customer thinks they bought. The exceptions section names what the auditor found. A Type 2 report over twelve months with zero exceptions usually means narrow scope rather than flawless operation. Check the period end date as well: if it closed seven months ago, the only thing covering the gap is a bridge letter, which is management's own assertion and is not audited. And a clean report says the controls management described operated as described. It is not a statement that the product is secure, and it is not a substitute for the penetration test remediation list.
Unit economics: read the bill, not the diagram
The architecture diagram shows what somebody meant to build. The bill shows what is running. Pull twelve months of line-item cost data and allocate it to compute, storage, egress, managed data services, third-party APIs, observability, and the long tail of services nobody remembers buying. Then divide by whatever unit the revenue model uses: active customer, transaction, seat, document processed.
Trend that unit cost against usage. If cost is flat while usage rises, either the system is over-provisioned, which is recoverable and is a first-year win, or fixed cost dominates and the margin story only works at a scale the company has not reached. Those two look identical on a summary invoice and completely different at line-item granularity.
The recurring finds are consistent across deals. Non-production environments running around the clock. Unattached storage volumes and snapshot archives going back years. Cross-region data transfer that exists because a service was moved and something was not. Observability spend that scales with log volume rather than with anything anyone looks at. And committed-use discounts with an expiry date inside the hold period, which is a liability that transfers at close and belongs in the model rather than in the appendix.
One caution on this section, because it is the one that gets over-promised. Cost work that is configuration is fast and safe to commit to. Cost work that requires re-architecture is an integration project competing with the roadmap, and it belongs in the integration plan, not in the first-year synergy line.
Planning Default — First-Year Post-Close Engineering Hours
Starting allocation summing to 100, before findings. Diligence exists to replace these defaults with measured numbers.
Multi-tenancy and the per-customer fork
Most deal theses assume one product serving every customer. Test it. Count the feature flags that have been permanently on for exactly one account, the branches named after a customer, the configuration files with a customer name in them, and the data migrations described internally as temporary. Then ask how many customers are running code paths no other customer runs.
Ten customer-specific variants do not cost ten times a single product. They cost more, because every future change has to be evaluated against each variant, and the evaluation is manual. That is the mechanism by which a two-day change becomes a six-week release, and it is the single most common reason an integration timeline doubles after close.
Isolation is the other half of this. Ask how tenant separation is enforced: an application-layer filter, a schema per tenant, a database per tenant, or a deployment per tenant. Application-layer filtering with no constraint at the database is one missing predicate away from cross-tenant exposure, and that is not only an engineering finding. Under GDPR Article 33 a personal data breach carries a seventy-two hour notification clock, and most enterprise customer contracts carry their own notification terms on top. Ask whether that specific failure mode has ever happened, and ask the question in a way that makes the answer checkable against the incident record.
The incident record is the most honest document in the room
Request twenty-four months of incidents with timestamps, duration, customer impact and postmortems, and separately request the paging export from the alerting system. Compare them. A log with six entries against four hundred pages is not an incident log, it is a communications artifact, and everything else the team has written about reliability should be re-read in that light.
Three things to read for. Repeated root causes in the same subsystem, three or more times, are an architectural finding rather than an operational one, and they will not be fixed by better process. The gap between time to detect and time to resolve tells you whether the problem is observability or design, and observability is much cheaper to fix. And postmortem action items with no completion date, or dates that have passed, tell you what happens to work that nobody is measured on.
On-call load predicts retention better than compensation does. A rotation of two people is not a rotation, it is two people who are always on call, and it is a common reason the engineer you planned to retain resigns in month four. Get the page counts by person and by hour of day. Night pages concentrated on one name is a finding with a name attached to it.
Send it over and we will tell you what we would change.
Email the artifact request you sent the seller, the list of what has actually come back so far, and twelve months of the cloud bill at line-item granularity to contact@precisionfederal.com. You get back a short written note naming the three things we would change and why. One business day. No charge, no meeting, no deck.
contact@precisionfederal.comKey people, and what a retention agreement actually buys
The ownership measurement from the repository gives you bus factor per component. Map it to names, then map the names to their economics. An engineer whose equity vests at close and whose payout clears their mortgage is a flight risk whatever the retention agreement says, and the correct response is to plan for the departure rather than to price the agreement as certainty.
Retention buys time, not knowledge, and the time gets wasted more often than not on documentation sprints. Documentation written to be handed over is written to a reader nobody has met and gets read once. Documentation produced while an acquirer engineer and a retained engineer ship real changes together is used the same week it is written. Structure the retention period around joint work on the roadmap, with the acquirer engineer holding the pen, and measure transfer by who can run the release without help.
Then close the IP question. Every contributor needs a signed assignment, employees and contractors both, and the contractor agreements are where gaps live. A core module written by a contractor under an agreement with no assignment clause is a cleanup item that costs very little to find before close and a great deal to negotiate after.
Compliance evidence, checked rather than accepted
Attestations are claims until somebody opens them. Four checks cover most of what matters commercially. Read the SOC 2 or ISO 27001 scope and exceptions rather than the logo on the website. Confirm that GDPR Article 28 processor terms are in place with every subprocessor, that the published subprocessor list matches what is actually running in the cloud account, and that a transfer mechanism exists for anything leaving the EEA. If the target processes protected health information, verify that business associate agreements run downstream to every vendor that touches it, because a gap between customer-facing and vendor-facing agreements is a finding with a defined remediation cost. And if cards are in scope, establish whether the target attests through a self-assessment questionnaire or a full report on compliance, and which questionnaire, since PCI DSS v4.0 moved a set of previously future-dated requirements into force on 31 March 2025.
Each of these ends up in the same place: a closing condition, a specific indemnity, or a line in the remediation budget. None of them belongs in a memo as an observation.
Turning findings into deal terms
| Finding | Instrument | Why that one |
|---|---|---|
| Unsupported runtime under a customer security obligation | Priced remediation, funded from a holdback with a completion date | The work is known and datable, so it should be scheduled and paid for, not carried as risk |
| Live credentials in repository history | Closing condition: rotate and evidence before funds move | Cheap to fix, and impossible to prove was fixed once everyone has left |
| One engineer owns a component with no second reader | Retention agreement with named transfer deliverables, tied to a holdback | Retention alone buys presence; the deliverables buy the transfer |
| Copyleft dependency in a hosted product | Legal opinion pre-close, specific indemnity if it cannot be resolved | The exposure is legal, unbounded and not fixable by engineering alone |
| Customer-specific forks across the base | Reforecast the integration schedule in the model | This is a plan change, not a risk register line, and it moves the synergy dates |
| Unit cost that does not fall with volume | Adjust gross margin before the price is agreed | It is a valuation input, and it is the finding most often discovered too late |
| Attestation scope narrower than the customer base assumes | Closing condition or price adjustment, with renewal risk noted per account | Enterprise renewals turn on the scope statement, not the badge |
The instrument is the part that matters. A finding written as a risk gets read once and filed. The same finding written as a dollar amount, an owner and a completion date gets negotiated, and negotiated findings are the ones that actually get fixed. Write the memo in the language of the deal documents and it will survive contact with the deal.
A three-week workstream that fits a deal calendar
Diligence Sprint
Three weeks is enough because the expensive unknowns are all measurable inside it, and the schedule only slips for one reason: access. Ask for provisioning in the first hour and escalate on day two, because every day of delay comes out of the measurement window and not out of the deadline.
The management sessions go last deliberately. Walking in cold produces a presentation. Walking in having already measured the ownership concentration, the unit cost curve and the paging volume produces a conversation where you ask questions you know the answer to. How a team responds when the number in front of them is unflattering is itself one of the more predictive findings in the whole exercise, and it cannot be obtained any other way.
Where Three Weeks of Effort Goes
Effort split on a mid-market software target. Measurement outweighs conversation by roughly nine to one.
Findings that have never once turned out to be benign
- A build that succeeds only on one engineer's machine, with no CI job producing the deployed artifact.
- An incident log with fewer entries than the alerting system has pages for the same period.
- Repository access still refused under exclusivity, with an executed confidentiality agreement in place.
- A staging environment holding a copy of production data with no masking and broader access than production.
- Credentials in git history that nobody has rotated since the day they were committed.
- Feature flags named after customers that have been permanently on for more than a year.
- Tests skipped in CI as a temporary measure, with a commit date older than six months.
- Cloud organization root credentials held by one person who is not staying past close.
- A dependency lockfile that is not committed, so no two installs resolve to the same versions.
What a good answer sounds like
The tell is specificity about weakness. A team that says the architecture scales well has not measured it. A team that says they run at forty percent CPU at peak on the API tier, have load tested to three times current volume and can show the run, and know the next bottleneck is the primary write path, which is why sharding sits in the third quarter of the roadmap, has measured all of it. The second answer contains a limitation, a number and a plan, and it is worth more than any reassurance.
The same holds for debt. A target that hands over a written, ranked technical debt list with rough costs against each item is telling you the engineering organization has been managed rather than merely staffed, and that is a genuine upward adjustment worth stating in the memo. Almost nobody writes the positive findings down. Do it anyway, because a report containing only problems reads as an advocacy document and gets discounted as one.
Common objections
Our own engineers can do this
They should be in the room, and they should own the integration question, because they are the ones who will live with the answer. Two problems argue against them owning the whole read. They are already committed to delivery, so the work happens in gaps and slips. And they will inherit the system, which pulls them toward being either too generous, because they want the deal, or too harsh, because they do not. An independent read handles the measurement, the acquirer's engineers handle the fit.
The deal is too small to justify a full workstream
Then scale it down rather than skipping it. One week of one engineer gets you clone-to-running, the repository measurement, the dependency and secrets scan, and the cloud bill allocation. That is most of the evidence and a large share of the findings that move price. What you lose is depth on compliance and incident history, so state that limitation in the memo rather than leaving the reader to assume coverage.
The seller says the code is fine and the numbers are audited
Financial audit and technical diligence do not overlap. An audit confirms the revenue was recognized correctly. It says nothing about the cost of serving that revenue next year, whether the roadmap the price assumes is buildable by the team that remains, or whether an unsupported base image is about to fail a customer's own security review at renewal. Those are engineering questions with financial answers, and they are the only reason the workstream exists.
Bottom line
Technical due diligence is not a code review and it is not a security scan. It is a cost model with evidence under it. Do the measurable work first, because clone-to-running, repository history, the cloud bill and the paging export are cheap, they cannot be spun, and they tell you exactly which questions are worth asking a human. Read only what the measurements point at. Then write every finding as a number, an owner and a date, in the language the deal documents already use. A memo written that way changes the price or the plan. A memo written any other way gets filed, and the cost turns up later at full price.
Frequently asked questions
Three weeks for a mid-market software target, with the schedule driven almost entirely by how quickly access is granted. A compressed one-week version covers the build, the repository measurement, dependency and secrets scanning, and the cloud bill. Anything shorter is an opinion with a cover page.
Read-only repository access with full history, CI results, twelve months of line-item cloud spend, a running-resource inventory, dependency lockfiles, twenty-four months of incidents plus the paging export, penetration tests with remediation status, the full compliance report including exceptions, subprocessor and data processing agreements, IP assignments for every contributor, and a list of customer-specific code paths. What does not arrive is itself a finding.
Partially, and it should be labeled as partial. The cloud bill, incident and paging records, compliance reports and contracts still produce real findings. What you cannot get is ownership concentration, test suite honesty, dependency and license exposure, or secrets in history, which is where a large share of priced findings come from. A clean-team arrangement or an independent reviewer who reports conclusions without transferring code usually resolves the objection.
Unit cost that does not improve with volume, because it moves gross margin rather than the risk register. Close behind it are customer-specific forks, which move the integration schedule, and ownership concentration on a component whose owner is leaving, which moves the cost of every roadmap item that touches it.
A findings register where each row carries evidence, a cost or schedule impact, a proposed instrument such as a price adjustment, closing condition, holdback or indemnity, and a named owner. A three-year cost model with the assumptions written down. And a short list of what could not be verified and why, so the reader knows the boundary of the work.