What I would inspect before investing in a SaaS company

Most technical diligence I see run by investors themselves stops at questions a founder can rehearse: what's your stack, do you have tests, what's your uptime. Founders know these are coming and prepare good answers, which is exactly why they're weak signals. The useful questions are the ones that require pulling up the actual system, not describing it from memory.

1. Ask to see a real incident, not a summary of incidents

Not "tell me about your worst outage" — pull an actual postmortem, or if one doesn't exist, ask why. A team that documents incidents in writing, with a timeline and a named root cause, is telling you something about operating discipline that no answer in a pitch meeting can. A team with no postmortems either hasn't had an incident worth writing up, which is rare past a certain scale, or doesn't have the habit of learning from them in a way that sticks.

2. Look at what percentage of revenue depends on one customer's specific requests

This is a product question that hides as a technical one. Pull the git history or the ticket tracker and look for how much engineering time in the last two quarters went to one-off requests from the two or three biggest accounts. A SaaS company that's quietly become a services shop for its largest customer has a different risk profile than the multiple implies, and it usually doesn't show up until you look at where the commits actually went.

3. Check whether the roadmap and the org chart tell the same story

If the pitch is "AI-native platform" and the engineering org has one person touching anything ML-related, that's not necessarily disqualifying, but it changes what you're actually valuing — a platform with an AI feature, not an AI company. Match the language in the deck against where the headcount and the recent hiring actually sits.

4. Find the one system nobody wants to touch

Every codebase past 18 months old has one. Ask directly which part of the system the engineering team avoids touching, and why. The honest answer tells you where the real technical debt is concentrated and whether the team has a plan for it or has just been routing around it. The evasive answer tells you the team doesn't know, which is its own finding.

5. Test the bus factor on the founder-CTO specifically

In founder-led technical companies, a huge amount of undocumented context sits with one person. If that person is distracted by fundraising or a board seat for six months post-close, does the technical organization still function? This is uncomfortable to test directly, but it's answerable by looking at whether architectural decisions get made and documented by more than one person, or whether everything routes through one head.

None of this replaces a proper technical diligence engagement, but it's the difference between a diligence process that confirms what the deck already said and one that finds what the deck couldn't have said. See how a technical due diligence engagement is scoped.

Subscribe: RSS