§ OFFER 05 — FIXED SCOPE

Technical Due Diligence for Investors

An independent read on a target's engineering before money moves. Architecture, debt, security posture, and whether the team can hold the plan the deck describes.

Who
Led by the founder, hands-on for the duration.
Timeline
2–3 weeks
Request a call What you get

What you're seeing

The deck describes a platform and the engineering conversation keeps returning to one person.
Usually means Key-person concentration. It is the most common finding that changes a price, and it rarely appears in the materials because the target does not experience it as a risk.
The target's roadmap assumes a hiring rate they have never achieved.
Usually means The plan being underwritten is not the plan the team can deliver. This is checkable against their actual offer-to-start history before anyone signs.
Growth is in the model but nobody has asked what the architecture does at ten times the load.
Usually means The rebuild is usually not the risk — the timing is. A system that has to be re-platformed in month nine of a plan that spends its capital in month six is a financing problem, not an engineering one.
The target sells to enterprise and has no security certification.
Usually means There is a category of deal they cannot currently close, and the model may already assume those deals. It is a scoped cost with a known timeline, which makes it one of the easier findings to price.
You have been given a code quality score from an automated tool.
Usually means It measures something real and it does not answer the question you are asking. Nothing in a static score tells you whether the team can hold the plan.

What you get

Fixed scope. Everything below is in the engagement, not an upsell.

Deliverable What it means
Written report Findings ranked by what they cost and when. Written for an investment committee, with an engineering appendix that survives the target's own CTO reading it.
Architecture assessment How the system is actually put together, where it will bend under the growth the model assumes, and what that bend costs to prevent.
Debt and rebuild estimate What is carried, what is deferred, and the range of engineering months to bring the worst of it back inside tolerance.
Security and compliance posture What would fail a SOC 2 or ISO 27001 audit today, and which enterprise deals that blocks.
Delivery capability read Whether the team ships at the rate the plan needs, from release history and process rather than from interviews alone.
Findings call Ninety minutes with the deal team. Questions answered against the evidence, not the summary.

The capabilities behind it Architecture Review · Technical Debt Assessment · Security Audit · Code Security Review

What the report answers

Three questions, in the order a deal team asks them.

Is the system what the deck says it is? Architecture as built rather than as diagrammed, the data model underneath it, the third-party dependencies the business would not survive losing, and the difference between what is deployed and what is documented.

What does it cost over the horizon being underwritten? Carried debt, the point at which the architecture stops absorbing growth, the infrastructure line as volume rises, and the certifications a stated go-to-market implies. Each with a range and the assumptions behind it written down.

Can this team ship the plan? Reconstructed from release history, incident record and hiring data rather than from interviews alone. A team that has never hired four engineers in a quarter is unlikely to hire eight.

How it differs from a code audit

A code audit reads the code. Diligence reads the code and then asks what it implies about the money.

The distinction shows up most clearly in what gets escalated. A static analyser will rank a class of defect by severity, and severity is not the axis a deal team is deciding on. The finding that moves a price is more often structural and unremarkable-looking: one engineer who is the only person who has deployed the payment path, a data model that makes multi-region a rewrite rather than a configuration, a dependency two versions from end of life on a product sold under enterprise support terms.

None of those are code quality problems. All of them are cost with a date attached.

What we could not verify, and why it is in the report

Two to three weeks is not enough to check everything, and the honest version of a diligence report says which parts were checked.

Every finding is marked by its basis — measured from a system we had access to, reconstructed from history, or asserted by the target and not independently confirmed. Reports that flatten that distinction read as more complete and are less useful, because an assumption presented as a finding gets underwritten with a confidence it has not earned.

Where a target declined access, that is written down too. It is not an accusation. It is a fact about what the buyer is being allowed to see, and it belongs in front of the person deciding.

Where it sits against the rest

If you are the company being assessed rather than the one assessing, the Engineering Audit is the same inspection pointed the other way — bought by you, aimed at fixing what it finds, and written for your own team to act on. Founders preparing for a raise often run one deliberately, on the reasoning that the problems are cheaper to find before somebody else does.

Where the finding is a missing certification blocking enterprise revenue, SOC 2 Readiness is the scoped version of that work, and the diligence report will say roughly what it costs and how long the observation period adds.

How it runs

  1. Access and inventory

    • Repository, cloud and ticketing access under NDA
    • System inventory: services, data stores, third-party dependencies
    • Release history and incident record pulled

  2. Assessment

    • Architecture walkthrough with the target's engineering leadership
    • Code and dependency review, security posture check
    • Delivery metrics reconstructed from the repository

  3. Report and findings call

    • Findings ranked by cost and urgency
    • Rebuild estimate with its assumptions stated
    • Ninety-minute session with the deal team

Total duration

2–3 weeks

Phases

