Evidence-backed technical due diligence for software startups
StackAttest provides repeatable technical evidence that supplements investor and expert diligence. It is not the reviewer. The evidence arrives the same way for every company and carries the strength of its own proof, and a person still decides what it means for the deal in front of them.
What the evidence is made of
Diligence evidence is worth what its weakest source is worth, so each layer states how far it can see. A report says which layers ran, and a reviewer can weigh the result accordingly.
Public URL scan
E4Tests the deployed application from outside, the way any visitor reaches it: transport security, security response headers, and what the running service discloses about itself. It needs nothing but the address, and what it observes it observes against the running system. Its limit is reach rather than strength: a URL can never establish authorisation, data-layer or backup posture, and those controls stay uncovered.
Repository validation
E2Reads the source: where secrets live, whether authorisation is enforced on the server or only in the interface, whether data access is injection safe, and which dependencies carry known critical vulnerabilities. Findings cite the file they came from, so a result is checkable rather than asserted.
Runtime validation
E4Builds and runs the application in an isolated environment and probes the running system. This is the layer that answers questions reading code cannot: whether the deployed configuration actually refuses an unauthorised request, and whether error responses leak internals under real conditions.
What technical diligence runs on today
This is not a complaint about the people doing the work. It is a description of the inputs they are handed, and of why two careful reviews of the same company can arrive at different answers.
A questionnaire the company fills in about itself
Security questionnaires are the backbone of most processes, and every answer in one is self-reported. A founder who says access control is enforced is describing what they believe. Nothing in the document distinguishes a belief that was tested from one that was never checked, and the reviewer has no way to tell them apart.
A deck and an architecture diagram
Both describe intent. An architecture diagram is drawn from how the system was meant to be built, and the gap between that drawing and the deployed service is exactly the territory diligence is supposed to cover. Diagrams also age badly, since nothing forces one to change when the software does.
A call where the technical answers are taken on trust
The diligence call is a good instrument for judging whether a team knows its own system. It is a poor instrument for establishing whether a specific control is switched on in production, because the honest answer to that is often that nobody has looked recently.
A one-off review that starts ageing the day it lands
An external reviewer produces a snapshot of a codebase that is still being changed daily. Within weeks the software has moved and the report has not. It is still useful, and it is no longer a current description of the thing being bought.
A price that decides how often any of this happens
Published market figures put the technical portion of an investor-led seed review at roughly ten to forty thousand dollars to the fund, and angel-led deals at two to fifteen thousand. Those are researched market numbers rather than ours. At that price the review happens once per round, which is why the evidence behind a deal is usually a year old by the time anyone questions it.
What the result looks like
An illustrative extract, not a real customer result. Every row carries the evidence grade behind it, and a control nobody could establish says so.
| Control | Status | Evidence | Note |
|---|---|---|---|
| Tenant isolation enforced server-side | Verified | E4 | Cross-account request refused by the running system |
| Secrets managed outside source code | Failed | E2 | A privileged key is reachable from client code |
| Dependencies free of known-critical vulnerabilities | Partial | E3 | Two advisories open, both with a fix available |
| Transport security enforced | Verified | E1 | Observed from outside on the production domain |
| Intellectual property assignment complete | Uncovered | Not graded | An administrative question no technical run can answer |
Mapped to published standards
Each control is tested against a named clause, so a result means something outside our own vocabulary. Mapping is not certification, and none of these bodies endorse StackAttest.
Where this stops
- It does not replace human due diligence. A reviewer still decides what the evidence means for a particular deal, and the question that matters most in a given company is usually the one only a person thought to ask.
- It is not a penetration test. Deterministic checks and runtime probes are not an adversarial human engagement, and there are classes of weakness only someone hunting for them will find.
- It is not SOC 2 and does not stand in for it. SOC 2 attests to organisational controls over a period; this tests technical controls in the software. A buyer asking for one is not asking for the other.
- It says nothing about the commercial and legal halves of diligence. Ownership of intellectual property, contracts, licences and the cap table are diligence too, and no technical run touches them.
- Thirteen controls is a defined floor, not a complete review, and a control the run could not reach is reported as uncovered rather than quietly passed.
Questions
What is technical due diligence for a startup?
The part of an investment or acquisition process that establishes whether the software does what the company says it does, and what it would cost the buyer to own. At seed and Series A it usually covers security controls, code and dependency health, ownership of the intellectual property, and whether the team can operate what it built.
Does this replace the technical reviewer an investor brings in?
No, and a page claiming otherwise would be selling you something that does not exist. What changes is where the reviewer starts. Instead of opening with a questionnaire the company wrote about itself, they open with tested results that carry an evidence grade, and spend their time on the judgment calls that actually need a person.
What does technical due diligence cost?
Published market figures put the technical portion of an investor-led seed review at around ten to forty thousand dollars to the fund, with angel-led deals nearer two to fifteen thousand. Those are third-party market numbers, not ours, and they are the reason the review tends to happen once rather than continuously.
Who runs the validation, the founder or the investor?
The founder does, on their own product, and they decide what is shared. An investor requests the sections they need for a stated purpose, and sees nothing until that request is approved. Access can carry an expiry and can be revoked later.
How current is the evidence?
As current as the last run, and every result shows its date. That is the point of making validation repeatable rather than a single engagement: a company that revalidates after shipping has a current answer, and a stale one is visibly stale rather than silently so.
What does an investor actually see?
The Passport sections the founder granted, with the evidence grade behind each result and the controls that were never covered still listed as uncovered. Source code is not included in any section, and a request that was not granted returns nothing at all.
Related
Find out what is actually true of your application
Start with the layer you can run today. The report says which layers ran and what they could not reach, so the result is honest about its own limits.