When is your vibe coded app ready to launch?

Getting something running on localhost:3000 is a great first step, especially if you aren't a professional software developer. Showing something cool on your laptop to your friends is one thing. Someone in Norway using it in a way you haven't thought of is another. They sign up at 3am your time, on a device you have never tested with, while you are asleep.

Your app is ready to launch when it handles the second situation without you there to watch it.

What ready to launch actually means

A "soft launch" might be you pushing your web app to Vercel or Lovable and sharing the link with a few friends. A true launch is when you decide you have something you want to share with the world and hope to make some money from.

Being ready to launch usually means:

• Your main feature works.
• You have a plan to get users.
• The app keeps working while you get on with your life.

Building features for no users is the easy part. Getting users through marketing and sales is a separate challenge, and not one this site covers. Building and maintaining the software is what we know.

A launch-ready app can be used 24/7 by people you have never met. It works for them almost all of the time. When something goes wrong, you know about it quickly and you can fix it quickly. The fixes that you make don't unexpectedly break something else. You know how people are using your product without having to ask them.

If your app goes viral and 10,000 people sign up in 3 days, they can all sign up, pay their subscription and use it with the same quality as when you had 10 users.

If your app is already live, the same goes for any day strangers arrive faster than before, like a Product Hunt post or the day you start paying for ads.

Developers call a launch-ready app "production ready". Production is the live copy of your app, the one your users see. Your AI coding tool uses the phrase too, so it helps to know what it means.

You can't see any of this in a demo to a friend. It shows up once strangers arrive, in four places.

Four things to check before you launch

Each of these is hard to get right by hand, one change at a time. Each gets much easier once a system does the checking for you: something you set up once that then runs on every change and every signup.

Your users' data stays safe

Imagine the headline is "Vibe Coder's Cool App Hacked". What data would the attacker have? Is there enough to open a credit card in your customers' names?

Apps built with AI tools tend to leak or lose data through the same few holes:

• A secret key for OpenAI, Anthropic or Stripe sits in the code your site sends to the browser. Anyone who opens their browser tools can copy it and run up your bill.
• The .env file holding your keys was committed to GitHub. Deleting the file later does not remove the key from the git history, so the only fix is a new key.
• A logged-in user changes /orders/123 to /orders/124 in the address bar and sees someone else's order. The server checked that they were logged in, but not that the order was theirs.
• The database has never been backed up. Or you think it is, but the backup is quietly failing, or it works and you don't know how to restore it. Either way, you are no better off than with no backup at all.

What helps:

