Before you launch that vibe-coded app

If you are building with Lovable, Base44, Replit, Bolt, Cursor, Claude Code, Codex, or any other AI-assisted tool, the goal is not to stop vibe coding. The goal is to know when a fast prototype has crossed the line into a product that can hurt users, lose revenue, or block your next build decision.

A landing page with fake data is a prototype. A product with real users, authentication, private data, payments, email flows, admin access, and production deployment is a different responsibility.

That is the line this checklist is for.

We already wrote about the hidden costs of vibe-coded products, the Homer Simpson MVP problem, and how to audit an AI-generated codebase before scaling. This article is more tactical: what should a vibecoder check before letting real users depend on the app?

The rule: the screen finishes before the system does

Vibe coding makes the visible layer appear early. Buttons work. Pages load. The dashboard looks real. The demo feels convincing.

But the invisible parts often decide whether the product is safe to launch:

• who can access which data
• what happens when payment fails
• where secrets are stored
• how the database represents ownership
• whether production can be rolled back
• whether the team can debug a broken user journey

That is why this checklist is not about adding more features. It is about checking the invisible product before the visible product makes a promise.

If you use Lovable, Base44, Replit, or similar platforms

These platforms are great for speed, but speed can hide ownership gaps. Do not only ask the platform to build the next screen. Ask it to explain the system it already created.

Useful prompts:

• "Show me every place where secrets, API keys, tokens, or service role keys are stored. Tell me which ones are exposed to the browser."
• "Explain how routes are protected. Which checks happen only in the UI, and which checks happen on the server?"
• "Map the database tables and explain who owns each record. Show me how one user is prevented from reading another user's data."
• "List every payment event this app handles and every payment event it ignores."
• "Tell me how to push this project to GitHub and what files should not be committed."
• "Create a production readiness checklist for auth, payments, database, environment variables, and rollback."

If the answer is vague, that is the signal. A real product needs more than generated screens; it needs a system you can explain.

1. Authentication: do not invent your own login system

Authentication is where many AI-built apps look fine on screen and fail in the details.

If your app has accounts, private dashboards, subscriptions, admin panels, client portals, or any user-specific data, you need authentication that is boring, standard, and hard to accidentally bypass.

Use a trusted provider or a mature framework. Supabase Auth, Clerk, Auth0, Firebase Auth, Cognito, NextAuth, and similar tools exist for a reason. The risky move is asking the AI to "build login" from scratch and accepting whatever token, cookie, password, or session logic it invents.

Before launch, check:

• Can a user access another user's data by changing an ID in the URL?
• Are admin routes protected on the server, not only hidden in the UI?
• Are sessions expired properly after logout?
• Are password reset links single-use and time-limited?
• Are roles explicit, for example user, admin, owner, or support?
• Can a deleted, downgraded, or unpaid user still access private areas?

The most important rule: the UI is not security. Hiding a button does not protect a route. Disabling a menu item does not protect an API endpoint. Every permission that matters must be enforced by the backend or database policy.

Quick recipe: auth sanity check

1. Create two normal users.
2. Create private data with user A.
3. Log in as user B.
4. Try to access user A's record by changing the URL, request body, or ID.
5. Repeat the same check for admin screens and paid features.

If user B can see or modify anything that belongs to user A, stop and fix authorization before launch.

2. Security: secrets, permissions, and server-side validation

A common vibe-coded failure is putting secret keys where the browser can see them. If an API key, service role key, webhook secret, private token, database credential, or payment secret appears in frontend code, it is not secret anymore.

Before launch, search for secrets in:

• frontend files
• .env examples
• generated config files
• public build output
• GitHub commits
• Replit or platform environment panels
• screenshots or copied prompts

Then check what the app trusts. AI-generated code often trusts the happy path: "the frontend sent a valid user ID, therefore it must be true." That is not enough. The backend should validate the user, the action, the input, and the permission every time.

Ask these questions:

• Does the backend validate required fields, types, formats, and limits?
• Are file uploads restricted by size, type, and destination?
• Are database writes scoped to the authenticated user or organization?
• Are public routes intentionally public, or just accidentally exposed?
• Are third-party callbacks verified before they update your database?

Security does not need to be dramatic. Most early product risk comes from simple mistakes: exposed credentials, weak permissions, missing validation, and generated code that assumes nobody will try the wrong URL.

Quick recipe: secret exposure check

Ask your AI tool or coding agent:

Search the codebase for API keys, service role keys, database URLs, webhook secrets, payment secrets, and private tokens. Split the results into safe server-side usage and unsafe browser-exposed usage. Explain what must move to environment variables or backend-only code.

Then manually check the public build output and GitHub history. Secrets are not safe just because you deleted them from the latest file.

