Technical Due Diligence for Deals Decided on Evidence
Before you invest in or acquire a software company, we review its platform, code and engineering team, and tell you in writing what the technology means for the business plan: the risks, the strengths and the work needed. A fixed fee, and two to three weeks once access is ready.
Engineering experience behind the assessment
- 1,000,000,000
- financial transactions in under an hourFastPost accounting platform · developed for LegerityFastPost case study
- Architecture
- integration architecture analysis and designGlobal beverage companyIntegration case study
- 80%
- lower infrastructure costHotel metasearch platform redevelopmentHotel search case study
- For
- Investors, acquirers and boards who need an independent view of a software company's technology before deciding
- Timing
- Typically two to three weeks once access is ready, with the schedule agreed around your deadline
- Fee
- Fixed quote based on the systems, codebase size and review depth, independent of any follow-on work
- Output
- Decision summary, evidenced findings and remediation priorities, with a walkthrough for your team
What the due diligence report contains
Written for the investment team, with every finding tied to the evidence behind it.
Decision summary
The material risks, strengths and open questions for the investment team, with their implications for the business plan.
Evidence and limitations
Findings linked to reviewed code, documentation, interviews or operational data. Gaps in access and areas outside the review are explicit.
Remediation priorities
A ranked list of changes with indicative effort and dependencies, supporting the next planning discussion.
Readout and questions
A walkthrough with the assessors and a written clarification round. The report remains yours, regardless of any later engagement.
Stratoflow was a great partner, challenging as well as supporting our customer projects for the best outcome. They have a great pool of talent within the business - all very capable technologists, as well as being business-savvy and suitable for consultancy engagements.
What a technical due diligence covers
Architecture and scalability
System boundaries, dependencies, failure modes and the capacity assumptions behind the roadmap.
Code and testing
Maintainability, test strategy, dependency health and the effort required to change the software safely.
Team and delivery
Ownership, key-person dependencies, release process and whether the team can execute the proposed plan.
Investment implications
How technical findings affect delivery, operating costs and near-term priorities, including uncertainty in the estimates.
Security and operations
Identity controls, secrets handling, vulnerability management, deployment practices and incident history.
Data and AI
Data availability and quality, existing AI controls and the feasibility of planned AI features.
How a technical due diligence review runs, from scope to readout
Two to three weeks from access to report, with your investment questions agreed up front and the findings explained to your team at the end.
Scope the review
We discuss the target, its systems, your investment questions and the deadline, and agree the fee, the access checklist and the boundaries before work starts.
Review the evidence
We read the code and documentation, inspect the available operating data and talk to the technical leaders under NDA.
Test the findings
The evidence is compared with management’s assumptions. Confirmed issues are kept apart from open questions.
Deliver and explain
You receive the report with its priorities and limitations, and a walkthrough for the investment team with time for follow-up questions.
Independence and scope of the review
The due diligence fee does not depend on any follow-on work. Findings rest on the evidence available, and recommendations include alternatives where they would change the decision.
Our deepest experience is in Java and JVM platforms. For mixed technology stacks we agree the expertise needed before quoting, and name any specialist review that falls outside our scope.
Questions about technical due diligence
How is the fee set?
We quote a fixed fee based on the number of systems, codebase size, requested depth and access available. Repeat assessments can be covered by a framework agreement.
What affects the timeline?
A typical review takes two to three weeks once access is ready. More systems, incomplete documentation, delayed access or specialist questions may require a different schedule, agreed with you.
What access do you need?
Usually read access to repositories, CI and deployment information, architecture documentation and relevant operating records, plus interviews with technical leaders. We agree a proportionate access plan under NDA.
Is this a penetration test or compliance certification?
No. We review security posture and available evidence within the agreed assessment. Penetration testing, formal certification and legal opinions require separate specialist scope.
Can you implement the recommendations?
Yes, where they fit our engineering expertise, under a separate agreement. You can also use the report to brief your own team or another supplier.
Is technical due diligence the same as software due diligence?
The terms overlap. Tech due diligence and technology due diligence usually cover the whole technology function, including infrastructure, security and the team; software due diligence focuses on the code and architecture. Our technical due diligence services cover both. A codebase in good shape still carries risk when the team cannot change it, so the team is part of the review.
Do you work from a software due diligence checklist?
Yes. A software due diligence checklist makes sure nothing standard is missed: licenses, dependencies, security, tests, deployment and documentation. The findings that change a valuation usually come from outside it: how the system behaves at the growth the plan assumes, and who can change it.
How is IT due diligence different?
IT due diligence usually reviews internal IT: infrastructure, vendor contracts, licenses and support. Technical due diligence looks at the product the company sells and the team that builds it. When the target’s value is its software, that is what we review, and we name the IT areas that need a separate review.
Can you run a code audit outside a transaction?
Yes, for a board that needs an independent view of a system it owns. The review is the same: architecture, code quality, security posture, the team and the effort to change the software, for a fixed fee.
Due diligence guides from our engineers
- Modernization
What Is Technical Debt, and How Do You Measure and Reduce It?
Technical debt defined, measured and priced, with the types that matter most in Java systems.
- Java
Java End of Life Dates, 2026 to 2033: What Ends When, and What October Changes
Every Java LTS in use today loses Oracle extended support between 2029 and 2033, and Oracle JDK 21 stops being free in production in October 2026.
- Modernization
Legacy System Modernization: When to Keep, Upgrade, Rearchitect or Replace
Keep, upgrade, rearchitect or replace: four questions that pick the option for a legacy system, with the stories of Southwest, TSB, Knight Capital and Shopify.
Discuss the target and your decision timeline
Tell us which systems are involved and what the investment team needs to understand. We will propose the review scope, access requirements and fee.