• Keep secret keys on the server, in your host's environment settings (Vercel, Netlify and Railway all have one). Your server calls OpenAI or Stripe, so the browser never sees the key.
• Put .env in .gitignore, and add a secret scanner that catches a key before it reaches GitHub (gitleaks, or GitHub's own secret scanning).
• Check who owns a record on the server, on every request that reads or changes one. If your app uses Supabase, Row Level Security policies do this. Every table needs them.
• Turn on automated backups for your database, then restore one into a spare database once to prove it works. Check whether your host includes backups on your plan.
• Store only what you need. If you don't need a date of birth, don't ask for one: data you never collected can't leak. If a piece of data could help someone open a credit card in your customer's name, ask whether you need it.

Check yours: Where do your secret keys live? Has your .env file ever been committed? Could a user see someone else's data by changing a number in the address bar? Could you restore your database today?

It still works when a lot of people turn up

What happens when you have 100,000 users? When your database grows to 100,000,000 rows, does your page still load in under a second? If 5,000 people are using the app at the same time, does it still work, or are they looking at a cool spinner you spent 10,000 tokens to get Claude to build?

A page that is fast with 50 rows of test data can take 30 seconds with 5 million. The usual cause is a missing database index: without one, the database reads every row to find the few you asked for. Think of a library where the books are in no order. With 20 books, you can find any of them in a second. With 20,000, you will be there all day. An index is the catalogue that tells you which shelf to look on.

High load can also mean a high bill for you. If someone writes a script that signs up fake accounts and uses your expensive AI feature 10,000 times overnight, every one of those AI calls costs you money. Nothing stops them if you don't have any limits.

What helps:

• Add an index to every column your app searches, filters or sorts by. Ask your AI tool to list the queries behind your slowest pages and check each one has an index.
• Show long lists a page at a time. A list that loads every row works at 100 rows and times out at 100,000.
• Rate limit signup, login and anything that calls a paid API, so one person can only make a set number of requests a minute (Vercel's firewall, Cloudflare or Upstash Ratelimit).
• Set a monthly spend limit or a budget alert in your AI provider and cloud accounts. A limit turns a surprise bill into an email.
• Optional: before launch day, load test the app with a tool like k6 or Artillery to see where it slows down first.

Check yours: If someone scripted your signup or a paid feature 10,000 times tonight, what would stop your bill?

New features don't break old ones

You spent a week building the new feature your users had been asking for. You release it, and it breaks something else you didn't expect.

While the app is small, you catch this by clicking through every screen after each change. That stops working around the time you have 40 screens and ship twice a day. AI tools also change files you didn't ask them to touch, so the break is often somewhere you would never think to click.

What helps:

• Protect your main branch, the copy of your code that your live app is built from. Once it is protected, every change has to arrive as a pull request: a proposed change that gets checked before it goes live.
• Run the build, a type check and your tests automatically on every pull request. GitHub Actions covers most small projects inside its free allowance.
• Write end-to-end tests for the paths that make you money: signup, login and checkout. A tool like Playwright or Cypress clicks through them for you on every change.
• Try each change on a preview deploy, a private copy of the app at its own URL, before your users see it. Vercel and Netlify create one for every pull request.
• Know how to roll back. Most hosts can put the previous version back live in one click, which makes a broken release a two-minute problem.

Check yours: Can a change reach your live app without anything checking it first?

You know when something is wrong

Is your login page broken right now? Are users giving up at checkout because your payment step is broken? Is file upload failing? Is your API getting slower each week? Are users confused by a feature and giving up?

Most users won't email you to say so. They leave. If you only hear from the ones who write in, you hear about a small share of the problems, days late. A widely quoted customer service figure, credited to Lee Resources (opens in a new tab), puts it at 26 silent customers for every one who complains.

What helps:

• Error tracking alerts you the moment something breaks for a user, with the error and the page it happened on (Sentry, PostHog or Bugsnag). Most of these tools also record how long requests take, so you see the API slowing down before users give up on it.
• Uptime monitoring loads your key pages every few minutes and tells you when one stops responding (Better Stack, UptimeRobot or Checkly).
• Product analytics with funnels shows where people drop off between landing, signing up and paying (PostHog, Google Analytics or Amplitude). A sudden drop at one step is often a bug nobody reported.

Check yours: If the app broke for a user right now, would you find out before they emailed you? This is the 3am test.

Where vibe-coded apps usually sit

Spending a few days or weeks talking with Claude or Lovable can get you a pretty good app. It looks good, maybe even deploys to the world, and works how you need it to. You can create an account, do your cool thing and add the new features you need. If something breaks, you know, because you tried it and then you fixed it.

That works while you are the main user. It stops working once strangers are.

AI coding tools build what you ask for. You check what you can see. Almost nothing in the four sections above shows up on screen. A missing ownership check, a missing index, an untested backup and an error nobody is alerted to all look exactly like a working app, so the tool rarely builds them unless you ask.

That is the default output of the tools, not a mistake on your part. Most of it is a few days of setup. You only do it once.

Set up your AI coding tool before you launch

An AI coding tool starts each session knowing only your code and what you tell it. It is like Leonard, Guy Pearce's character in Memento: every new session remembers nothing of the last six months and looks at your code for the first time. So leave it notes it reads at the start of every session:

• An AGENTS.md file (or CLAUDE.md for Claude Code) at the root of your project, which your coding agent reads at the start of every session. Lovable has a project knowledge setting that does the same job. Put in it how to run the app and its tests, your conventions, and the things the tool must never do, like putting a secret key in browser code.
• Playbooks: your standards written out, one file per topic, such as security, database changes or testing. The tool builds to them and a reviewer checks against them. Your AGENTS.md points to them, so the tool reads the one it needs.
• Skills: saved step-by-step instructions for a job you repeat, such as adding a database table with its access rules, or shipping a release. The tool follows the same steps every time, including the ones it would otherwise skip.
• Code review on every change: a skill that runs after every change your AI tool makes. First the automated checks run (build, type check, tests), then the review skill reads your playbooks and fixes anything in the new code that breaks them.

Each of these is written once. After that it applies to every change, including the one you make at 1am to fix a bug before bed. The rules live in the project, where every session reads them.

How to tell if yours is ready

The Check yours questions above are most of the check. Our free quiz, Is your app safe to launch?, asks eight questions like these, takes about two minutes and needs no signup. Your result shows on screen with each gap named.

It sorts the questions into three groups:

• Security: leaked keys and exposed data.
• Scaling & cost: runaway bills and lost data.
• Coding & ops readiness: unreviewed changes and outages nobody notices.

Answer honestly. "Not sure" counts as a gap: if you can't say where your secret keys live, you can't rule out that they are in the browser.

Every gap it names has a fix in the sections above. Start with Security: a leaked key or exposed customer data is the gap that ends up in the headline.