3. Database: your data model is your product memory

AI tools are very good at creating tables quickly. That does not mean the model represents your business correctly.

A fragile database usually shows up later as product confusion: duplicate users, missing ownership, orphaned records, subscriptions that do not match accounts, projects with no owner, deleted entities that still appear in reports, or dashboards that cannot answer basic business questions.

Before launch, map the core objects in plain language:

• Who owns this record?
• Can it belong to a team, company, workspace, or only one user?
• What happens when the owner is deleted?
• Which records are private, shared, archived, or public?
• Which status values exist, and what do they mean?
• What data must never be deleted without a backup?

For many MVPs, a simple model is enough. But it has to be intentional. If the AI created five similar tables because every prompt added a new feature, stop and simplify before real usage makes cleanup painful.

Also check backups and migrations. If you cannot explain how to restore the database after a bad deploy, accidental deletion, or platform mistake, you are not ready to treat the app as production.

Quick recipe: database ownership map

Create a small table with four columns:

Data	Owner	Who can read it?	Who can change it?
User profile	User	User, admin	User, admin
Subscription	Account/workspace	Owner, admin	Payment webhook, admin
Project/client record	Workspace	Workspace members	Owner, editor

If you cannot fill this out, the backend probably cannot enforce it consistently.

4. Payments: redirects are not confirmation

Payment integrations deserve their own pillar because they connect revenue, user access, support, analytics, and backend behavior.

If you use Stripe, PayPal, Mercado Pago, Lemon Squeezy, Paddle, or another provider, do not treat a successful redirect as proof that the payment is complete. A redirect only tells you that the user came back to your app. It does not reliably prove that the provider captured the payment, that the subscription is active, or that the event was recorded correctly.

Use webhooks for payment confirmation.

A safe payment flow usually needs the backend to receive provider events and update your internal state from those events. For example:

• payment completed
• payment failed
• payment pending
• subscription created
• subscription renewed
• subscription canceled
• invoice failed
• refund issued
• dispute opened

Then your app should translate those events into product state:

• user registered but not paid
• user paid but onboarding incomplete
• user subscribed and active
• user payment pending
• user subscription past due
• user refunded or canceled
• user should lose access after grace period

This is where bad vibe-coded payment flows create expensive bugs. You can end up with users registered but no payment record, paid users without access, free users with paid access, failed payments that still unlock features, or missing revenue events that break reporting.

Test more than the happy path:

• successful checkout
• failed card or failed payment method
• delayed or pending payment
• user closes the browser before returning to your app
• webhook arrives before the redirect
• redirect arrives before the webhook
• duplicate webhook event
• refund
• chargeback or dispute
• subscription cancellation
• plan upgrade or downgrade

Two rules matter a lot:

1. Verify webhook signatures. Do not trust random HTTP requests that claim to be payment events.
2. Make fulfillment idempotent. If the same payment event arrives twice, the backend should not grant access twice, create duplicate records, or corrupt subscription state.

If payments affect access, your product should have a clear source of truth for entitlements: what the user is allowed to do right now, and why.

Quick recipe: payment confirmation flow

1. Create the user as registered, not paid.
2. Send the user to checkout.
3. Wait for a verified webhook from the payment provider.
4. Store the provider event ID and payment/subscription ID.
5. Update the internal entitlement state once, even if the event arrives twice.
6. Let the UI read access from your internal entitlement state, not from the redirect URL.

This prevents the classic bug: a user exists in your app, but the backend does not know whether they paid, failed, canceled, refunded, or are still pending.

5. Testing: prove the product survives more than the demo

Vibe-coded apps often pass the demo because the demo follows exactly the path used while prompting. Real users do not.

Testing does not need to start as a giant QA department. Start with a launch checklist that proves the critical flows:

• sign up
• log in
• log out
• reset password
• create the main business object
• invite a teammate if teams exist
• pay or subscribe if payments exist
• access paid features
• cancel or downgrade
• submit the most important form
• receive the most important email
• see a useful error when something fails

For every critical flow, test three versions:

1. Happy path: everything works.
2. Permission failure: the wrong user tries the action.
3. Interrupted flow: the user refreshes, closes the tab, retries, or comes back later.

If you are using Claude Code, Codex, Cursor, or another coding agent, ask it to write tests before asking it to change major behavior. Tests give the agent a boundary. Without tests, the agent can fix one screen and break another without noticing.

Quick recipe: first test suite

Ask your agent:

Identify the five product flows that would create the most user or revenue damage if they broke. Write tests for those flows before changing implementation code. Include one permission failure and one interrupted-flow case for each.

Do not start with 200 tests. Start with the flows that would make you lose trust, money, or data.

6. GitHub: do not let the platform be the only copy of the product

