Labeled example, not a real customer
This is what your report looks like.
Every free audit runs the same 15 checks and comes back in the same format: plain-language findings, a score, and the three things to fix first. This is a representative example built from findings typical of early-stage AI-built apps, not a real audited customer. We don't have one to publish yet.
Production Audit Report
"ExampleCo" · example scenario
14/30
🔴 Red
ExampleCo's app has two urgent problems: a database key that anyone can find in the public website code, and no working backup if something goes wrong. Both are fixable this week. Everything else is in reasonable shape for an early-stage app.
| # | Check | Status | What this means | Fix effort |
|---|---|---|---|---|
| 1 | Frontend-bundle secrets | Fail | Your database's full-access key is sitting in the public website code right now. Anyone who looks can read or change your data. | S |
| 2 | CORS | Warn | Your API accepts requests from any website, which is looser than it should be. | S |
| 3 | Rate limiting | Fail | Your login page has no limit on repeated attempts. | S |
| 4 | Debug/stack-trace exposure | Pass | Errors are shown safely, no internal details leak. | — |
| 5 | Backup existence | Fail | You have no working backup. If the database is lost, it's gone for good. | M |
| 6 | Authorization / RLS | Warn | Most data is protected per-user, but one table isn't. | M |
| 7 | TLS / HSTS | Pass | Your site is served securely over HTTPS. | — |
| 8 | Error/PII exposure | Pass | Error messages don't leak other users' information. | — |
| 9 | Dependency CVEs | Warn | A couple of your software libraries have known medium-severity issues. | S |
| 10 | Uptime monitoring | Fail | Nothing tells you if the app goes down; you'd hear it from a user first. | S |
| 11 | Admin endpoints | Warn | Your admin page exists and loads, but only shows a login form, no data leak. | S |
| 12 | Client env-var misuse | Pass | No secrets are mislabeled as public. | — |
| 13 | Logging / PII retention | Warn | Logs keep some personal data with no set deletion date. | M |
| 14 | DNS/mail (SPF/DKIM/DMARC) | Warn | Your outgoing mail has partial spam protection, not complete. | S |
| 15 | Bus factor | Fail | Only one person can currently deploy, fix, or restore this app. | — |
Top 3 to fix this week
- Rotate the exposed database key today and move it server-side, before anyone finds it.
- Set up a real, tested backup. Right now, one mistake and your data is gone permanently.
- Add basic uptime monitoring so you find out about an outage before your users do.
How we'd fix all of this for you
Everything above except the backup and monitoring gaps is covered by Secrets & Access Lockdown (€490, 3 business days). Since ExampleCo is also missing backups and monitoring, the Full Production Rescue + Migration (€1,490, 7–10 days) covers all of it in one pass, plus the first month of managed hosting. See rescue services.
Real evidence, not a claim
We ran a real restore drill
"We test every restore" is easy to say and easy to leave unproven. Here's what an actual drill looked like, with infrastructure identifiers stripped since they're not the point:
- Restored into a separate database, then checked row by row. Not a "the command didn't error" check. The newest backup was restored into its own scratch database and queried directly. Every table came back, including a larger production database where the biggest single table held over 33,000 rows, all present after restore.
- Off-server by design. Backups ship automatically, three times a day, to separate cloud storage the moment they're taken, so a problem with the server itself can't take the backup down with it.
- Encrypted at rest. Backups sit in Cloudflare R2, which encrypts every object with AES-256 automatically, on by default, with no separate step that could be left off.
- A stale or missing backup gets flagged, not discovered later. Every backup run is checked against a 12-hour freshness threshold. If one goes stale or doesn't show up at all, it raises an alert on its own, the same day, not whenever someone happens to look.
This is a drill we've run on our own infrastructure, not a customer's live restore. We don't have a customer to show yet. We don't run point-in-time recovery today: a worst-case restore can lose up to the gap between two backup runs, not just seconds. If your app needs second-level recovery, ask us during the audit and we'll tell you straight whether our current setup covers it.
Report in 48 hours, yours to keep whatever you decide.