Before You Ship Your Lovable or Replit App: What to Check First

You built something real. In a few weeks, with Lovable or Replit or Cursor, you got further than most funded teams got in six months a decade ago. The demo works. People who see it say "this is great, when can I use it?"

Now you're about to find out that "works in the demo" and "survives real customers" are two different claims. Not because the tools failed you — vibe coding is genuinely the fastest way to validate an idea that has ever existed — but because the demo only ever tested one path: yours. You, on your laptop, on good wifi, clicking the buttons in the order you designed them, with data you entered yourself.

Real users don't do any of that. They arrive all at once, type things you never typed, click twice when the button is slow, and leave without telling you what broke.

This is a walkthrough of what actually changes when you launch, organized the way it will actually happen: by the first 30 days of traffic. Read it before you announce, not after.

What the demo hides

An AI-generated app is optimized to satisfy the person prompting it. That's the whole loop: you describe a behavior, the tool builds it, you check that it works, you move on. Every check happens under demo conditions — one user, clean data, the happy path.

What that loop never tests:

• What happens when the input is wrong. You always typed a valid email. You never pasted a 40,000-character string into the bio field.
• What happens when two things happen at once. You never clicked "buy" from two tabs, or had two users edit the same record in the same second.
• What happens when a third party fails. Your payment provider, email service, and database were all up every time you tested. In production, they won't be.
• Whether anyone can see what went wrong. In the demo, errors appear in your own browser. In production, they happen on a stranger's phone, silently.

None of this means the code is bad. It means the code is unverified against conditions it hasn't met yet. Launching is when it meets them — on a schedule, roughly like this.

Day 1: the traffic you invited

Launch day traffic is the traffic you asked for — a Product Hunt post, a LinkedIn announcement, an email to a waitlist. It's the friendliest traffic you'll ever get, and it still breaks things, because it's the first time more than one person has used the app.

The first thing it stresses is signup and auth. In the demo, you logged in as yourself. Now fifty strangers are creating accounts in the same hour. Common failure points in AI-built auth: password reset emails that were never wired up (you never reset your own password), verification flows that dead-end, sessions that never expire, and — the serious one — API routes that check whether a user is logged in but not whether it's the right user. That last one means customer A can read customer B's data by changing an ID in a URL. It's among the most common findings in vibe-coded apps, and it's invisible in a one-user demo by definition.

The second thing Day 1 exposes is error visibility — or the lack of it. When something fails on a user's device, one of two things happens: they email you, or they leave. Mostly they leave. If you have no error tracking, your launch metrics will show a drop-off and you will have no idea whether it's disinterest or a broken button. Those require opposite responses, and you can't tell them apart.

The Day 1 rule: you don't need the app to be perfect. You need to know when it isn't.

Week 1: the edge cases arrive

Survive the first day and the traffic changes character. These aren't launch-day well-wishers anymore. They're people trying to actually use the thing — and actual use is where edge cases live.

Payments first, because it's where mistakes cost money. AI tools integrate Stripe's happy path competently: user clicks pay, card succeeds, account upgrades. Week 1 delivers everything else. A card gets declined — does the user see why, or a blank screen? A user pays but closes the tab before the redirect — did your app record the payment, or does a paying customer now look free? A webhook arrives twice — do you grant the subscription twice, or charge twice? These branches exist in every payment system. Generated code often handles exactly one of them.

Then weird input. Real users paste rich text into plain fields, upload 200 MB files to a headshot uploader, put emoji in name fields, and submit forms with the back button. Each unhandled case is either a crash the user sees or — quietly worse — bad data your database now holds forever.

Then concurrency. Two users grab the last inventory slot at the same moment. One user double-clicks a slow submit button and creates two orders. In a single-user demo, "at the same time" cannot occur, so generated code rarely defends against it. Week 1 is when "cannot occur" stops being true.

The demo tested whether your app works when one person uses it correctly. Production tests whether it survives many people using it wrong, at the same time, while you're asleep.

