Short answer. A technical due diligence checklist for a mid-market acquisition covers ten areas: architecture and scalability, infrastructure and hosting, security, software quality and technical debt, the engineering team, product and roadmap, data, revenue systems, third-party and open-source dependencies, and cost. A checklist earns its fee only when every item maps to a deal decision: the price, the structure (escrow, indemnity, earn-out), or the first 100 days. The version below lists, for each area, the question it answers for the deal, the evidence to request, and the findings that should change your terms.
I use this on the buy side and when preparing companies for sale. Most technical due diligence checklists online are written for engineers and run to 200 questions. Deal teams need fewer questions and a clear line from each answer to the investment committee memo.
The technical due diligence checklist at a glance
| Area | The question for the deal | Evidence to request | Findings that change the terms |
|---|---|---|---|
| 1. Architecture and scalability | Can the platform carry the growth in the model without a rebuild? | Architecture diagram, load history, incident log for 24 months | A rebuild needed inside the hold; growth capped by a single component |
| 2. Infrastructure and hosting | What does it cost to run, and who controls it? | Cloud bills for 12 months, account ownership, backup and recovery tests | Accounts owned by a founder personally; untested recovery; cost growing faster than revenue |
| 3. Security | What is the exposure, and would a buyer’s insurer accept it? | Pen test reports, access reviews, incident history, policies actually in use | Unreported incidents; shared admin credentials; no MFA on production |
| 4. Code quality and technical debt | How much of the roadmap budget is servicing old decisions? | Repository access, test coverage, deployment frequency, debt register | Releases that need manual heroics; no tests on billing or core workflows |
| 5. Engineering team | Who can leave and take the product with them? | Org chart, tenure, contractor share, who wrote which systems | Critical systems known by one person; key people on short notice contracts |
| 6. Product and roadmap | Is the roadmap funded by the plan, and is it shipping? | Roadmap for 18 months, delivery history against past roadmaps | Roadmap promises in the CIM that the team has not started |
| 7. Data | Can you trust the numbers the model is built on? | Data model, definitions of customer and revenue, reconciliation of reports to finance | KPIs that do not reconcile to the ledger; churn defined differently by sales and finance |
| 8. Revenue systems | Do CRM, billing and finance agree, and can they scale the go-to-market plan? | CRM and billing exports, integration map, pipeline history | Manual billing; pipeline that does not tie to closed revenue |
| 9. Third-party and open-source dependencies | Is there licence, vendor or concentration risk? | Software bill of materials, key vendor contracts, licence scan | Copyleft code in the distributed product; a single vendor that can reprice |
| 10. Technology cost | Does the cost base match the margin in the model? | Licences, hosting, headcount, contractors by function | Costs capitalised in ways a buyer will reverse; tools nobody uses |
How each finding should change the deal
A technical due diligence report that lists issues without prices is a document the deal team cannot use. Sort every finding into one of four outcomes:
- Price. The finding has a known cost that the seller should carry: a forced migration, an unsupported framework, a licence true-up.
- Structure. The cost is uncertain: an unreported security incident, a dispute with a key vendor. Use escrow, a specific indemnity or a closing condition.
- 100-day plan. The issue is real but fixable after close and inside the model: missing tests, weak access management, a CRM that needs cleaning.
- Note only. Normal for a company of this size and stage. Write it down so nobody discovers it again at exit.
Most findings belong in the third bucket. The value of the exercise is the small number that belong in the first two, and finding them before the price is fixed.
Areas that deserve more time than most checklists give them
Security, priced in money
Security findings are where diligence most often turns into a price conversation, because the downside is large and easy to quantify. IBM’s Cost of a Data Breach report is the benchmark most insurers and boards recognise. Ask for the last pen test and the remediation status of every high finding, then check access controls yourself: who has production admin rights, whether former employees still do, and whether MFA covers every system that touches customer data.
Data and definitions
The model in the investment memo is built on numbers the target reports. If revenue, churn or customer counts are defined differently in the CRM, the billing system and the finance ledger, the model inherits the inconsistency. Reconcile three months of reported KPIs back to the ledger before you sign. This is also where the digital due diligence of the website, martech and analytics belongs on B2B targets that sell online.
Revenue systems
For a B2B company the CRM, billing and finance integration is the engine of the value creation plan: pricing changes, cross-sell, forecasting. A pipeline that does not tie to closed revenue, or billing that runs on spreadsheets, is a 100-day item at best and a margin problem at worst. The M&A integration playbook for CRM, martech and data covers what to do with those findings after close.
Key-person risk
Ask who wrote the billing logic, the core data model and the deployment pipeline. If the answer is the same person for all three, that is a retention decision for the term sheet, not a note in the report.
Architecture and scalability
Ask for the growth assumptions in the model, then ask the team what breaks first at that volume. Check the incident log for the answer: recurring incidents in the same component are the scaling limit, whatever the diagram says. A platform that needs a rebuild inside the hold is a price item, because the rebuild competes with the roadmap for the same engineers.
Infrastructure and hosting
Twelve months of cloud bills show more than any architecture review: the growth of cost against revenue, environments nobody uses, and services bought for one customer and never turned off. Check who owns the accounts and whether a restore from backup has been tested in the last year. “We have backups” and “we have restored from backup” are different answers.
Code quality and technical debt
Focus on the code the growth case depends on: billing, onboarding, the core workflow, integrations with the largest customers. Test coverage and deployment frequency there tell you how expensive change will be. A debt register written by the team is a good sign even when it is long; a team that says it has no technical debt has not looked.
Engineering team
Map people to systems. Count contractors and their notice periods, and check whether the contractors hold knowledge the employees do not. Read the last year of departures: a team that lost its senior engineers recently may still be running on what they left behind.
Product and roadmap
Compare the current roadmap with the one from a year ago. The delivery rate against past roadmaps is the best predictor of the next one, and it tests the growth story in the investor materials without an argument.
Third-party and open-source dependencies
Ask for a software bill of materials or run a licence scan. Copyleft licences in a distributed product, abandoned libraries in core workflows, and a single vendor that can reprice the product are all findings with a cost. On roll-ups, check whether each company licences the same tools separately; that is a synergy as well as a risk.
Technology cost
Rebuild the technology cost base from invoices and payroll by function: people, contractors, hosting, licences. Compare it with revenue and with the margin assumptions in the model. Watch for development costs capitalised in a way a buyer’s quality of earnings team will reverse.
Technical due diligence questions to ask the CTO
- Which part of the system would you rebuild if you had six months and no feature requests?
- What broke in production in the last year, and what changed afterwards?
- How long does it take a new engineer to ship to production?
- How often do you deploy, and who can do it?
- Which systems does only one person understand?
- What does the cloud bill look like per customer, and how has it moved?
- Which vendor could hurt you most by raising prices or ending support?
- Where do customer data live, and who can export them?
- Which roadmap items in the investor materials have not started?
- How do you measure engineering output, and what does the trend show?
- What would you need to support twice the customers?
- Which security findings are open, and why?
Compare the answers with the evidence. The gap between the CTO’s account and the repository, the incident log and the cloud bill is where the useful findings are.
The technical due diligence process, step by step
- Scope against the thesis. List the parts of the investment case that depend on technology: growth the platform must carry, products on the roadmap, integration synergies, cost savings. The review tests those first.
- Request the evidence on day one. Repository and cloud access, the last pen test, 12 months of incidents and cloud bills, the org chart, the roadmap and its predecessor, KPI definitions.
- Read before you interview. The interviews are more useful when the reviewer already knows where the evidence and the story differ.
- Interview the CTO and two senior engineers. Use the questions above, and ask the engineers the same questions as the CTO.
- Test the numbers. Reconcile reported KPIs to the ledger; check hosting cost per customer; check delivery against the old roadmap.
- Sort and price the findings. Price, structure, 100-day plan, note.
- Write the verdict for the investment committee, and the technology section of the 100-day plan for the operating team.
SaaS targets and tech-enabled services targets
The checklist applies to both, but the weight shifts. In a SaaS company the product is the asset, so architecture, code quality and the roadmap carry most of the risk, and a code-level review is worth the time. In a tech-enabled services business the technology runs the operation: CRM, billing, scheduling, ERP and the integrations between them. There the risk sits in data, revenue systems and vendor dependencies, and a review that spends a week in the code of a customised CRM misses the point. Decide which kind of target you are buying before you scope the review.
Pre-LOI screen or full confirmatory review
| Pre-LOI technical screen | Confirmatory technical due diligence | |
|---|---|---|
| Purpose | Decide whether to proceed and at roughly what price | Confirm the thesis, price the findings, write the 100-day plan |
| Access | Management call, public product, high-level documents | Repository, cloud accounts, data room, team interviews |
| Time | Two to three days | One to three weeks |
| Output | Go, no-go or go with conditions, plus questions for confirmatory work | Written report with findings sorted into price, structure, 100-day plan and notes |
How long technical due diligence takes and what it costs
Published ranges are wide because scope is. Sparkle Technologies’ 2026 pricing guide puts technology due diligence for PE and VC deals at $10,000 to $150,000, with a full assessment from a specialist firm commonly at $35,000 to $95,000 over one to three weeks. Code scanning tools, security testing and the number of entities drive the top of the range. A single-entity mid-market target with one product sits at the lower end; a roll-up with several codebases does not.
The cost to watch is time on the deal calendar. A review that starts after the LOI and runs three weeks can push signing. Book the reviewer when you start exclusivity, and send the data room request on day one.
What the technical due diligence report should contain
- A one-page verdict: proceed, proceed with conditions, or do not proceed, with the three reasons.
- Findings sorted into price, structure, 100-day plan and notes, each with an estimated cost range where one exists.
- The ten areas above, scored, with the evidence reviewed for each.
- Key people and the retention recommendation.
- The technology section of the 100-day plan: owners, dates and costs.
If the report cannot be read by the investment committee in ten minutes, it will not change the decision, however good the analysis behind it.
From checklist to the 100-day plan
The checklist ends where the value creation plan starts. Findings in the 100-day bucket become the technology workstream: access and security fixes in the first 30 days, data definitions and revenue system cleanup by day 60, the first architecture or vendor decisions by day 100. Keep the report and the evidence; the next buyer will ask what you found and what you fixed.
When a sponsor needs the review done or the remediation delivered, that work runs through DevriX’s technology due diligence practice.
