Technical due diligence
Independent technical assessments, from architecture to AI claims.
Years ago I flagged an architectural problem I thought would make a product hard to sell. The advice wasn't taken. When the first buyer arrived, their due diligence found the same issue within days, and they walked away. As did the rest.
I've spent over twenty years building software for organisations from startups to the BBC, much of that time exploring unfamiliar codebases and helping people make hard decisions about what to do with them.
Buy-side
An independent assessment of the target's technology before terms are final.
- A clear view of technical risk before committing
- Findings backed by evidence from the codebase, systems, and team
- Indicative remediation costs to inform negotiation
Sell-side
The same assessment, run before buyers run theirs (sometimes called vendor due diligence).
- An early view of what a buyer's due diligence will find
- A prioritised fix list, with a view on what can safely wait
- Documentation and evidence ready for the data room
- Fewer surprises mean less leverage against the valuation
What gets assessed
The assessment covers the areas that most often decide whether a deal is sound, scoped to what matters for the transaction in hand. It draws on the codebase, the engineering team, leadership, processes, documentation, and product management.
Architecture
How the product is actually built: structure, code quality, technical debt, and whether the foundations can support where the business is heading.
Scalability
Whether the platform can handle the growth the deal assumes, and what it would take to get there if not.
Security
How customer data and systems are protected in practice: access control, secrets handling, and security hygiene. A review of posture and practice, not a penetration test.
Team
Where the critical knowledge sits, how much walks out of the door if one person leaves, and how well the rest is written down.
Operations
Deployment, monitoring, backups, and incident handling. Whether the product is run on solid process or on goodwill and memory.
Open-source licensing
What the product depends on, and any licence terms that could complicate a change of ownership. Risks are flagged for legal review rather than settled.
AI claims
Whether AI features are real capability or a thin wrapper around someone else's model, and whether they'd survive a competitor copying them.
Roadmap
Whether the plans the valuation rests on are achievable with this team, this codebase, and this budget.
Why Secret Orange
I'm a practitioner. Findings come from having built and run comparable systems across media, fintech, real estate, health and safety, and various other SaaS products.
AI claims get particular scrutiny. Having worked hands-on with machine learning since 2021 and more recently agentic AI, I can tell the difference between genuine capability and good marketing.
Where the experience comes from
Hands-on engineering and product work with organisations like these.
How it works
The process is designed to be light on the company being assessed: usually a day or so of the team's time in total, spread across interviews and access to code and systems. The report follows within a few weeks.
- Red flags first. Findings that could affect the deal appear on the first page.
- Red, amber, green. Every finding carries a severity rating, so the overall picture is clear at a glance.
- Remediation costs. Indicative effort and cost to put each significant issue right, useful in negotiation and planning.
- Plain English. Written for investors, boards, and founders. The technical evidence is all there, and the conclusions don't need translating.
Getting started
Whether buying, investing, or preparing to sell, the first step is a short, confidential conversation about the deal and what the assessment needs to cover.