Vibe Coding to Production: The Launch Checklist for AI-Built Apps

Why vibe-coded apps need a launch checklist

AI coding tools are excellent at producing something that works on the happy path in minutes. They are much less reliable at the unglamorous 20% that decides whether an app survives real users: security, failure handling, data protection and operations. A checklist closes that gap.

1. Secrets and configuration

• No API keys, tokens or database URLs in the repository or the browser bundle. Search the git history too.
• All secrets in environment variables on the host; separate values for development and production.
• Any key ever pasted into an AI chat is treated as exposed and rotated.
• A .env.example file documents required variables without values.

2. Authentication and authorisation

• Use a proven provider or library (Auth.js, Clerk, Supabase Auth, Firebase Auth); do not hand-roll password storage.
• Every API route checks the caller’s identity and their permission to touch that specific record.
• Admin routes are protected on the server, not merely hidden in the UI.
• Sessions expire; password reset and email verification flows work.

3. Data and database

• Row-level security (Supabase) or security rules (Firebase) are enabled and tested with a non-admin user.
• Automated daily backups, and you have actually tested a restore.
• Migrations are scripted; nobody edits the production schema by hand.
• Personal data is minimised, and you know where it is stored (important for GDPR, UK GDPR, PIPEDA, UAE PDPL and similar laws).

4. Input validation and abuse protection

• Server-side validation on every input (schema validation such as Zod or Pydantic).
• Rate limiting on login, signup, forms and any endpoint that calls a paid API.
• Spend caps and alerts on OpenAI/Anthropic/Google AI accounts.
• File uploads are type- and size-limited and stored outside the web root.
• Protection against prompt injection if the app feeds user or web content into an LLM that can take actions.

5. Reliability and observability

• Error tracking (Sentry or equivalent) and structured logs.
• Uptime monitoring with an alert to a real person.
• Health-check endpoint; graceful handling of third-party API failures and timeouts.
• Load tested at a realistic level, not just clicked through once.

6. Deployment and ownership

• One-command or push-to-deploy pipeline with a rollback path.
• Production, staging and local environments are separate.
• Domain, DNS, hosting and database accounts belong to the business, with 2FA and a recovery contact.
• A one-page runbook: where things live, how to redeploy, how to restore.

7. SEO, AEO and legal basics (often forgotten)

• Public pages are server-rendered or pre-rendered, with unique titles, descriptions, canonical tags and a sitemap.
• robots.txt does not accidentally block search or AI crawlers you want; see LLM-friendly websites.
• Privacy policy, terms, cookie consent where required, and analytics configured (for example the Google tag).
• Accessibility basics: contrast, labels, keyboard navigation.

A worked example: what a 2-day hardening pass looks like

Take a typical founder-built app: a Next.js front end, a Supabase database, Stripe checkout and an OpenAI-powered feature, generated mostly with an AI coding tool. A focused two-day pass usually goes like this.

• Hour 1–3, discovery: run the app, map every route and data table, list every third-party key and where it lives.
• Hour 3–8, security: rotate keys found in the repo, move calls to the OpenAI API behind a server route with per-user rate limits, switch on row-level security and write policies, test them as a normal user and as an anonymous visitor.
• Day 2 morning, reliability: add input validation on forms, handle Stripe webhook retries idempotently, add Sentry and an uptime monitor.
• Day 2 afternoon, delivery: set up preview and production environments, automate deployment, run a smoke test of signup, payment and the core feature, write the runbook.

The result is not a perfect system, but one where the common ways of failing publicly have been closed and you can see problems when they occur.

How to test an AI-built app yourself in 30 minutes

1. Open the site in a private window and try to reach pages and API URLs you should not see when logged out.
2. Log in as user A, copy a record URL or ID, log in as user B and try to open it. If it opens, authorisation is broken.
3. Open browser developer tools, search the loaded JavaScript for “sk-”, “key”, “secret” and your database URL.
4. Submit forms with very long text, special characters and empty values.
5. Click the main action ten times quickly. Does it create duplicates, crash, or run up a paid API bill?
6. Turn off the network mid-action and see what the user experiences.

Frequently asked questions

Related guides