Short on time? Technology due diligence checks what a company really owns and runs before you buy it, merge with it or invest. Review architecture, code, security, data, people, contracts, licences, operations and cost. Rate each finding as a deal breaker, a fix before closing or a plan for after closing. Start early, ask for evidence and involve legal, finance and security.
A company can look healthy on paper and hide risky software, unpatched systems, unclear licences or a key engineer who is about to leave. In a deal, such issues change price, timing and the first year of integration.
Technology due diligence is the structured check that finds them. This article lays out a practical review for buyers, investors and sellers. It suits a small business buying a competitor and a large group acquiring a software firm. It is general information, so take legal and financial advice for your deal.
Key takeaways
- Technology due diligence covers architecture, code, security, data, people, third-party and open source licences, operations and cost.
- Ask for evidence, since descriptions can mislead: diagrams, reports, test results and contracts.
- Classify findings as deal breaker, fix before closing or plan for after closing.
- Security and data findings can change both value and legal risk.
- Plan integration while you review, since many costs appear after closing.
What the review covers
Architecture and code
- How is the system built, and does it scale?
- How much technical debt exists? Martin Fowler’s technical debt article offers a useful frame: extra effort on every change is the interest. See also our article on technical debt.
- Are there tests, a build pipeline and sound release habits?
- Who understands the code, and is it documented?
Software supply chain and licences
- Which open source and third-party components are inside, and under which licences?
- Is there a software bill of materials? CISA describes an SBOM as a nested inventory of the components that make up software, and a key building block for supply chain risk management.
- Are there licence terms that affect resale, hosting or change of control?
- Who owns the intellectual property, including work done by contractors?
Security and privacy
- Is there a security programme, and which framework does it follow? The NIST Cybersecurity Framework helps organisations understand and improve management of cybersecurity risk, and it is a common reference for such reviews.
- Results of recent penetration tests and vulnerability scans. See penetration testing explained.
- Incident history, and how the company responded.
- Privacy compliance for the markets served.
Data and systems
- What data is held, where, and under what rules?
- Quality of data and reporting.
- Integration points and dependencies. See enterprise software integration patterns.
People and ways of working
- Key people, their roles, notice periods and retention risk.
- Team skills against the roadmap.
- Use of contractors and outsourcers.
Operations and cost
- Hosting, cloud bills and contracts, including commitments. See cloud cost optimisation.
- Resilience: backups, recovery tests and uptime history.
- Support load and customer-reported issues.
A worked example: buying a small software firm
This example is illustrative.
A services group plans to buy a firm of 30 people that sells a scheduling product.
Week one: the buyer sends a request list and signs a confidentiality agreement. The seller opens a data room with diagrams, contracts and reports.
Weeks two and three:
- An engineer reviews the code structure and sample modules, and runs a dependency scan.
- A security specialist reads test reports and interviews the lead developer.
- A finance analyst compares cloud bills with revenue.
- A lawyer reviews licences, customer contracts and employee agreements.
Findings:
- Deal breaker: none.
- Fix before closing: one open source component with a licence that conflicts with the sale model, and a known vulnerability in a login library.
- Plan after closing: the product runs on one large server with weak recovery tests, and one engineer holds most of the knowledge about billing.
Actions: the seller replaces the component and updates the library before closing. The buyer negotiates a retention agreement for the key engineer and adds a recovery project to the first 100-day plan.
Questions to ask in interviews
- What would break first if usage doubled?
- Which part of the system do you fear changing?
- When did you last restore from backup, and how long did it take?
- What was your worst incident, and what changed afterwards?
- Which customers rely on custom work?
- What is on the roadmap that the current design cannot support?
Honest answers matter more than polished ones.
Rating findings
- Deal breaker: a problem that makes the deal unwise at any realistic price, such as no ownership of core code or a serious undisclosed breach.
- Fix before closing: an issue the seller can and should resolve, or that the price should reflect.
- Plan after closing: a risk you accept and schedule, with cost and owner.
Put a cost range and a time estimate next to each item.
Small and large deals
- Small deal: a focused review of a few days, led by one or two experienced people, concentrating on code ownership, security basics, key people and costs.
- Mid-size deal: a team covering each area, with written reports.
- Large deal: a formal programme with specialists, clean rooms for sensitive data, legal sign-off and integration planning from day one.
Regional and regulatory notes
Data protection, export controls, employment law and sector rules vary by country. A target company may serve customers in regions with strict rules. Involve local advisers where the target operates.
Common mistakes
- Starting the technology review after the price is agreed.
- Accepting slides in place of evidence.
- Skipping open source licence checks.
- Ignoring people risk.
- Treating security as a yes or no.
- Not planning integration costs.
A starting plan
- Write a request list for each review area.
- Pick reviewers with the right skills, and agree confidentiality.
- Review evidence and interview key people.
- Rate findings and attach costs.
- Feed results into price, terms and the first 100 days.
How SoftSapien supports technology due diligence
SoftSapien’s consultants and engineers review code, architecture, security, data and operations, rate findings and build integration plans for buyers, investors and sellers. See our business advisory consulting and cybersecurity consulting services.
To plan a technology review, use the contact page to chat with our team, send a message or schedule a free consultation call.
Frequently asked questions
What is technology due diligence?
A structured review of a target company technology before a deal: architecture, code, security, data, people, licences, operations and cost.
What should be rated a deal breaker?
Problems that make the deal unwise at any realistic price, such as no ownership of core code or a serious undisclosed breach.
Why check open source licences?
Licence terms can affect resale, hosting or change of control, so a bill of materials and licence review matter.
How long does it take?
A focused review of a small deal can take days, and large deals take weeks with specialists for each area.
Can SoftSapien help with technology reviews?
Yes, for buyers, investors and sellers. Contact SoftSapien through the contact page to chat with our team, send a message or schedule a free consultation call.