Week 2–4: growth stresses the shape

If you're still standing after two weeks, congratulations — you have the good problems now. The failures stop being crashes and start being drag.

The app gets slow. AI-generated database queries are usually correct and rarely efficient. A dashboard that queries the database once per row is instant with your 10 test records and takes eight seconds with a customer's 5,000. Nothing "breaks." The app just gets slower every week, and users stop coming back without ever filing a complaint.

Changes get scary. Code generation tends to solve each prompt locally, so the same logic — how a price is calculated, how a permission is checked — ends up duplicated in several places. When you ask your AI tool for a change, it updates some copies and not others. Now the price is right on one page and wrong on another, and every new feature ships with a side of mystery regressions. This is the point where founders report that progress, which used to feel effortless, suddenly feels like wading.

And you're still flying blind. By week 3 you need answers to boring operational questions: Is the app up right now? Did last night's signups get their welcome emails? When did the database last get backed up — and has anyone ever tested restoring it? If every answer is "I'd have to check manually," you don't have monitoring, you have hope.

What you can do yourself this week

You don't need an engineer for the first pass. Before you announce anything, spend a few hours on this:

1. Try to break your own signup. Wrong passwords, malformed emails, the reset-password flow end to end, signing up twice with the same email. Fix what dead-ends.
2. Log in as two different users in two browsers. Try to reach user A's data from user B's session — including by editing IDs in URLs and calling API endpoints directly. If anything leaks, stop and fix that before you launch. This one is not optional.
3. Fail a payment on purpose. Stripe publishes test card numbers that decline. Use them. Check what the user sees, and check what your database recorded.
4. Feed every form garbage. Empty submissions, huge text, emoji, script tags, a giant file. Note every crash and every silently-accepted absurdity.
5. Add error tracking. Sentry or an equivalent has a free tier and takes under an hour, even prompted through your AI tool. This is the single highest-leverage hour on this list.
6. Confirm backups exist and restore one. Find where your database actually lives, check the backup setting is on, and do a test restore. A backup you've never restored is a rumor.
7. Ask your AI tool to audit its own work. Prompt it: "Review this codebase for security issues, missing error handling, and unprotected API routes." It will find real problems. It won't find all of them — the tool shares its own blind spots — but the list is free.

Do these seven things and you're ahead of most AI-built launches.

When to bring in an engineer

Honestly: sometimes you don't need one yet.

If you're pre-launch with no real users, no payments, and no sensitive data — ship it. The checklist above is enough. Real usage will teach you more than any expert review, and hardening an app nobody wants is the most expensive mistake available. The tools got you here precisely so you could learn cheaply. Keep doing that.

Bring in a senior engineer when the stakes change shape:

• You're about to charge money. Payment edge cases fail in ways that cost real dollars and refund emails.
• You're holding data that can hurt someone — health information, financial records, kids' data, other people's customer lists.
• The self-checks above turned up something you can't evaluate. You found a way to see another user's data, or the AI's self-audit flagged issues you can't judge the severity of.
• Progress has inverted. Every change breaks something else, and features that used to take a prompt now take a week of whack-a-mole.
• Real customers are arriving faster than you can watch the app by hand.

What you want at that point is not a rebuild — most AI-built apps don't need one — and not an open-ended hourly engagement with no defined end. You want a fixed-scope review that tells you exactly what's solid, what's fragile, and what order to fix things in. The failure patterns are consistent enough that we've catalogued them in what breaks when AI builds your app; a good audit checks your specific codebase against them.

That's the product we built for this exact moment: a fixed-price code audit — from $995, delivered in 5 business days, as a written report covering security, architecture, performance, and a prioritized path to production. No hourly meter, no lock-in. The report is yours: hand it to us, to any engineer you trust, or back to your AI tool as a very well-informed prompt.

You did the hard part — you built something people want. The last 20% is just making sure it survives them.

Related: read the auth security breakdown · book a vibe coding audit