All posts
Product design

Vibe Coding to Production: The 40-Point Launch Checklist

A 40-point vibe coding production checklist: auth, row-level security, secrets, payments, errors, backups, limits, analytics, legal pages and accessibility.

By Mehdi Hassan9 min read

The short answer

A vibe coding production checklist covers what AI builders skip: server-side auth checks, row-level security on every table, secrets kept out of the browser, verified payment webhooks, error tracking, tested backups, rate limits, analytics, legal pages and accessibility. Work through security and payments first, because those failures hurt users and cost money.

Key takeaways

  • Test access as two ordinary users trying to read each other's data, never only as yourself or an admin.
  • Anything prefixed VITE_ or NEXT_PUBLIC_ ships to the browser, so no secret key belongs there.
  • Plan status comes from verified payment webhooks, never from the checkout success page.
  • A backup you've never restored is a hope, not a backup.
  • Split the 40 points by owner: security and payments to a developer, the rest can be shared.

Part of MVP Design and Development: The Founder's Guide to Building Version One

What belongs on a vibe coding production checklist?

A vibe coding production checklist covers the layers AI builders handle least reliably: who can see what, where secrets live, how money moves, what happens when things fail, and the legal and accessibility basics. The happy path usually works already. This list is about everything around it.

The 40 points below are grouped so you can hand each group to one owner. Points 1 to 19 need someone who reads code. The rest a founder can check with a developer's help. Where this sits in the bigger build process is in our MVP design and development guide, and if the app already has known problems, rescuing a vibe-coded app covers the repair order.

Security: auth, data access and secrets

Security is the first section because it protects users right now and is invisible until it fails. Check these 14 points before anyone outside your team signs up.

Authentication (1–5)

  • 1. Server-side session checks. Every route and API call that returns private data checks the session on the server. A client-side redirect is not protection.
  • 2. Roles enforced on the server. Permissions are checked in server code or database policies, not by hiding buttons. Test with your lowest-privilege role.
  • 3. Account flows tested end to end. Sign-up, email verification, password reset and invites, including expired and reused links.
  • 4. Sign-in protection. Rate limits or bot protection on sign-in, sign-up and reset, and leaked-password checks if your auth provider offers them.
  • 5. Account deletion. Users can delete their account, and their data is removed or anonymized as your privacy policy says.

Data access and row-level security (6–10)

  • 6. Row-level security on every table. On Supabase, tables exposed through its API need RLS turned on with policies. Supabase's Security Advisor and Lovable's security scan both flag tables without it.
  • 7. Policies for every operation. Select, insert, update and delete each need a policy. Update policies should also check the new row, so users can't hand a record to someone else.
  • 8. The two-user test. Sign in as two ordinary users and try to read and edit each other's records through the API directly.
  • 9. Private file storage. Uploads sit in private buckets with access policies. Public URLs only for files meant to be public.
  • 10. Views and functions reviewed. Postgres views and security-definer functions can bypass RLS. Check each one runs with the caller's permissions or filters deliberately.

Secrets and configuration (11–14)

  • 11. No secrets in the browser. Environment variables prefixed VITE_ or NEXT_PUBLIC_ are bundled into client code. Supabase's publishable key is safe there; its secret or service_role key bypasses RLS and must stay server-side.
  • 12. Rotate anything exposed. Any key ever pasted into a prompt, committed to the repository or shipped to the browser gets rotated.
  • 13. Separate environments. Development and production use different databases and keys, including Stripe test and live keys.
  • 14. Third-party calls on the server. AI providers, email services and other paid APIs are called from server functions, with keys kept there.
How to run the two-user test in 15 minutes

Create two ordinary accounts, A and B. As B, create a few records. As A, open the browser's developer tools, watch the network requests the app makes, and copy one that fetches a record. Change the ID to one of B's records and send it again. Then try the same with an update and a delete.

If any of those succeed, your access rules are wrong, and that's the first thing to fix. Repeat for file uploads and for any admin-only screen, signed in as a non-admin.

Payments: is your billing production-ready?

Billing is production-ready when your payment provider is the source of truth and your app handles every subscription state, not only a successful checkout. These five points apply to Stripe and most other providers.

  • 15. Verified webhooks. Every webhook's signature is verified using the raw request body and the endpoint's signing secret.
  • 16. Plan status from webhooks. Access is granted when the server records a confirmed payment event, never because the browser reached a success page.
  • 17. Duplicates and order handled. Stripe doesn't guarantee event order and can deliver an event twice, so store processed event IDs and fetch the latest object when in doubt. In live mode it retries failed deliveries for up to three days.
  • 18. Every state designed. Trial ending, card declined, past due, downgrade, cancellation and reactivation each have a screen or email, plus a way for users to manage billing.
  • 19. Live mode switched over. Live keys, a live webhook endpoint with its own signing secret, live products and prices, and one real low-value purchase refunded.

Errors, backups and environments

