AI app launch readiness

AI App Production Checklist

By Ohad Krispin, founder of VibeRaven · LinkedIn

Before launching an AI-built app, verify that a new user can sign in, complete the core task and access only the data they should. If you charge, verify that payment creates the right access. Then check production configuration, error reporting and recovery. A working preview is a useful starting point; the launch decision needs evidence from the deployed app as well as its code.

Paste this to your agent

Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Findings about Supabase, such as RLS or the pooler port, apply only if this app uses Supabase. Do not add Supabase or any other provider this app does not already use. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.

The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.

Read the production guide

Why it matters

The working demo is not the launch.

Start with failures that could expose data, grant access incorrectly or interrupt the product's main task. Record each check as verified, failed or not tested, with the deployment and evidence you used. Do not turn "not tested" into a pass. The checklist below describes your launch review; it is broader than VibeRaven's automated checks for Vercel + Supabase. VibeRaven is advice, not a gate, and a repository check, not a live database or security test.

Checklist

What to check before real users arrive

01Sign-in and permissions: read session checks and authorization in routes, handlers and server actions. On the production URL, verify sign-up, confirmation, sign-in, reset and sign-out. Protected actions must reject unauthorized requests.
02Data access: read migrations, grants and ownership rules. Verify that an account can access its own private records and cannot read or change another account's records.
03Payments, if applicable: read webhook verification, event handling and entitlement logic. Verify the correct provider mode and endpoint, that payment changes access correctly, and that replaying an event does not grant duplicate benefits.
04Secrets and configuration: read server/client boundaries and required variable names. Verify that the intended deployment uses the correct environment values without exposing server credentials.
05Core product task: read validation, failure handling and relevant tests. Verify that a fresh account completes the main task, reloads and sees the expected saved result. Check a realistic failure too.
06Monitoring: read client and server instrumentation. Verify that a controlled test error reaches the correct project and the person responsible can see it.
07Recovery: read the migration plan and restore procedure. Know which deployment to restore and how to recover data; confirm the backup covers what the app actually stores.

How VibeRaven helps

For an AI-built app on Vercel + Supabase, run npx -y viberaven check from its repo. It can surface some gaps in migrations, credentials, environment-variable declarations and Stripe webhook code.
A disposable synthetic fixture checked on October 31, 2026 with published version 1.7.2 produced rls_disabled and data_api_grant_without_rls as critical findings, plus missing_monitoring as info. It exited with code 1 and wrote .viberaven/agent-tasklist.md with the migration file and line for each blocker. This verified the current command and generated artifacts, not a deployed app.
Read the tasklist before choosing a fix. In that run, the RLS task warned that enabling RLS without policies blocks browser reads, asked for user agreement, and separately listed applying the migration to the live database.
Server-side authorization, payment entitlements, provider configuration and the live user journey still need separate verification. A clean repo result does not prove the app is secure or production-ready.

Run VibeRaven to scan one AI-built repo on Vercel + Supabase and see which repo gaps it finds before launch.

Evidence and next steps

Turn the launch checklist into verified behavior

Use the checks above to separate code evidence from deployed behavior. The primary sources and historical comparison below explain why both matter.

Check permissions beyond the interface

A hidden button does not prevent a request to its endpoint. Inspect where the server verifies identity and permission, then exercise the same action as an unauthorized caller in a controlled test. Next.js treats both Server Actions and Route Handlers as public-facing entry points that need authorization checks.

For Supabase, check both grants and row-level policies. Supabase's RLS documentation explains that policies enforce row access when RLS is enabled. Test allowed behavior as well as denied behavior: blocking every request is not a working permission model.

Separate the build from production configuration

Compare required variable names with the values configured for the intended deployment. On Vercel, variable changes apply to new deployments, so redeploy after changing them and retest the affected feature. In Next.js, NEXT_PUBLIC_ values are bundled for the browser at build time. Never use that prefix for a server secret.

Check callback URLs, email links and external-service endpoints on the production domain. A successful localhost flow does not verify those settings.

Follow payment and error signals to their destination

If you use Stripe, verify signatures against the raw request body and the endpoint's signing secret. Test duplicate delivery and access changes, not just whether checkout opens. Stripe documents signature verification, retries and duplicate events; those behaviors matter when a payment becomes product access.

For monitoring, trigger a controlled error through the app's instrumentation and confirm receipt. Sentry's Next.js setup guide includes a test-error page for verification. An installed package alone does not show that errors reach the project.

A historical example: the policy existed, but the final state mattered

In a maintainer-authored synthetic comparison on October 5, 2026, VibeRaven 1.6.3 inspected a public.notes table with explicit grants to an ordinary authenticated role and no RLS. It reported rls_disabled and data_api_grant_without_rls as critical. A separate disposable local PostgreSQL test returned both seeded users' rows to one authenticated caller.

In the comparison's valid_split fixture, a later migration enabled RLS and added owner policies. Version 1.6.3 reported neither SQL finding, and the local SELECT returned only the caller's row. The useful lesson is to inspect the complete migration sequence and test the resulting permissions.

These are historical local observations using PGlite 0.5.8, explicit grants and an auth.uid() shim. They do not establish anonymous access, all CRUD behavior, hosted Supabase state or application authorization. The baseline's anonymous-access wording was too broad for these grants. The original comparison, recorded scanner results and runtime reproduction are listed with the sources below.

Run a local repo check on Vercel + Supabase

For an AI-built Vercel + Supabase app, run the command from the repo and read .viberaven/agent-tasklist.md. Use a finding to narrow the next code task; verify provider settings and the deployed user journey separately.

npx -y viberaven check

CLI guide: npx viberaven

Give your agent one concrete launch task

Use the repo findings and manual checks to narrow the next task. Ask your agent:

Recheck after a fix, then repeat the affected user flow. Invite users when the essential checks have evidence and you can explain the remaining limits.

Let's ship, but first review the core user journey in this repo.
Find the routes and data rules it depends on. Choose one failed
or untested check, propose the smallest fix, and specify the
allowed and denied behavior to verify. Separate code work from
provider settings. Report the evidence and anything still untested
before calling this production-ready.

I vibe coded an app. Now what?

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

What should I check before launching an AI-built app?

Verify sign-in and permissions, data access, payments if applicable, secrets and production configuration, the core product task, monitoring and recovery. Record each check as verified, failed or not tested, with the deployment and evidence you used.

Is VibeRaven a security audit?

No. VibeRaven can surface some launch risks from repo evidence, but it does not replace a security review, penetration test, or compliance audit, and it does not test the live database.

Does VibeRaven change my code?

The check reads repo evidence and writes local .viberaven findings and tasklist artifacts. It does not apply a code fix or change provider settings. A separate fix command or your coding agent can make a code change after you choose the task.