Vibe-Coded App Production Checklist: What to Fix Before Real Users

You built the app in Lovable, Bolt, Replit or Cursor. It works, early users like it, and now real customers, real payments or an investor's due diligence are on the way. Prompt-to-app builders and SI coding tools are good at producing software that runs. They are less dependable on the parts a demo never shows: who can read which data, where secrets live, and how you recover from a bad migration.

This checklist is for founders and product leads deciding what to fix before launch and what can wait. It is ordered by the damage each gap can do, not by how hard it is to fix.

What breaks first when a vibe-coded app meets real users?

The failures that hurt are rarely exotic. Most are access control problems: one user can read or change another user's records because the check happens in the browser, or not at all. OWASP ranks broken access control first in its Top 10 for 2025. The rest are operational: backups nobody has restored, no alerts, one environment that is both playground and production, and accounts owned by whoever signed up first.

What should I check before launching a vibe-coded app to real users?

Start with data access: confirm every permission check runs on the server or in the database, and test it by signing in as one user and requesting another user's records. Then move every secret out of the browser code and rotate any key that was exposed. Verify payment webhook signatures and handle duplicate events. After that, turn on backups and test a restore, add error alerts, separate development from production, and make sure the company owns the code repository and every account.

1. Is authorization enforced on the server, not just in the interface?

Generated front ends often hide a button or a page from users who should not see it, and stop there. Hiding is not enforcement. Anyone can open the browser's developer tools, copy the requests your app makes, and replay them with a different record ID. OWASP's guidance is to deny by default and enforce access control in trusted server-side code. Lovable's own security guidance agrees: frontend code should never make security decisions.

• Sign in as user A, copy a request that loads one of A's records, and change the ID to one of user B's. You should get nothing back.
• Repeat the request as a signed-out visitor.
• Check that every server function and API route confirms who is calling and whether they may perform that action on that record.
• Look at how admin rights are stored. If "is admin" is a field users can edit on their own profile, anyone can promote themselves.

2. Is the database protected row by row?

Many of these tools use Supabase as the backend, and the browser talks to the database directly through Supabase's Data API with a publishable key that ships inside your app. Supabase's production security checklist is blunt: a table without Row Level Security (RLS) and reasonable policies lets any client read and change its data. Tables created in the Supabase dashboard have RLS on by default. Tables created with SQL, which is how most generated migrations run, need it enabled explicitly.

Run Supabase's Security Advisor before launch. It flags public tables without RLS, tables with RLS but no policies, and views that bypass policies. Then check file storage: files in a public Supabase bucket are publicly accessible, so invoices, ID scans and contracts belong in a private bucket with policies.

3. Where do your secrets live?

Prompt-to-app builders make it easy to paste an API key into a chat and have it wired up for you. Check where it landed. Lovable's documentation says secrets stored in frontend code are visible to users and should be considered compromised.

• Search the built JavaScript bundle, not only the source, for the key prefixes of your payment, email and LLM providers.
• In Supabase, the publishable key (the legacy anon key) is designed to be public. A secret key (the legacy service_role key) bypasses every RLS policy and belongs only in server code. Disable legacy keys you no longer use.
• Check the git history. A key removed in a later commit is still in the repository. Rotate any key that has ever sat in client code, a chat transcript or a public repository.
• Use the platform's secret store, such as Replit Secrets, Lovable Secrets or your host's environment variables, and check who can see the values. Replit's docs note that project collaborators can see secret names and values.

4. Do payments survive retries, duplicates and forgeries?

Generated payment flows usually handle the happy path: checkout succeeds, the webhook arrives, the account is upgraded. Stripe's webhook documentation spells out what production adds, and the same ideas apply to other providers.

