Technology due diligence is where optimistic decks meet reality. Having led technical reviews on both sides of the table — as an investor and as the executive being reviewed — I use a checklist that fits on one page. It will not replace a full audit, but it catches the majority of deal-killing problems early.
Architecture and scalability
- Can the team draw the entire system on one whiteboard, including third-party dependencies?
- What breaks first if load grows 10×? An honest answer here is a green flag by itself.
- How much of the “proprietary platform” is genuinely proprietary, and how much is configuration of open-source or cloud services? Neither is bad — misrepresenting it is.
- Is there a single point of failure: one server, one region, one irreplaceable engineer?
Team and process
The strongest technical signal is rarely the code itself — it is how the team changes it:
- Version control discipline, code review, CI with automated tests that actually run.
- A deployment path that does not depend on one person’s laptop.
- Bus factor: what happens if the CTO is unavailable for a month?
- A realistic view of technical debt. Every startup has it; mature teams can list theirs.
Security and data
After years of consulting in information security, I check these before anything else:
- Where does personal data live, and who can access production?
- Secrets management: are credentials in the repository? (You would be surprised how often.)
- Basic hygiene: TLS everywhere, patched dependencies, offboarding process for departed staff.
- For regulated markets: GDPR posture, data-processing agreements, incident history.
Intellectual property
- Is the IP actually owned by the company — not by a contractor, a previous employer, or a co-founder who left?
- Contributor agreements for everyone who touched the code, including freelancers.
- If patents are claimed, what exactly do they cover and in which jurisdictions? Having filed and defended patents myself, I read the claims, not the marketing summary.
What I consider red flags
- Demos that cannot be shown live “for security reasons”.
- A codebase the founders cannot navigate during a screen share.
- Metrics dashboards assembled the night before the meeting.
- Hostility toward the diligence process itself — the strongest predictor of a difficult partnership later.
None of these alone kills a deal; patterns do. And the reverse is also true: a team that opens its repository, admits its debts and explains its trade-offs is telling you exactly how it will behave as a portfolio company. That is the team worth backing.
Read next
How to Pitch Your Startup to Investors: a Reviewer's View
What actually matters in a startup pitch, from an investor who has reviewed 10,000+ startups: team, traction, technology and the questions you must answer.