Sample report
What the other side's engineers would find, on a real product.
This is the complete Full Audit of nicuk/docsflow, one of our own products: a multi-tenant platform where businesses ask questions of their own documents. Nothing is edited or hand-picked. It is what the audit returned, and every finding points at a file and line you can open on GitHub.
- Scanned
- September 22, 2026
- Codebase
- 50,238 lines
- Files read
- 160 of 477
- Ranked risks
- 2 critical · 5 high · 4 medium
What you're looking at
The automated Full Audit, exactly as a buyer receives it. Start with the Snapshot, then the Action Plan: it groups every fix by when it matters, including the ones to close before you raise or sell.
What the due-diligence review adds
A senior engineer checks these findings against the code, removes anything that doesn't hold up, adds what automation can't judge, and signs a written summary. That review isn't shown here.
Your system at a glance
- Critical risk: 0
- High risk: 0
- Medium risk: 7
- Low risk: 24
Who holds the knowledge
3 critical areas depend on one person.
| Area | Commits | People | Top person's share | Reading |
|---|---|---|---|---|
| migrationscritical | 7 | 1 | 100% | One person |
| app/authcritical | 2 | 1 | 100% | Too few commits to judge |
| app/logincritical | 1 | 1 | 100% | Too few commits to judge |
| docs/databasecritical | 4 | 1 | 100% | Too few commits to judge |
| lib/authcritical | 4 | 1 | 100% | Too few commits to judge |
| supabase/migrationscritical | 10 | 1 | 100% | One person |
| app/api/authcritical | 25 | 1 | 100% | One person |
| app/api/stripecritical | 4 | 1 | 100% | Too few commits to judge |
Measured from commits in the last 12 months, not from understanding. Squash merges, shared accounts, and AI agents committing under a person's name can all make one person look like many, or many look like one.
The Bottom Line
This is a well-architected document-question-answering product for business customers, with genuinely strong engineering in its core search and reliability systems. However, the administrative side of the product currently trusts information that a visitor can simply type in themselves, meaning someone who knows a customer's account number and an administrator's email could read that customer's user list or send out invitations. That is a small, fixable set of problems — roughly a week of work — but it should be handled before any enterprise security review or investor technical audit.
Several issues need attention soon. Plan for 2-4 weeks of focused development work.
If Nothing Is Done
The administrative doors on your platform are effectively unlocked for anyone who knows two pieces of ID information, and one of your invitation systems hands out access codes that are guessable. If a customer discovers this — or an enterprise buyer's security team finds it during a review — you lose the deal and potentially the customer, and you spend weeks on emergency response and breach notification instead of building product. Separately, with no automated safety checks running before code goes live, every change your team ships is a coin flip, which quietly slows down every future release.
2 critical and 5 high-severity vulnerabilities detected across 11 total issues + 3 high-priority quality issues
Feature Coverage
5 of 11 features have test coverage
6 features need automated verification
45%
Coverage
System Health Score
What the score means
Critical risks cap the max score
Your system is well-built and maintainable
Risk Overview
11 risks + 13 quality issuesWant this for your own codebase?
Scan it free in about a minute, or ask for the human-reviewed version before a raise, sale or acquisition, from $1,500.