• Forgery: verify the signature on every webhook with the endpoint's signing secret, using the raw request body. Otherwise anyone who finds the URL can post a fake "payment succeeded" event.
• Duplicates: Stripe says an endpoint might receive the same event more than once. Record processed event IDs and skip repeats.
• Ordering: Stripe does not guarantee events arrive in the order they were generated.
• Source of truth: grant paid access from a verified webhook or a server-side lookup, never from a redirect to a success page a user could open directly.
• Separation: test and live mode use different endpoint secrets. Keep test keys out of production.

5. Can you recover from a bad day?

If a migration drops a column or someone deletes the wrong records, what can you restore, to which point, and how long is the app unavailable meanwhile?

• Know what your plan includes. Supabase does not take automatic backups of Free plan projects and recommends regular exports with the CLI. Paid plans include daily backups, with retention that depends on the plan, and point-in-time recovery is an add-on.
• Files are separate. Supabase's database backups do not include objects stored through the Storage API.
• Restores mean downtime. Supabase says the project is inaccessible while a restore runs.
• Restore once into a scratch project before launch. A backup nobody has restored is a hope, not a plan.

6. Will you know when something is wrong?

Many generated apps go live with no error tracking, so the first sign of trouble is a customer email. The minimum is modest.

• Error tracking on the front end and the server, with alerts that reach a named person.
• An uptime check on the core journey: sign in, the main action, checkout.
• A record of who did what for sensitive actions, kept free of passwords, tokens and personal data you do not need. Our guide on what to log without storing personal data covers this for LLM features.
• The auth settings in Supabase's production security checklist: email confirmations on, a one-time password expiry of one hour or less, and a custom SMTP server.
• If the app calls an LLM, errors, latency and usage per feature, so a runaway loop shows up before the invoice does.

7. Are development and production separate?

Prompt-to-app projects often start as one project that is both test bench and live app, so every prompt is a change to production and every test sign-up lands in the real user table.

• A separate production database or project, with its own keys.
• Schema changes kept as migration files in version control and applied to a staging copy first. Supabase supports deploying from a connected GitHub branch, and branching on paid plans to test migrations before they reach production.
• Test data that is not copied from production, or is masked when it must be.
• A clear rule for who, if anyone, may prompt changes directly against production.

8. Does the company own the code and the accounts?

Nothing breaks on the day you skip this. It matters when you raise money, sell the company, hire an engineer or change tools.

• The repository lives in the company's GitHub organization. Lovable, for example, can two-way sync with a repository in the GitHub account you choose, and the repository stays there if you disconnect.
• Database, hosting, domain, payment, email and LLM provider accounts are in the company's name. Supabase recommends more than one organization owner and multi-factor authentication; apply the same rule everywhere.
• A short runbook for running, deploying and restoring the app.
• A signed assignment of intellectual property from any freelancer or agency who touched the code.

What should you fix first?

1. Close data access holes: server-side checks and database policies, tested as two users and a signed-out visitor.
2. Rotate exposed secrets and move them to server code.
3. Verify webhook signatures and make payment handling safe to repeat.
4. Turn on backups and complete one test restore.
5. Add error tracking and alerts.
6. Separate development from production.
7. Move code and accounts into the company's name.

The first three are launch blockers. The rest can follow soon after launch, provided someone owns each item and it has a date.

Should you rebuild or harden?

Usually harden. Rebuild when the data model itself is wrong, or when every fix breaks something else. Otherwise, fixing the gaps in place ships sooner and keeps what users already like. A custom software review should tell you which case you are in before anyone rewrites anything.

A vibe-coded app is often a good proof of concept, and moving it to production is a stage with its own exit criteria, as we set out in what each stage must prove. If you are inheriting an app someone else built, the questions in how to evaluate a vendor's demo apply just as well.

Where Octalcode fits

Octalcode is a studio in Lahore, with a US presence in Austin, that builds custom software, LLM applications and SI agents. Our custom software team takes apps started in prompt-to-app builders and SI coding tools and hardens them for real users, working through the order above.

This list is written so you can work through it yourself. If you would like a second pair of eyes on the result, get in touch. We sign an NDA before we see any code or data, and we reply to enquiries within 24 hours.