Launch and privacy

Launch answers one question: can you open the app to real people? It combines what Faundr already knows (security, errors, tests, Stack) with what only your computer can check, and shows what's missing across three levels. The Privacy tab shows what privacy laws expect from your app.

Ready to launch?

The verdict sits at the top: "Not yet: N items block launch", "Nothing blocks launch; N items left before real users" or "Ready for real users". The Check now button copies /faundr:launch.

The three levels

Blocks launch. If any of these is open, someone's data or money is exposed.

1. No exposed keys or passwords
2. Database closed to visitors
3. No critical security issues
4. Payments confirmed by a signed webhook

Before real users. Fine for showing friends. Not ready for the public.

1. Site security headers
2. Rate limiting on routes
3. Privacy policy
4. Automatic database backups
5. Backup tested
6. Recovery plan
7. High-severity security issues resolved
8. Tests passing
9. Production environment variables documented
10. Live app errors reach Faundr
11. Alert when the site goes down

Keep an eye on. These don't block launch, but they grow if nobody looks.

1. Packages without known vulnerabilities
2. Live app errors resolved
3. Recent security review

Each item has a status (Ready, Missing, Warning, N/A or Not checked), a detail line with the date of the last check and, when it isn't ready, the command that fixes it. The View in Security, View in Errors, View in Tests and View in Stack buttons take you to the section the item comes from.

What updates on its own and what you check

• On its own: the items that come from Security, Errors, Tests and Stack.
• Through /faundr:launch: anything only your computer or the live site can verify. That covers the database test as a visitor, the security headers on the live site, rate limiting, the payment webhook signature, the privacy policy, automatic database backups (read from Supabase with your personal SUPABASE_ACCESS_TOKEN, which never leaves your computer) and the recovery plan. The plan is the file docs/plano-de-recuperacao.md: what to do if a key leaks, the database is lost, an account is taken over or the site goes down, and how to notify the data protection authority after a breach (the ANPD, under Brazil's LGPD). If the plan doesn't exist yet, the agent offers to write a draft.
• By hand: Backup tested. Restore a database backup into a test project and, if it works, click I tested a restore today. After 90 days the item goes back to "Warning" to remind you to test again.

The database test as a visitor

/faundr:launch tests your Supabase database the way an attacker would:

1. As a visitor, with the public key that ships in your app, it tries to read every table.
2. As another signed-in person, it tries to read, write, update and delete data that belongs to someone else.

The write, update and delete tests touch your real database, so they only run with your OK, and everything is undone right away: the test runs inside a transaction that's rolled back on purpose. Every open door it finds becomes an issue in Security.

To write, update and delete, the test needs your personal Supabase token (SUPABASE_ACCESS_TOKEN) or the Supabase tools in your AI agent. Without either, it only tests reads and tells you so.

Privacy

The Privacy tab shows what your app does with personal data and what privacy laws still require. Which laws apply depends on where your users are. Your own location doesn't decide it: LGPD for users in Brazil, GDPR for the EU and the UK, CCPA/CPRA for California and similar US state laws. Several can apply at once.

The check doesn't use AI. Faundr only reads field names, columns, packages and URLs in your code. It never reads your users' data.

What you'll see

• What to do: the six items checked, each with a status, a detail line and why it matters:
• Privacy policy
• Terms of service
• Cookie consent
• Delete account and data
• Sensitive data
• Companies that receive data
• Personal data the app collects: each type of data (name, email, tax ID, address, location…), where it shows up and a sensitive tag on the categories the law protects most (health, religion, biometrics…).
• Where the data goes: the outside services that receive data (payments, email, analytics, ads…), tagged tracker and uses cookies where it applies.

Writing what's missing

/faundr:privacy works out which laws apply from where your users are. If the code doesn't make that clear, it asks you. It then explains the inventory in plain language and, once you approve, writes:

• the privacy policy;
• the terms of service;
• the cookie notice, only if the app uses trackers;
• the delete account button, which removes the person's data too.

Before writing, the agent asks for what only you know: the company or controller name, the tax ID, the email for privacy requests, the jurisdiction for disputes and how long data is kept after an account is deleted. To write just one piece: /faundr:privacy policy, terms, cookies or deletion.

Commands