Will you tell us whether to do the deal?

No, and you should be wary of anyone who will. We give you findings with severity, a remediation table in developer-months and dollars, and a red-flag list ranked by money at risk. Price and decision are yours — our job is to make sure neither is made blind.

What if the seller will not give us code access?

Read-only access through the data room is normal and enough. Where something is refused or simply absent, it is written into the report as not provided, named as a question for the seller, and never filled in with an estimate. A hole you can see is safer than a number we guessed.

Does this replace a security audit?

No. We run dependency and static analysis, check licences, and report what those tools and the interviews surface. We will never write that a system is secure — that is a separate discipline with its own testing regime and its own insurance, and the sentence is not ours to write.

Does a bigger codebase cost more?

Not really. The price tracks the size of the deal, because that is what sets the cost of being wrong. A modest transaction and a very large one involve roughly the same work on our side and entirely different consequences, and the fee reflects the risk being carried.

Can it be done in a week?

Rarely, and the constraint is not the code. It is data-room access and getting two to four engineers into interviews around their existing work. Two to six weeks is the honest range, and a compressed timeline is quoted with a surcharge stated up front.

What do you find that the financials never show?

Concentration, most often. Git history shows which systems have had one contributor for the last six months long before anyone admits it in an interview, and that single fact usually moves the year-one cost more than anything in the code itself.

Consulting, Product & Talent

Technical due diligence

The code, the team, the infrastructure and the risk read from the inside, and every finding converted into what it costs in year one.

From: $3,000–$30,000
Typical time: 2–6 weeks
Usually bought by: VCs, acquirers

What this actually solves

The accountant has been through the numbers and the numbers are fine. That is exactly the problem, because in a software company the numbers do not hold the risk. The risk sits in places a financial model cannot reach — a system that only exists properly inside one person's head, and that person is planning to leave the day the deal closes. A library buried three levels deep whose licence would oblige you to publish your own source. A cloud bill that will not survive next year's volume, because the current architecture only works at the current one.

What you need is not a technical opinion. It is a number: how much additional money and time does this thing need in the first year after the deal. Without that number there is no basis for negotiating price, no basis for sizing the integration budget, and no way to tell whether the engineering team being acquired is an asset or a liability wearing an asset's job titles. That number, evidenced and defensible, is the deliverable.

What we do, and in what order

Scope and access. Scope letter, NDA, read-only access to the data room and the repositories, and an agreed list of who we may interview. This step usually sets the pace of the whole engagement and it is rarely us holding it up. Two to four days.
The counting day. cloc or scc across everything — languages, size, file counts, how old the code is and which parts have not been touched in years. Boring, fast, and the map everything else is read against. One day.
Dependencies and licences. npm audit or pip-audit for known advisories, license-checker for licence obligations, Semgrep for static analysis, SonarCloud where a quality baseline helps. What is out of date, what has a published vulnerability, and what carries a licence that changes what you are allowed to do with the product. One to two days.
Git history. Contributors, share of commits, who has actually been active in the last six months. This is where the bus factor comes from, and it comes from evidence rather than from asking the CTO how the team is doing. One to two days.
Tests, CI/CD, infrastructure and its monthly bill. What is automated, what is manual, what breaks on deploy, what the environment costs today and what happens to that cost at three times the load. Two to three days.
Two to four engineer interviews. The most valuable hours of the engagement. People tell you what the code cannot — which system everyone is afraid of, what the last outage really was, and what they have been asking for that never gets prioritised. Questions are written so the answers cannot be prepared in advance. Two to four days including scheduling.
Findings, remediation table, executive summary, readout. Every finding with severity, what was observed, why it matters to your investment, and what fixing it costs in developer-months and dollars. Plus a separate list of things that look alarming to an engineer and do not matter to this deal. Three to five days.

What moves the price

The range is $3,000–$30,000 over 2–6 weeks, and three things decide where an engagement sits in it.

The size of the deal. The work is broadly the same whether the transaction is small or large. What changes is the cost of getting it wrong, and the fee is priced against that risk rather than against lines of code.

How many systems there actually are. One product with one repository and one environment is a clean engagement. A holding company with a stack of acquired products, more than one cloud and the abandoned platforms nobody wants to discuss is several engagements sharing one report.

Where the scope stops. A findings list is one price. Findings plus engineer interviews, plus a five-year infrastructure cost model, plus a remediation plan you can hand straight to your own developers on day one, is another.

What usually goes wrong

Findings get written as opinions about code quality. "Code quality is poor" is worth nothing to you — it cannot be priced, argued or negotiated against. The same observation earns its place written like this: these named people leaving take with them these named systems nobody else has worked on, rebuilding those systems costs this many developer-months, and that is what it adds to your first year. Every finding ends in money and time, or it is an opinion pretending to be a conclusion.

The second list is missing. Alongside the red flags there has to be a list of the things that alarm a technical reader and genuinely do not matter to this decision — the unfashionable framework that works fine, the missing tests on a module that never changes. Without that list every finding looks equally expensive, you over-correct on price, and the report loses credibility with the engineering team it will eventually be shown to.

Gaps get quietly filled with estimates. Test coverage was never measured, so a plausible figure appears. The infrastructure cost was not provided, so somebody models one. A due-diligence report that estimates a number it was never given is more dangerous than one with a visible hole, because the hole would have become a question at the negotiating table and the estimate becomes a fact nobody checks.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Will you tell us whether to do the deal?: No, and you should be wary of anyone who will. We give you findings with severity, a remediation table in developer-months and dollars, and a red-flag list ranked by money at risk. Price and decision are yours — our job is to make sure neither is made blind.
What if the seller will not give us code access?: Read-only access through the data room is normal and enough. Where something is refused or simply absent, it is written into the report as not provided, named as a question for the seller, and never filled in with an estimate. A hole you can see is safer than a number we guessed.
Does this replace a security audit?: No. We run dependency and static analysis, check licences, and report what those tools and the interviews surface. We will never write that a system is secure — that is a separate discipline with its own testing regime and its own insurance, and the sentence is not ours to write.
Does a bigger codebase cost more?: Not really. The price tracks the size of the deal, because that is what sets the cost of being wrong. A modest transaction and a very large one involve roughly the same work on our side and entirely different consequences, and the fee reflects the risk being carried.
Can it be done in a week?: Rarely, and the constraint is not the code. It is data-room access and getting two to four engineers into interviews around their existing work. Two to six weeks is the honest range, and a compressed timeline is quoted with a surcharge stated up front.
What do you find that the financials never show?: Concentration, most often. Git history shows which systems have had one contributor for the last six months long before anyone admits it in an interview, and that single fact usually moves the year-one cost more than anything in the code itself.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Technical due diligence All Consulting, Product & Talent services