Technical due diligence: what can be established in a few days
For: Investors, acquirers and board members
Updated: 2026-09
Technical due diligence under time pressure concentrates on six questions: does the architecture carry the planned growth path, how large is the technical debt, does the system depend on individuals, how do security and licensing stand, and can operations be handed over.
Technical due diligence rarely has enough time to examine everything, so it has to prioritise. Not every defect is a risk to the price, and not every tidy repository means a system that will hold.
This checklist sorts by what can be established reliably in a few days and what genuinely bears on valuation. The emphasis is on risks that become expensive after closing.
The checklist
- 01
Test the architecture against the growth path
Do not ask whether the architecture is good, ask whether it carries the intended path. A monolith may be entirely adequate for that path — the question is where the first hard limit sits.
Done when: The point at which the architecture hits a limit is named and expressed in user numbers or data volume.
- 02
Make technical debt concrete
Count the distribution rather than the quantity. What matters is whether the debt sits in areas the planned work must touch or in stable peripheral ones.
Done when: There is a statement on which parts of the system the next initiatives will touch and what condition exactly those parts are in.
- 03
Establish dependence on individuals
Check whether any area is understood by one person only. In small teams that is the norm; the question is whether that person stays and whether a handover route exists.
Done when: Every critical part of the system has at least two named people, or the risk is expressly recorded.
- 04
Check dependency licences
Copyleft licences in a commercial product can carry binding consequences. The check is automatable and is one of the few points with a clear yes or no.
Done when: A complete dependency list with licences exists and critical licences are individually assessed.
- 05
Test security fundamentals
Access management, secret handling, encryption, currency of dependencies. Not a full security test, but the question of whether the basics are present.
Done when: No credentials sit in the source code, and the currency of dependencies is known.
- 06
Assess operational readiness and handover
Can a different team run this system? Check deployment, monitoring, backups and whether a restore has ever been carried out.
Done when: A restore from backup has demonstrably been performed once rather than merely configured.
- 07
Record the compliance position
Processing register, processing agreements, data residency and — where the product carries AI functions — classification under the AI Act. Gaps here become the buyer’s responsibility after closing.
Done when: The compliance position is documented and open points carry an effort estimate.
Common mistakes
- —The review assesses code quality rather than risk. Elegant code in an area nobody will touch is immaterial to valuation.
- —Dependence on individuals goes unaddressed because it is uncomfortable. In small teams it is often the largest single risk.
- —Backups are configured but a restore has never been tested. The difference only shows in an emergency.
- —Compliance is set aside as a legal matter, although open points feed directly into integration effort.
What this checklist does not cover
- —Technical due diligence in a few days is a risk assessment, not a completeness guarantee. It finds the large items, not every defect.
- —A full penetration test is not included and must be commissioned separately where protection needs are elevated.
- —Legal review of contracts, intellectual property rights and employment matters is a separate workstream.
- —Statements on future scalability rest on the growth path described. If that changes, so does the assessment.
Parent service: IT Consulting
Matching offers
Tech due diligence
A tech due diligence examines what sits under the hood before an investment or acquisition: architecture, code quality, scalability, security and technical debt. The result is an honest risk assessment that can prevent an expensive wrong decision — before it is taken.
CTO as a Service
CTO as a Service delivers technical leadership on demand: well-founded architecture and technology decisions, roadmap planning and team guidance — without the cost of a full-time position. Suited to companies that need technical substance but cannot yet carry, or do not yet want, a CTO of their own.
FAQ
How much access is needed?
Read access to the repository, sight of the dependency list and conversations with the technical leads cover most of it. Production access is rarely necessary.
What is the most common finding?
Dependence on individuals and an untested restore. Both are fixable, but they have to be known before closing because they feed straight into integration planning.
Is a finding a reason to walk away?
Rarely. More often findings flow into price, warranties or a post-closing remediation plan. The purpose of the review is an accurate picture, not a pass or fail.
More checklists
Technical SEO review: the points that actually block indexing
Most technical SEO problems trace back to a handful of causes: pages are not indexable, canonicals point elsewhere, the sitemap lists pages that should not be indexed, hreflang is not reciprocal, or pages carry almost no internal links.
Visibility in AI answers: a checklist for being citable
Being citable in AI answers rests on a few properties: a short self-contained answer near the top, unambiguous statements instead of marketing language, verifiable claims with a date and an author, clean access for AI crawlers, and identifiable authorship.
MVP launch: what has to stand before your first paying customer
Five things have to stand before an MVP launch: a working payment path, a data model that permits later change, a route to delete accounts, a way to learn that something has broken, and basic legal documents. Everything else can wait.