SEC-01
Least-privilege access
Each integration gets the narrowest scope that lets the work function. Nothing more.
Stage 01 · StrategizeTechnical due diligence
What the code and the team are actually worth
An independent read on the technology behind a deal — before you buy it, invest in it, or bet a roadmap on it. Written for the people making the decision, not for engineers.
- Access stays in your accounts
- Every change on record
- Written, auditable deliverables
- C01Understand the thesis firstIn scope
- C02Architecture and scaleIn scope
- C03Code and delivery healthIn scope
- C04Security and dataIn scope
- C05People and knowledge riskIn scope
- C06Cost to ownIn scope
- C07Priced risk registerIn scope
In short
Technical due diligence is an independent assessment of whether the technology behind a deal supports the valuation. It covers architecture and scalability, code quality and test coverage, security posture and data handling, third-party and licence exposure, infrastructure cost, key-person risk, and the size of the technical debt the buyer would inherit. The output is a risk register with each finding priced — remediation cost, timeline and whether it is a negotiating point or a walk-away.
- 5
- Warning signals
- that say this is the work
- 7
- Controlled steps
- each ships something you keep
- 4
- Written refusals
- lines we do not cross
Self-audit
Signals this is the work
Tick the ones that are true where you are. Nothing is sent anywhere — the answer is for you, not for us.
If more than one of these is true today, the problem is usually further along than it looks from the outside. That is not a sales line; it is what the cost of waiting does.
Readiness checklistTechnical due diligence
0 of 5 true
Nothing ticked yet.
How we do it
The sequence
Each step ships something you keep. You can stop after any of them and still be better off than when you started.
Start with step one- 01
Step 1 of 7
Understand the thesis first
What has to be true about the technology for the deal to work? That question shapes everything examined, and stops diligence becoming an undirected code review.
- 02
Step 2 of 7
Architecture and scale
Whether the design supports the growth in the plan, and what breaks first if it arrives. Stated capacity is tested against how the system actually behaves.
- 03
Step 3 of 7
Code and delivery health
Test coverage, build and release process, branch and review discipline, and how long a small change genuinely takes to reach production.
- 04
Step 4 of 7
Security and data
Access control, secrets handling, dependency exposure, personal-data flows and what a breach would reach.
- 05
Step 5 of 7
People and knowledge risk
How much of the system exists only in one person. This is the finding that most often changes a valuation.
- 06
Step 6 of 7
Cost to own
Infrastructure, licences, and the engineering capacity needed to keep the thing standing before it does anything new.
- 07
Step 7 of 7
Priced risk register
Every finding with a remediation estimate, so the output is usable in a negotiation rather than a list of concerns.
Assurance
Secured and auditable by default
These controls apply to every engagement, including this one. They are engineering decisions, not a certificate on a wall — and you can check each of them.
SEC-02
Credentials in your name
Accounts and keys live in your tenancy. You can revoke any of them without asking us.
SEC-03
Every change logged
Changes, deployments and incidents leave a written trail you can audit.
SEC-04
Restores tested, not assumed
A backup only counts once it has been restored. We test, and we report the result.
SEC-05
Separate environments
Development never touches production credentials or unmasked customer data.
SEC-06
A documented exit
Runbooks written as we go. Leaving means revoking our access — nothing is held back.
What we will not do
The refusals
The things we turn down are a better description of how we work than the things we sell.
Standing commitmentsTechnical due diligence
- 01
We will not: Produce a report that justifies a decision already taken.
- 02
We will not: Score a codebase against a house style rather than against the deal thesis.
- 03
We will not: Flag every finding as critical. If everything is red, nothing is.
- 04
We will not: Assess a team we were not allowed to speak to, and present it as complete.
Questions
Before you ask
Anything else, ask on the first call. There is no charge for working out whether this is the right fit.
Talk about a problemHow long does technical due diligence take?
Most engagements run one to three weeks depending on codebase size, how many systems are in scope, and how quickly access is granted. Access is usually the constraint. We scope it against your deal timeline and tell you what is achievable in the window you actually have.
What do you need access to?
Read access to repositories, a walkthrough with the senior engineers, infrastructure and billing visibility, and the incident history. If access is restricted — which is common pre-signing — we say explicitly what could not be verified rather than inferring it.
Will this create friction with the target team?
It can, and how it is run matters. We frame it as understanding the system rather than grading the engineers, and we share findings with their technical lead before the report is final. Engineers generally recognise the problems already; being asked is less adversarial than being reported on.
What if we find something serious?
Most findings are priced and negotiated rather than fatal. A missing test suite, a scaling ceiling or an unpatched dependency is a number. Genuine walk-aways are rarer: unresolvable licence contamination, a platform with no supported upgrade path, or data handling that creates regulatory exposure the buyer would inherit.
Tell us what isn’t working.
One process, one system, one decision you are stuck on. An engineer replies within one working day with how we would approach it, and whether it needs building at all.