Technical due diligence
Find and frame the technical questions before a buyer asks them.
Every serious software buyer looks under the hood. We organise the review of licences, code quality, dependencies and security with specialist reviewers, so your team answers with evidence and the price holds through diligence.
Readiness tracker
In review
Every finding paired with a plan before a buyer sees it.
Why it matters
Issues found by a buyer in confirmatory diligence arrive when you have the least leverage, and often turn into price cuts, special indemnities or escrow. The same issues found early become a short, well-explained list with a fix or a plan beside each one. That is a strength in negotiation.
What buyers check
Buyers and their advisers look at the same core areas. We prepare each one with you.
Open-source licences
Most products include open-source code. Permissive licences such as MIT or Apache 2.0 are rarely a concern. Copyleft licences such as GPL or AGPL can carry obligations to share source code, depending on how the code is used and distributed.
Technical debt
Buyers want to know how much work sits between today and the roadmap they are paying for. A clear register, with effort and priority, reads very differently from an open-ended unknown.
API dependencies
Third-party APIs, cloud services and AI model providers can be single points of failure or cost. Buyers check contract terms, pricing exposure and how hard each one would be to replace.
Security
Static code analysis, dependency vulnerability scanning and, where appropriate, a penetration test show a buyer how the product is protected and how quickly issues are fixed.
How it works
A structured review, run alongside your team and specialist reviewers, ahead of the sale process.
Start a readiness reviewWeek 1
We agree scope with your CTO and collect the basics: repositories, architecture, key services, team and existing policies.
OutputScope and document list
Weeks 2-3
Specialist reviewers run licence, dependency and security scans and review code and architecture against what buyers typically ask.
OutputFindings, ranked by impact
Weeks 3-6
Your team fixes what is quick to fix. Everything else gets an owner, a plan and a clear explanation a buyer can follow.
OutputRemediation plan
Before launch
Findings, the bill of materials and supporting documents are organised into the technical section of the data room, ready for buyer questions.
OutputTechnical data room folder
Typical findings
Most findings are routine. What matters is that each one arrives with context and a plan.
| Finding | How we prepare it |
|---|---|
| Copyleft component in a distributed product | Confirm how it is used, then replace, isolate or document compliance with counsel. |
| Unmaintained or outdated dependencies | List them, upgrade the critical ones, schedule the rest. |
| Known vulnerabilities in third-party packages | Patch, or record the risk and the fix date. |
| Heavy reliance on one API or model provider | Show contract terms, usage costs and a realistic fallback. |
| Knowledge held by one engineer | Document key systems and show retention or handover plans. |
| Secrets or credentials in code history | Rotate them and show the controls now in place. |
Legal views on licence obligations come from licensed counsel. Security testing is carried out by specialist reviewers.
Prepared vs unprepared
The issues rarely change. How and when a buyer learns about them does.
Found by the buyer
Prepared in advance
Found by the buyerLate, after exclusivity
Prepared in advanceEarly, on your terms
Found by the buyerOpen-ended unknown
Prepared in advanceSized issue with a plan
Found by the buyerTeam scrambles for answers
Prepared in advanceEvidence already in the data room
Found by the buyerCuts, escrow or special indemnities
Prepared in advanceHeadline price protected
Evidence, not reassurance
A well-organised technical section of the data room shows a buyer that your team knows its product, its risks and its roadmap. That confidence carries straight into the final offer.
Every Acquiry mandate runs under strict NDA.
Questions
We run and coordinate it. Code, security and licence reviews are carried out by specialist technical reviewers, and legal views on licence obligations come from licensed counsel. We make sure the findings are organised and framed for the sale.
Usually not. It depends on how the code is used and whether the product is distributed. Many issues are resolved by documenting compliance, isolating the component or replacing it. Finding it early is what keeps it small.
A list of every third-party and open-source component in your product, with versions and licences. Buyers increasingly ask for one, and it is the starting point for licence and vulnerability checks.
Ideally a few months before going to market, so there is time to fix the quick issues and plan the rest. It can also run alongside a process if a buyer has already approached you.
Yes. Preparation does not replace buyer diligence. It means their review confirms what you have already shown them, rather than uncovering something new.
Discuss a technical readiness review
Share a few details and we will reply directly, usually the same working day. You do not need to share any code yet.