A production app fails visibly: errors reach the team, data can be restored, and changes are tested before real users see them. These five points cover the minimum.

  • 20. Error tracking. Front-end and server errors go to an error tracker with enough context to reproduce them, without logging passwords or payment data.
  • 21. Uptime alerts. The app and its core API are monitored, and alerts reach a person who will act on them.
  • 22. Backups that exist. Confirm what your plan includes. On Supabase, daily backups come with the Pro, Team and Enterprise plans; free projects should export their data regularly.
  • 23. One restore rehearsed. Restore a backup to a separate project at least once, so you know how long it takes and that it works.
  • 24. Staging and an audit trail. A staging copy for testing changes, and logs of key actions such as sign-ups, payments and deletions.

Performance, rate limits and AI costs

Performance and limits keep one user, one bot or one slow query from taking the app down or running up your bill. Check these four before you announce the launch.

  • 25. Rate limits on costly endpoints. Especially AI calls: per-user limits and a spending cap with your provider. Our guide to building AI features in a web app covers cost control.
  • 26. Indexes where you filter. Index the columns your queries and RLS policies filter on, such as user or organization IDs.
  • 27. Pagination. Lists load in pages, and no screen fetches a whole table.
  • 28. Speed on a real phone. Test the landing page and core screen on a mid-range phone and mobile network. Our web app performance checklist goes deeper.

Analytics tell you whether launch worked, and legal pages tell users what you do with their data. Both are quick to set up and awkward to add after real users arrive.

  • 29. Core flow events. Track each step of the main flow and one activation event that means a user got value.
  • 30. Events verified in production. Check events fire on the live site, and filter out your own team's traffic.
  • 31. Consent respected. Where consent is required, such as for EU visitors, analytics and marketing tags wait for it.
  • 32. Privacy policy that matches reality. It names the kinds of data you collect and the processors you use: database host, AI provider, analytics and email.
  • 33. Terms of service. Including refund and cancellation terms if you charge.
  • 34. Cookie notice. A banner or notice where the law requires one, with a real option to decline.
  • 35. Data requests. A way for users to ask for a copy or deletion of their data, and a person who handles it. For health or financial data, get legal advice.

Accessibility and UX finish

Accessibility and UX finish decide whether people can use the product and trust it. These five points catch what AI-generated interfaces most often miss.

  • 36. Keyboard use. Every action works with a keyboard, and focus is always visible.
  • 37. Labels and contrast. Every input has a label, and text meets the WCAG AA contrast ratio of 4.5:1 for normal text. Our accessible web app checklist covers the rest.
  • 38. Empty, loading and error states. Each core screen has all three, written in plain language.
  • 39. Email that arrives. Transactional email sends from your own domain with SPF, DKIM and DMARC set up, and lands in the inbox, not spam.
  • 40. The basics of a real site. Custom domain with HTTPS, page titles, a favicon, a helpful 404 page and social preview images.

How should a founder split the launch checklist work?

Split the checklist by owner and run it in risk order: a developer takes security and payments, the founder takes analytics, legal and UX finish, and both review errors and performance. Nothing ships to real users until points 1 to 19 pass.

  1. Freeze features

    No new features while the checklist runs, so you're checking a stable app. Our MVP scoping guide helps decide what waits.

  2. Security and payments first

    Points 1 to 19, by someone who reads code. Fix failures before moving on.

  3. Reliability next

    Points 20 to 28: error tracking, backups, a restore, limits and speed.

  4. Founder pass

    Points 29 to 40: analytics, legal pages, accessibility and finish.

  5. Launch small

    Invite a small group first, watch errors and analytics, then open the doors.

Our MVP design service explains how the trial week works. If the checklist turns up more than a week of work, you've likely outgrown the builder; vibe coding vs hiring a team explains what to do next.

Frequently asked questions

Does Lovable's security scan replace this checklist?
No, but use it. Lovable runs a quick scan at publish that flags database access problems and vulnerable dependencies, and offers a deeper code scan on demand. Automated scans catch common issues; they can't confirm your roles match your business rules or that billing handles every state. Treat the scan as a first pass and still run the two-user test.
Can I launch a vibe-coded app without a developer?
You can launch a free beta without one if no sensitive data is stored and nobody pays. Once you take payments or store personal data, have someone who reads code check authentication, access rules, secrets and webhooks. Those are the points where a mistake exposes users or loses money, and they're hard to judge from the interface.
Is the Supabase anon or publishable key safe to expose?
Yes, if row-level security is on and your policies are correct. Supabase designs the publishable key, and the older anon key, to be used in browser code, and it can only reach what RLS allows. The secret key and the older service_role key bypass RLS entirely, so they must never appear in front-end code or a public repository.
What error tracking should a small app use?
Any established error tracker that captures front-end and server errors with stack traces and the affected user works. Pick one with a free tier, connect it to both the browser and your server functions, upload source maps so errors point to real code, and route alerts to a channel someone reads. The tool matters less than someone acting on alerts.
How often should I rerun the checklist?
Rerun the security and payments sections whenever you add a table, a role, an integration or a pricing change, and the whole list before any big launch. AI builders can change access rules and components as a side effect of unrelated prompts, so a quick two-user test after major changes is worth making a habit.

· CEO & Design Director

Copywriter, designer and developer, and founder of Designify Studio. Over five years, 60+ projects across 14+ industries, for startups that have raised $300M+.

Not sure yet? Try a week together.

One week of design and development, so you can see how we work before you commit. $1,000, fixed.

Schedule Call