Know what you are buying.
The deck says the platform is scalable. We read the code, talk to the engineers, and tell you what is actually there — in language your board can act on.
We review a company's code, architecture, team and process before you invest or acquire, and report in plain language. Two to three weeks. The findings usually change the price or the conditions rather than killing the deal.
Updated August 2026
Almost nothing kills a deal.
Most findings change the price or the conditions instead.
Almost nothing we find is a reason to walk away. Most of it is a reason to negotiate.
Buyers expect a verdict. What they get is more useful: a list of what will cost money after completion, what carries real risk, and what was described optimistically.
The common findings are unglamorous. One person understands the critical system. There are no tests, so every change is a gamble. The infrastructure bill will triple at the growth they are projecting. None of these kill a deal; all of them are worth knowing before signing.
We write for the people making the decision, not for engineers. If your board cannot act on the report, it has failed regardless of how thorough it was.
What you get.
A report a board can read
Findings first, in plain language, with the technical detail in an appendix for whoever wants it.
Findings ranked by cost
What you will have to spend after completion, and roughly when.
Key-person risk named
Who holds knowledge nobody else has. Consistently the most valuable finding.
An honest read on the team
From conversations with the engineers, not from CVs.
What the claims actually mean
Where the pitch and the repository disagree, stated without drama.
Cost projection
What infrastructure costs at the growth being forecast, which is rarely modelled.
Questions for the negotiation
Specific things to ask, with the answers you should expect.
A call to walk through it
So your team can ask what the findings actually mean for the price.
What we actually look at.
Ranked by how often the finding changes a deal.
| Area | What we check | How often it matters |
|---|---|---|
| Key-person risk | Who understands what, and what happens if they leave | Very often — the top finding |
| Tests and deployment | Can they change things safely and quickly | Very often |
| Architecture at scale | What breaks at 10× the current load | Often |
| Infrastructure cost | What the bill looks like at projected growth | Often — and rarely modelled |
| Security and data | Access control, secrets, personal data handling | Sometimes, seriously when it does |
| Licences and ownership | Who owns the code, what is licensed in | Rarely — but occasionally fatal |
Where the judgement comes from.
Our founder has been building and inheriting production systems for two decades.
Six years and four and a half years respectively — both fintech, both at real scale.
We are not bidding to rebuild what we assess. That would make the report worthless.
When to commission this.
You are acquiring a company
Technology is usually the least examined part of a deal and often the most expensive surprise.
You are investing
Especially at the point where the round is large enough that a rebuild would matter.
You are the one being examined
Finding your own problems first is far better than a buyer finding them.
Not to justify a decision already made
If the deal is happening regardless, we will say so rather than produce a document for the file.
How we work.
We agree what matters to you
A five-person acquisition and a growth round need different depth. Scope decides the price.
We read the code
Structure, quality, tests, dependencies, and where the risky parts sit.
We talk to the engineers
Usually the most revealing part. People are candid when asked directly and without their CEO present.
We check the infrastructure
What it costs now, what it costs at the growth being forecast.
We write it plainly
Findings ranked by what they will cost you, not by technical severity.
We walk you through it
So the negotiation is informed by what the findings actually mean.
Frequently asked.
5 questions answered. Still have one? Reach out.
Two to three weeks for most engagements. A small acquisition can be done in one; a large platform with several teams takes four. The limiting factor is almost always access — how quickly we get the repository, the infrastructure account and time with the engineers.