If your product lives only inside Lovable, Base44, Replit, or another platform, you may be moving fast, but you do not fully control the product yet.

Put the project in GitHub as early as possible.

A basic repository should include:

• source code
• README with setup instructions
• environment variable list without secret values
• notes about the stack and providers
• clear commit history
• issues or tasks for known gaps
• branches or pull requests for risky changes

GitHub is not just for developers. It gives you ownership, history, rollback options, and a way for future technical partners to understand what changed and why.

The habit is simple: before a big prompt session, commit. After a meaningful change, commit. Before letting an AI agent refactor, commit. If the output is bad, you can go back.

Quick recipe: minimum README

Your README should answer:

• What does this product do?
• How do you run it locally?
• Which services does it depend on?
• Which environment variables are required?
• How do auth, payments, and database access work at a high level?
• What is known to be unfinished or risky?

A future developer should not need to reverse-engineer the product from prompts.

7. Deploy and environments: separate experiments from production

One of the most dangerous patterns in AI-assisted building is editing production directly. It feels fast until one prompt breaks the app users are actually using.

At minimum, separate:

• local or preview environment for experiments
• staging environment for testing
• production environment for users

Each environment should have its own variables, provider keys, database, webhook endpoints, and payment mode. Stripe test mode should not touch production entitlements. PayPal sandbox events should not update real users. A staging database should not email real customers unless you explicitly intend it.

Also decide how you roll back. If a deploy breaks authentication, payment access, or core data creation, what is the fastest safe way to restore the previous version?

Quick recipe: production boundary

Before launch, write down:

• production URL
• production database
• production payment mode
• production webhook endpoint
• deploy command or platform
• rollback process
• who has admin access

If staging and production share the same keys or database by accident, fix that before users arrive.

8. Observability: know when something breaks

If a user reports "I paid but I cannot access my account," you need more than vibes to debug it.

Before launch, make sure you can see:

• app errors
• failed API requests
• payment webhook events
• user registration events
• subscription or entitlement changes
• form submissions
• important conversion events
• deploy history

This does not need to be complex. Start with logs, analytics, and a small set of product events. The key is that every critical workflow should leave a trace.

For payments, log the provider event ID, internal user ID, account or workspace ID, payment status, and entitlement change. That way, when something goes wrong, you can reconstruct what happened.

Quick recipe: support debugging trail

For every critical event, store enough context to answer:

• Who did it?
• What happened?
• When did it happen?
• Which provider event or API request triggered it?
• What changed in the user's access or data?

This is the difference between fixing a support issue in ten minutes and guessing for two days.

9. If you use Claude Code or Codex, treat the agent like a fast junior team

Claude Code, Codex, Cursor, and similar tools can be incredibly useful when the project has structure. They become risky when the repo is messy, the prompt is vague, and there are no tests.

Use this workflow:

• Start from a clean Git state.
• Explain the goal and the acceptance criteria.
• Ask the agent to inspect before editing.
• Keep changes small.
• Ask for tests or update existing tests.
• Review the diff before accepting.
• Run the app and the test suite.
• Commit only when the result is understandable.

Do not ask an agent to "fix the whole app" in one pass. Ask for one subsystem, one bug, one flow, or one refactor at a time.

And be especially careful with auth, database migrations, payment logic, permissions, and production config. Those are not good places for blind trust.

Useful prompts for coding agents

• "Inspect this codebase first. Do not edit yet. Tell me how auth, payments, database access, and deployment are structured."
• "Find places where the frontend appears to enforce a rule that the backend does not enforce."
• "Before changing this feature, write or update tests for the current expected behavior."
• "Review this diff as if you were looking for security, data loss, payment, and permission bugs."
• "Make the smallest safe change. If a larger refactor is needed, propose a plan before editing."

The best agent workflow is not magic. It is small changes, clear acceptance criteria, tests, and review.

The practical launch rule

If the app is only helping you validate a concept, move fast. Use AI aggressively. Build the clickable version. Learn from users.

But if the app has any of these, slow down and audit:

• real users
• private data
• payments
• subscriptions
• admin access
• client dashboards
• production database
• third-party integrations
• investor or customer demos that imply reliability

The question is not whether the product was built with AI. The question is whether anyone checked the parts that AI tools are most likely to skip: authentication, security, database ownership, payment confirmation, tests, deployment, observability, and maintainability.

The objective is not to stop vibe coding. The objective is to stop your product from depending on luck, old prompts, hidden state, and assumptions nobody reviewed.

---

Further reading

• Stripe Checkout fulfillment and webhook guidance
• PayPal checkout webhook events
• PayPal webhook integration and verification
• OWASP Authentication Cheat Sheet
• OWASP Session Management Cheat Sheet