OpsRunway Talk to an engineer
Menu

Preparing for Series A technical due diligence, from the founder's side.

Most writing on technical due diligence is aimed at investors. This is the other side: what a reviewer is likely to ask you, what to have ready in the data room, and what to fix in the 60 days before they look.

Written by the OpsRunway engineering team · Reviewed · How we research and fact-check guides

01When it happens

When technical due diligence happens.

Series A diligence usually comes in two rounds. Before the term sheet, investors look at the business and ask broad questions about the product and the team. After it, confirmatory diligence goes deeper, and that's when a technical reviewer, sometimes an outside firm, asks for access to documents, a walkthrough of the architecture and an hour with your CTO.

There's no industry-standard checklist. Every fund and every reviewer does it a little differently, which is why preparing for the common ground matters more than guessing the exact questions.

02What they look at

What technical reviewers look at.

AreaWhat they're really asking
ArchitectureWill this survive 10x the customers without a rewrite? Where are the single points of failure?
SecurityWho can access production and customer data? Would you know if someone did who shouldn't?
ReliabilityWhat happens if the database is lost? How long would recovery take, and has it been tested?
Cloud costWhat does it cost to serve one customer, and how does that change with growth? Are credits hiding the real number?
Code and processIs there review, testing and a deploy process, or does it all live in one person's head?
TeamKey-person risk. What happens if the CTO leaves?
IP and licencesDo you own the code? Any licences that would worry an acquirer?
03The data room

Fifteen documents to have ready.

  1. An architecture diagram that matches what's actually running
  2. A list of AWS accounts, environments and what runs where
  3. Who has production access, and how it's granted and removed
  4. Backup and restore approach, with the date of the last restore test
  5. Incident log for the last 12 months, with short write-ups
  6. Uptime figures for the last 90 days, with how they're measured
  7. Monthly cloud cost for 12 months, gross of credits
  8. Cost per customer or per unit of usage, and the trend
  9. Security measures in place, and any audit or pen test results
  10. Status of SOC 2 or other certifications, if customers ask for them
  11. Deploy process and frequency
  12. Third-party services that hold customer data
  13. Open-source licence summary
  14. Engineering team structure, and who knows what
  15. A short list of known technical debt, and the plan for it

Keep the numbers consistent across documents. An inconsistent data room slows a deal down more than an honest weakness does.

04Red flags

Infrastructure red flags, and the quick fixes.

Red flagQuick fixEffort
Shared root login or ex-employees with accessMFA on root, SSO for people, remove old users1 to 2 days
Backups never restoredRestore one, time it, write it downhalf a day
Deploys from a laptopCI deploys with OIDC credentials1 to 2 days
Everything clicked together in the consoleImport the core into Terraform1 to 2 weeks
Cloud cost only known net of creditsPull 12 months of gross usage from Cost Explorer2 hours
No idea what happens if the region goes downWrite down the answer, even if it's "we'd be down for a day"2 hours

Disclose, don't hide. Reviewers expect a Series A company to have gaps. What worries them is finding one you didn't mention. A known weakness with a dated plan reads as competence.

0560 days out

A 60-day prep plan.

  1. Get an outside read.

    Run through the readiness checklist honestly, or have someone do it for you.

  2. Fix the cheap, scary things.

    Access, backups, deploys, gross cost visibility. These are the items reviewers notice first.

  3. Write it down.

    Build the data room from the list above. Draw the architecture as it is, not as it will be.

  4. Rehearse.

    Have someone ask the CTO the hard questions for an hour, including the ones about cost per customer.

Our AWS readiness review covers days 1 to 10 in five working days and gives you a ranked list for the rest.

Further reading: Futureproof on Series A diligence, Vertex Ventures, madewithlove.