A tech due diligence checklist for angel and seed investors

Angels, syndicates, and seed funds routinely back software businesses on deals too small to justify a big-firm diligence process, which usually means the technology gets no independent look at all. The demo looked good, the founder sounded confident, the deck said “scalable.” That is not diligence; that is vibes. And the bill for vibes arrives late: not at signing, but a year or two in, when the founder’s “quick update” call turns out not to be quick. Here is what an independent reviewer actually checks, sized for smaller deals, so you can at least ask the right questions yourself.

1. Is the product what the demo says it is?

The first question is the crudest: does the software do, in production, what you were shown in the demo? Early products are sometimes a polished front on manual work behind the scenes. That can be a legitimate stage of a business, but you want to know you’re pricing a product, not a promise.

2. Architecture and code quality

Not “is the code pretty” but: is this built to last, or due for a rebuild the plan doesn’t budget for? A rebuild isn’t automatically a deal-breaker, and plenty of good early code is rough. What matters is whether the cost of what comes next is in the valuation.

3. Scalability, against the actual thesis

The question is never “does it scale” in the abstract. It is whether the technology can carry the growth this deal is priced on. Ten times the users is a different question from a thousand times, and the answers differ accordingly.

4. Security and the exposure you inherit

A breach after you invest is your problem too. What data does the product hold, who can access it, and what happens when someone hostile looks at it? For products holding payments, health, or identity data, this section gets longer, not shorter.

5. IP and licensing: do they own what you’re buying?

Contractors who never assigned IP, a co-founder who left with unclear ownership, copyleft licenses in the core product, code lifted from a previous employer. These are cheap to check and catastrophic to discover later. Ask who wrote every part of the product and what paper says the company owns it.

6. Key-person risk

In most early software companies, the honest answer to “what happens if the technical founder leaves” is “we have a serious problem.” The check is how much lives in one or two heads: can anyone else deploy, debug, and extend the product? Documentation and a second set of hands are worth real money here.

7. The team you’d be keeping

Diligence isn’t only code. Who actually built this, are they staying, and what gaps does the roadmap assume get filled? A strong product from a team that’s leaving is a weaker asset than a rough product from a team that’s staying.

8. The real cost after the deal

Finally, the number that belongs in your model: what will it cost to run, fix, and grow this technology after the money lands? Hosting and tooling, the deferred maintenance, the hires the roadmap quietly assumes. If the plan is priced on the demo and not on this number, the valuation is optimistic by exactly the difference.

When to get an independent read

You can ask all of this yourself, and good founders will answer straight. But founders are selling, and you are buying, and on the technology most investors can’t independently evaluate the answers. And “the founder is very technical” is not the reassurance it sounds like: nobody stress-tests their own decisions. This is where an independent tech due diligencereview earns its keep: someone with no stake in the deal reads the code, meets the team, and tells you straight whether to buy, walk, or renegotiate. On smaller deals that doesn’t need a big-firm process. It needs someone who has built and sold software businesses, a focused read, and a report your investment committee can act on.