Technical due diligence should answer a practical question: does the technical reality of this AI or SaaS business support the decision being considered?
That decision might be an investment, an acquisition, a major partnership or the next stage of product funding. The answer cannot come from a code-quality score or an architecture diagram alone.
An early-stage company can have imperfect software and still be a credible opportunity. It can also have a polished demonstration while lacking the data, operating capability or economics needed to become a dependable product.
The job is to distinguish normal stage-appropriate gaps from risks that change the decision.
This article explains the framework I use to structure that assessment. It builds on how I evaluate technical ideas as an investor, but goes further into the product and platform evidence behind the proposition.
It is general information, not an investment recommendation or legal, financial, accounting, tax, regulatory or security-certification advice. A formal assessment needs an agreed scope, appropriate access, clear conflicts management and the relevant professional specialists. Its conclusions are limited by the evidence available at the time.
Start with the decision, stage and scope
Technical diligence is not one standard checklist.
The depth should reflect:
- the decision being made
- the company's stage
- the amount and purpose of capital
- the product's risk and operating context
- what the business claims to have proved
- the access and time available for assessment
A pre-product company should not be judged as if it operates a mature enterprise platform. Its evidence may be customer research, a prototype and a credible plan to test the largest technical assumptions.
A company with paying customers should meet a different standard. There should be evidence that the product works repeatedly, that somebody owns production, that customer data is controlled and that the team understands the risks behind its next commercial milestone.
The scope should state what will and will not be reviewed. That can include product demonstrations, architecture, selected code and repositories, cloud environments, data flows, security evidence, delivery practices, incident history, cost information and interviews with the people responsible.
Access matters. A conclusion based on a presentation is not equivalent to one supported by system evidence.
1. Product evidence: does the software solve the stated problem?
I begin with the product because technical sophistication has little value without a useful outcome.
The company should be able to explain:
- who the product is for
- which workflow or decision it improves
- what the customer uses today
- why the proposed change is valuable enough to adopt
- what evidence has been gathered
- which assumptions remain
A demonstration shows that something can be made to work in a controlled setting. Product evidence shows whether it works for the intended user under realistic conditions.
Useful evidence can include:
- observed user behaviour rather than stated enthusiasm
- repeat use
- paid pilots or customers
- implementation and support experience
- renewal or retention signals appropriate to the stage
- product decisions changed by customer evidence
- known reasons for failed adoption
For an early company, the important question is not whether every feature exists. It is whether the team is learning about the right problem and reducing the uncertainties that could stop the business.
I also compare the product roadmap with the commercial plan. If the next sale depends on capabilities that are technically complex, poorly understood or several delivery cycles away, that is a decision-relevant gap.
2. Architecture: can the system support the next stage?
Architecture diligence is not a search for fashionable patterns.
I want to understand the main system boundaries, why important choices were made and where the platform is exposed to concentration, scale or change risk.
The review should cover:
- major applications, services and data stores
- external providers and integrations
- identity and trust boundaries
- critical synchronous dependencies
- expected workload and performance characteristics
- deployment and environment design
- failure containment and recovery
- infrastructure and third-party cost
Simple architecture is not a weakness when it fits the stage. A young SaaS business often benefits from fewer moving parts and clear ownership.
Complexity becomes a concern when the team cannot explain it, when every change crosses several fragile boundaries or when the platform depends on assumptions that have never been tested.
Scalability claims need evidence. That does not always require a large production customer. It may be supported by load tests, realistic capacity modelling, known service limits and a credible path for the next order of magnitude.
The question is not “Will this architecture scale forever?” It is “Can it support the next commercial stage, and does the team understand what must change after that?”
3. Data and AI: are the inputs, evaluations and dependencies credible?
Data diligence is central to an AI product and important to almost every SaaS business.
Start with provenance:
- Where does the data come from?
- Who owns it?
- On what basis can it be used?
- How is consent or another lawful basis handled where required?
- Which data is sensitive?
- How is it retained and deleted?
These questions may lead into legal and regulatory review, which requires the appropriate specialist. The technical assessment should identify the data flows and control evidence without pretending to provide that legal conclusion.
Then assess quality and operation:
- how records are validated and matched
- how missing or incorrect data is handled
- how lineage is preserved
- who can access or change the data
- how pipeline failure is detected and recovered
- whether training, test and production data are separated appropriately
For AI capability, a convincing demonstration is not enough. I look for an evaluation method tied to the real task.
That includes:
- a defined measure of useful performance
- representative evaluation data
- known failure modes
- human review where the consequence requires it
- monitoring for quality and operational degradation
- a fallback when a model or provider is unavailable
- visibility of latency and cost
Model-provider dependency also matters. The product may rely on capability, pricing, rate limits or terms controlled by another company. The diligence question is not whether third-party models should be avoided. It is whether that dependency is understood and whether the commercial model can absorb it.
4. Security: is there evidence of proportionate control?
Security review should begin with the product's actual risks, not a generic questionnaire.
I look at:
- authentication and authorisation
- privileged access
- tenant and customer-data separation
- secret and key management
- encryption in transit and at rest
- dependency and vulnerability management
- secure development and release controls
- logging and auditability
- backup and recovery
- incident ownership and response
The expected maturity depends on stage, data sensitivity and customer commitments. I do not expect a young business to operate every control of a large regulated enterprise.
I do expect it to know what it protects, where the main threats sit and who is responsible.
Claims require evidence. Saying that a platform is secure, compliant or aligned with a standard is not the same as showing the control, its scope and how it operates. A technical diligence review is not automatically a penetration test, regulatory opinion or certification audit.
Security gaps should be connected to consequence. An over-permissive internal tool, an exposed production credential and a missing formal policy are not equal findings.
5. Delivery capability: can the team keep making good changes?
The current codebase matters. The team's ability to change it matters more.
A good technical assessment examines:
- who owns product and architecture decisions
- the experience and coverage of the engineering team
- how work is prioritised
- code review and testing practices
- deployment frequency and failure handling
- documentation of critical decisions and systems
- reliance on individual people or suppliers
- hiring plans and realistic capability gaps
The aim is not to impose one engineering method. It is to see whether the delivery system produces reliable evidence and whether the team can respond when reality differs from the plan.
Founder capability belongs in this section. A technical founder does not need to know every discipline, but they should understand the limits of the system and the team. A non-technical founder should be able to explain who owns those decisions and how they evaluate the advice they receive.
Concentration risk is often underestimated. If one person alone understands deployment, a core integration or the production database, the business has an operating risk even if that person is excellent.
6. Operating reliability: what happens after deployment?
A product that works during a demonstration may still be difficult to operate.
I look for evidence from production or the closest realistic environment:
- service health and useful monitoring
- error rates and performance
- incident and support records
- ownership outside normal delivery work
- release and rollback practices
- backup restoration evidence
- capacity limits
- recovery from third-party failure
- customer communication during disruption
For a pre-production company, some evidence will be planned rather than observed. The plan should still name the likely failures, the signals that reveal them and the person responsible for responding.
Reliability is not a binary judgment. A non-critical early product may accept more interruption than a system that supports payments, healthcare, compliance or live customer service.
The standard should follow the promise made to the customer.
7. Technical debt: what has been deferred, and what does it constrain?
Every useful product carries technical debt. The existence of debt is not the finding.
I want to know:
- whether the team can identify it
- why it was accepted
- what change or risk it now constrains
- whether remediation is understood
- whether the commercial roadmap leaves room to address it
Debt becomes material when it repeatedly delays product work, creates customer or security exposure, makes releases unsafe, prevents hiring from being effective or requires a significant rewrite before the next milestone.
Warning signs include:
- unsupported frameworks or critical dependencies
- little automated coverage around consequential workflows
- environments that cannot be reproduced
- repeated production fixes without root-cause work
- manual processes that do not scale with customers
- undocumented systems understood by one person
- a roadmap that assumes debt can be removed without affecting delivery
Be careful with rewrite proposals. Replacing a working system is expensive and introduces new risk. The assessment should explain what cannot be achieved safely with the current platform and why incremental change is insufficient.
8. Commercial fit: does the technology support the business model?
Technical diligence should connect the platform to how the business sells, implements, serves and retains customers.
I examine:
- the buyer and adoption process
- implementation effort
- custom work required per customer
- procurement, security and integration barriers
- infrastructure and model costs
- support requirements
- the effect of customer growth on operating load
- technical dependencies behind the next revenue milestone
An AI or SaaS business may report recurring revenue while carrying substantial manual delivery. That is not automatically a bad model. The important point is whether the company understands which work can become repeatable, which remains service-led and how each affects margin and growth.
I also test product claims against technical cost. A feature may be valuable but uneconomic at the usage level customers expect. A platform may be technically scalable while every new customer requires months of bespoke integration.
The question is whether growth strengthens the business or simply multiplies work and exposure.
This commercial connection is central to my operator-led investment approach. Technology is assessed as part of a business, not in isolation from it.
Turn observations into decision-useful findings
A long list of issues is not a diligence conclusion.
Each material finding should explain:
- Evidence: what was reviewed or observed.
- Risk: what could fail or remain unproved.
- Consequence: why it matters to the decision.
- Stage: whether the gap is reasonable now or already overdue.
- Action: what would reduce the uncertainty or exposure.
It should also separate:
- confirmed facts
- reasonable inferences
- claims that could not be verified
- information that was not available
That distinction protects both sides. A missing document does not prove a control is absent, but it does limit the confidence of the assessment.
Useful conclusions are rarely a simple pass or fail. They show which risks are acceptable, which should affect terms or timing, which need specialist review and which contradict the investment or growth case.
Red flags are patterns, not isolated imperfections
Early-stage businesses are incomplete by definition. A single weak process may be normal.
I become more concerned when several signals point to the same underlying problem:
- strong claims with little inspectable evidence
- nobody clearly responsible for production or security
- technical decisions disconnected from customer and commercial priorities
- repeated customer-specific work presented as a scalable product
- AI performance discussed without a relevant evaluation method
- important dependencies that the team has not tested or costed
- known reliability issues with no ownership or learning process
- founders who treat reasonable diligence questions as an obstacle
The opposite is also true. A team can be credible while showing material gaps if it identifies them honestly, understands their consequences and has a realistic plan to close them.
What an operator lens changes
My approach is shaped by building products from initial concept through architecture, engineering and cloud delivery into commercial operation.
That experience makes me interested in the points between the diagrams: how a decision reaches production, how the team discovers failure, how customer commitments change priorities and how operating cost affects what can be sold.
The technology leadership disciplines behind that work cover product, software engineering, cloud, DevOps, MLOps, security, quality and production operations. Technical diligence draws evidence across those areas, then connects it to the stage and decision.
It should not reward complexity or punish a company for being young. It should test whether the claims, evidence and capability are consistent.
The final assessment
I return to eight questions:
- Is there evidence that the product solves an important customer problem?
- Can the architecture support the next commercial stage?
- Are the data and AI claims supportable and operable?
- Are security controls proportionate to the product's risk?
- Can the team deliver and learn reliably?
- Can the business operate the platform it has built?
- Does technical debt materially constrain the roadmap?
- Does the technical reality support the commercial model?
The objective is not certainty. No time-boxed assessment can guarantee future performance.
The objective is a clearer decision: what is known, what remains uncertain, which risks are material and what evidence should be required next.
If an investment, acquisition or portfolio decision needs a technical view, share the decision, stage and evidence available. A useful assessment starts with the question it must answer, not a generic checklist.
The technical due diligence reading path connects this framework to the earlier investment lens and the security evidence behind a dependable product.