The gap between a working prototype and a launch
AI app builders are good at producing something that works when you click through it. They are much less reliable at the parts you cannot see in a click-through: whether a logged-in user can read someone else’s records by changing an ID, whether a secret key is shipped to the browser, whether a failed payment webhook leaves an order half-created, whether the test data and the live data are in the same database.
None of that shows up until real users arrive, and by then it is a data incident rather than a bug. This review exists to find those problems before your launch date, explain them in terms you can act on, and separate the ones that must be fixed now from the ones that can wait.
What the review covers
I follow a fixed checklist, adapted to the stack your tool generated. The areas are the same ones covered in my published guide to taking an AI-generated codebase to production:
- Access control. Row-level security or equivalent on every table that holds user data, storage bucket policies, and server functions that run with elevated privileges. I test these with real requests as different users, not by reading the policies alone.
- Secrets and keys. Which keys reach the browser, which keys can bypass access control, and where third-party API keys are stored and rotated.
- Data model. Ownership columns, foreign keys, indexes on the columns your policies filter by, and migrations that can be re-run.
- Integrations. Payment webhooks verified and idempotent, AI model calls with timeouts, limits and handling for bad output, email and auth flows tested end to end.
- Environments and deployment. Separate development and production data, repeatable deployment, error tracking, and a way to roll back.
- Data obligations. Where personal data is stored, how a user’s data could be exported or deleted, and what your privacy notice promises. I flag gaps; I do not give legal advice.
The signature deliverable
You receive a production-readiness diagnostic and bounded remediation plan. Illustrative example of a findings extract:
| # | Finding | Evidence | Risk if launched | Launch blocker? | Effort |
|---|---|---|---|---|---|
| 1 | invoices table readable by any signed-in user | Test user B retrieved user A’s invoices via the API | Customer financial data exposed | Yes | Small |
| 2 | Secret key used in a client-side function | Key visible in the browser bundle | Full database access for anyone who finds it | Yes | Small, plus key rotation |
| 3 | Payment webhook not idempotent | Replayed event created a duplicate order | Double fulfilment, refund work | Yes | Medium |
| 4 | No index on projects.owner_id | Policy forces a full scan on each request | Slow pages as data grows | No, fix within a month | Small |
Illustrative example. Not taken from a client engagement.
How acceptance is judged
The review is accepted when you have the report, the acceptance checklist and the remediation plan, and we have walked through them together. If you commission remediation, each launch blocker becomes an acceptance item with a test that proves it is fixed, for example the cross-user permission test now failing as it should. The checklist is yours to reuse before every later release.
Ownership and handover
The report, the tests and any fixes live in your repository. Permission tests are written so your developers, or your AI coding tool, can run them on every change, which is the approach described in Vibes Inside Guardrails: rely on mechanical checks, not on remembering to look.
I am an independent practitioner; not affiliated with, endorsed by or a partner of Lovable, Bolt, v0, Cursor, Replit or Supabase.
When to choose something else
If the project is already stuck and the real question is whether to salvage it, see rescue an AI application that cannot ship. If the app is sound and only the database and access policies need work, see Supabase production engineering. If you need a contract engineer to keep building after launch, see hire a contract AI engineer.