Tech due diligence is the buyer's review of whether a target's technology can support the investment thesis: architecture and scalability, code quality and technical debt, security and compliance, hosting costs, license risk, team dependence, roadmap credibility and any AI claims. It finds what will cost money after close, so price, escrow, indemnities and the 100-day plan reflect it.
Shiptronix, a technology advisory and services firm in Belleair Bluffs, Florida, runs technology and commercial due diligence for private equity firms. This is the checklist we work from, including the lower middle market items larger checklists skip.
What is tech due diligence, and how is it different from IT due diligence?
They overlap and get used interchangeably, but they usually answer different questions.
| Tech due diligence | IT due diligence | |
|---|---|---|
| Main question | Can the product and platform scale with the plan? | Can the internal systems run the business safely? |
| Typical target | Software, SaaS, tech-enabled services | Any company: manufacturing, distribution, services |
| Focus areas | Architecture, code, engineering team, product roadmap, hosting | ERP, network, end-user devices, help desk, back office |
| Common surprises | Technical debt, single developer, license issues, overstated AI | End-of-life systems, no tested backups, spreadsheet reporting |
The technology due diligence checklist
Gather evidence, not answers. Grade each finding one of three ways:
- Normal
- A 100-day fix
- A deal issue
1. Architecture and scalability
- Get a current architecture diagram, then have an engineer walk through it live. A diagram drawn for the data room often differs from what runs.
- Identify single points of failure: one database server, one region, one integration that every order passes through.
- Ask what breaks at two times and five times current volume. That is usually what the growth plan assumes.
2. Code quality and technical debt
- Confirm the source code is in a company-controlled repository with history, not on a laptop or in a contractor's personal account.
- Review a sample of recent changes: is there code review, automated testing and a repeatable deployment process?
- Ask the team to list their own top technical debt items.
- Check for unsupported frameworks that force a rewrite inside the hold.
3. Security, compliance and incident history
- Request the most recent SOC 2 report if there is one. A SOC 2 examination, defined by the AICPA, reports on controls relevant to security, availability, processing integrity, confidentiality or privacy. A Type 1 report covers design at a point in time; a Type 2 report covers whether controls operated over a period. Read the exceptions section, not just the opinion.
- Ask for every security incident in the last three years, including phishing losses and ransomware attempts, plus what changed afterward.
- Check multi-factor authentication on email, cloud consoles, the code repository and finance systems.
- Confirm backups have actually been restored in a test.
4. Infrastructure and hosting costs
- Pull 12 months of cloud and hosting invoices and trend them against revenue. Hosting that grows faster than revenue eats margin as the business scales.
- Look for reserved capacity commitments, auto-renewals and price escalators that survive the close.
- Separate run-rate spend from deferred catch-up.
5. Third-party and open-source license risk
- Request a software bill of materials or run a scan. The SPDX standard gives each open-source license a consistent identifier, which makes the output reviewable.
- Flag strong copyleft licenses in shipped or hosted code. The GNU AGPL, for example, can require offering source code to users who interact with modified software over a network, which matters for SaaS.
- Confirm that employees and contractors who wrote the code signed IP assignment agreements.
- List critical vendor and API dependencies, and check change-of-control clauses in their contracts.
6. Data and privacy
- Map where personal and customer data lives, who can reach it and how long it is kept.
- Identify which privacy laws and contractual obligations apply, and whether there is a working process for access and deletion requests.
7. Team and key-person risk
- Ask who holds admin credentials for each critical system, and whether those credentials sit in a shared password manager owned by the company.
- Identify anyone whose departure would stop releases or block access to production.
- Review retention terms for key engineers.
8. Product roadmap credibility
- Compare the last two years of roadmaps with what actually shipped. Delivery history predicts delivery better than the plan does.
- Tie roadmap items to engineering capacity. A plan that needs twice the team is a hiring plan.
9. AI claims: are the AI features real?
- See each AI feature work live on real customer data, not in a recorded demo.
- Find out which model or vendor powers it, what it costs per use and what happens to margin as usage grows.
- Ask what share of customers actually use it.
- Check whether a human is quietly doing part of the work behind the feature.
The SEC has warned against "AI washing". For a buyer, the risk is paying a multiple for capability that does not exist yet. Our article on how private equity firms are using AI covers the buyer-side view.
10. Domains, DNS, email and website hosting (lower middle market)
In smaller companies these assets often sit in a founder's personal account. Chase them down before close.
- Look up who is the registrant of record for every company domain, and which login controls the registrar account.
- Identify who controls DNS hosting. Whoever controls DNS controls where the website and email go.
- Check that SPF, DKIM and DMARC are set up for the company's sending domains, and who manages them.
- Confirm who owns the website hosting account, the email tenant (Microsoft 365 or Google Workspace) and the billing on each.
- Make transfer of these accounts to company ownership a closing deliverable.
Our guide to DNS records explains what each record controls.
What we see most often in diligence
Three patterns keep coming up across management interviews, customer and industry interviews and competitive benchmarking.
- AI claims that are really roadmap. Automation in the pitch deck often describes a plan, not a shipped product. Asking to see it run on real data settles it in minutes.
- One person holds the keys. An engineer or the founder holds the credentials to the cloud account, the code repository and the registrar, sometimes on a personal email address.
- Domains in an individual's name. Domains, DNS and email are frequently registered to a person, not the company.
Our take: the last one is the cheapest to fix before close and the most painful after.
Which findings are red flags, and which are normal?
| Finding | Usually normal | Usually a red flag |
|---|---|---|
| Technical debt | A known, prioritized list the team can explain | Nobody can name it, or a rewrite is needed within the hold |
| Security | Gaps with a remediation plan in progress | No MFA on admin accounts, untested backups, undisclosed incidents |
| SOC 2 | No report yet at an early-stage company with a plan | A report with significant exceptions the seller downplays |
| Team | Small team with documentation | One person holds all credentials and knowledge |
| Licenses | Permissive licenses with attribution | Copyleft code in a hosted product, missing IP assignments |
| AI features | Clearly labeled as roadmap | Presented as live revenue drivers but not demonstrable |
| Domains and email | Registered to the company | Held in a founder's personal account with no transfer plan |
How do tech due diligence findings change deal terms?
Findings only matter once they reach the agreement or the plan:
- Price: quantifiable catch-up costs, such as a forced platform upgrade or hosting re-architecture, come off the valuation or are added to the model as one-time spend.
- Escrow or holdback: uncertain exposures, such as an open license issue, can be covered by holding back part of the price until resolved.
- Specific indemnities: known issues are often excluded from representations and warranties insurance, so buyers commonly ask for a specific indemnity from the seller for a named risk like a prior breach.
- Closing conditions: credential handover, domain and account transfers, and signed IP assignments can be required before funds move.
- 100-day plan: fixable items such as MFA rollout, backup testing and cost cleanup become owned tasks with dates.
When should tech due diligence happen in a deal?
After the letter of intent and before the purchase agreement is drafted, so findings can still shape terms.
A focused lower middle market review typically fits into a few weeks alongside financial and legal diligence.
If you only do one thing: when technology is central to the thesis, kick off a short pre-LOI screen. It can change the price you offer. Our guide to commercial due diligence covers the market-side work that runs in parallel.
To have an outside team run this checklist on a live deal, our technology due diligence engagements are built for PE buyers and their deal teams.
Frequently asked questions
What is the difference between tech due diligence and IT due diligence?
Tech due diligence focuses on the product: architecture, code, engineering team and roadmap. IT due diligence focuses on internal systems such as ERP, network and devices. Many deals need both.
How long does technology due diligence take for a lower middle market deal?
A focused review usually takes a few weeks after the letter of intent, in parallel with financial and legal diligence. Timing depends mostly on how fast the target provides access.
Does a target company need a SOC 2 report to be acquired?
No. Many smaller companies lack one, and that alone is not a red flag. Check whether customers require it and what controls exist.
How do I check whether a company's AI features are real?
Ask to see each feature run live on real customer data, find out which model or vendor powers it and what it costs per use, and check how many customers actually use it. If the answers are vague, treat the feature as roadmap.
What tech due diligence items should be closing conditions?
Common closing conditions include transferring domains, DNS, email and hosting accounts to company ownership, handing over admin credentials, and signed IP assignment agreements from founders, employees and contractors who wrote the code.