3

Deliverables

6 items

Engagement

standalone

How this is priced

Model

Fixed scope

A fixed fee against a fixed scope, quoted after a short call about the target and the deal timeline. It does not vary with what we find, which is the point — a diligence provider whose fee moves with the findings has an incentive nobody wants in the room.

Fixed The fee, the scope, and the deliverable: a written report with findings ranked by cost and urgency, a rebuild estimate with its assumptions stated, and a ninety-minute findings call with the deal team.

What moves it

  • The size of the estate: services, data stores and third-party dependencies to inventory
  • Whether security and compliance posture is in scope or the deal has a separate provider for it
  • How many engineering interviews the target will grant
  • The turnaround the deal calendar needs, within the limits of the work

Next step

Describe the situation and we'll tell you whether this is the right shape.

Request a call

How we decide

  • The report separates what we measured from what the target asserted

    Costs It makes the document longer and it puts our own coverage gaps in writing, in front of the client.

    Diligence reports tend to read as though everything was checked. A reader deciding on eight figures needs to know which half they are looking at, and an unverified assumption presented as a finding is worse than a blank — it gets acted on with confidence it has not earned.

  • Findings are priced, not scored

    Costs Every estimate carries assumptions, and stating them makes the report easier to argue with.

    A severity rating is not a decision input. What a deal team needs is the range of engineering months, what triggers the spend, and whether it lands before or after the capital does. An estimate you can dispute is more useful than a colour you cannot.

  • We write so the report survives the target's own CTO reading it

    Costs It rules out the rhetorical shortcuts that make a finding land harder in a committee.

    Deals close, and the engineer who wrote the code often becomes someone the buyer now employs. Anything phrased in a way we would not defend to them is a liability the day after signing — and in practice, a finding that survives that test is also the one that holds up under the target's rebuttal.

  • Refused access is reported as a finding, not worked around

    Costs It can put us in the middle of a negotiation between our client and the target.

    There is always a way to infer around a missing repository, and the inference will be presented with more confidence than it deserves. What a target will not show is information about the deal, and it belongs in the report as such.

Diligence, an audit, and a code review

The three get quoted against each other and they answer different questions for different buyers.

Assessment Who buys it The question What comes out
Technical Due Diligence An investor or acquirer, pre-close Is the business worth what the model says, given its engineering? A priced risk register and a rebuild estimate, written for a committee
Engineering Audit The company itself, before a commitment What is slowing us down and what do we fix first? A ranked diagnosis and a ninety-day plan to act on
A code review or static scan Engineering, at any time Is this code well written? A defect and quality report on the code as written
Security assessment or pen test Security, or a customer demanding one Can this be broken into? Exploitable findings, ranked by severity

A scan tells you the code has problems. Diligence tells you what those problems cost, when the cost lands, and whether the team can absorb it while delivering the plan — which is the only version of the question a deal team can act on.

Is this you?

  • Investors underwriting a Series A or B round in a software business
  • Acquirers who need an engineering read before signing
  • Founders preparing for diligence who would rather find the problems first

How we run it

The report names what we could not verify

Diligence reports tend to read as though everything was checked. Ours separates what was measured from what was asserted by the target and left unverified, because a reader deciding on eight figures needs to know which half they are looking at.

Frequently Asked Questions

An independent assessment of a software business's engineering before an investment or acquisition closes. It answers whether the system described in the deck is the system that exists, what it will cost to run and extend over the horizon being underwritten, and whether the team can deliver the plan. The output is a written report for the people making the decision, not a technical document for the target.
Two to three weeks from access being granted. The first week is inventory and access, the second is assessment, the third produces the report and the findings call. Deals that need something faster get a narrower scope rather than a compressed one — we will name what is out of scope rather than skim everything.
Read access to repositories, the cloud console and the issue tracker, plus time with engineering leadership. Where a target will not grant repository access we say so in the report rather than working around it. What a target declines to show is information about the deal.
That is the buyer's call. We write the report so it survives being shown to them: every finding is evidenced, and nothing in it is phrased in a way we would not defend to the engineer who wrote the code. In practice that also makes it more robust when the target responds.
No. The Engineering Audit is bought by the company being assessed and is aimed at fixing what it finds. This is bought by someone on the other side of a transaction and is aimed at pricing risk. Different reader, different report, and the two are not interchangeable even though the underlying inspection overlaps.
Engineering months to bring the worst of the carried debt back inside tolerance, expressed as a range with its assumptions written down — team size, seniority mix, and whether feature work continues in parallel. It is not a quote for us to do the work. It is a number the committee can put against the model.
Yes, and it is common: the findings become a remediation plan under a retainer or a delivery engagement. We say up front when we think that is where it leads, so the incentive is visible rather than buried in a recommendation.

Sources

Page reviewed