Technology Advisory
The technical truth before the term sheet
Know what you're buying, funding, or inheriting — before you sign.
Acquisitions, investments, and vendor takeovers all hinge on a question someone answers too late: is the technology what they claim? Code, architecture, security, and team risk can be read like a balance sheet — by people who build for a living.
- Deal price informed by technical reality
- Post-acquisition surprises moved pre-signature
- A remediation roadmap ready for day one
Capabilities
What the work actually involves
Codebase & architecture audit
Quality, maintainability, and scaling headroom assessed from the code itself, not the pitch.
Security posture review
Vulnerability surface, data handling, and compliance gaps — the liabilities that don't appear in data rooms.
Delivery & team assessment
Bus factors, velocity truth, and the difference between documentation and folklore.
Cost & scalability modelling
What growth actually costs on this architecture — infrastructure, licenses, and rework.
Red-flag & remediation report
Findings ranked by deal impact, with remediation costs estimated for negotiation leverage.
Licence and open-source compliance
What the codebase actually depends on and under which licences — copyleft obligations in a product about to be sold is the finding that changes a deal rather than a sprint.
Key-person and continuity risk
How much of the system only one person understands, and what the documented recovery path looks like if that person leaves the week after completion.
Deliverables
What you are handed.
Yours to keep, and written so another team could pick them up.
A code and architecture assessment
What is actually there, how much of it is load-bearing, and what it would cost to change.
A team and process review
Key-person risk, delivery capability, and whether the roadmap is achievable by the people present.
A risk register with costs
Each finding priced, so it can be negotiated rather than merely worried about.
A 100-day plan
What to do first if the deal proceeds.
We do not publish prices — scope drives them. Everything else, here.
- Starts with
- Scoped access to the codebase, the team and the roadmap
- Typical duration
- 2–5 weeks
- Who you get
- A principal architect and a senior engineer
- Commercial model
- Fixed fee, scoped to target size
How to decide
What the answer depends on.
Two sets of conditions. Read both against your own situation — most organisations recognise themselves in one column within a sentence or two.
This is the right call when
- You are acquiring or investing and the technology is material to the value.
- A target's roadmap looks optimistic and you want an independent read.
- You need findings priced, not just listed.
A different approach fits better when
- You need it in three days. Real diligence needs code and people access.
- Only a data room is available, with no access to the codebase or the engineers who wrote it.
- You want confirmation of a decision already taken.
Before you ask
Questions about technology due diligence
Sectors
Where this comes up most.
The regulatory context and the systems already in the building change the build. Each sector page says how.
More in Technology Advisory
Next step
Bring us the problem. We will bring the architecture.
A discovery call takes forty-five minutes. You leave with our read on the problem, the shape of the system we would propose, and a straight answer on whether we are the right team for it.
- No sales deck
- An engineer on the call, not an account manager
- NDA before you share anything