What Happens After You Vibe-Code an App: the Morning It Stops Being a Demo, and the Go/No-Go That Follows

Nobody decides to take a vibe-coded app to production. Production decides for you, on a morning you did not pick: the first stranger pays, a second company signs up, or a customer's procurement team sends a security questionnaire. From that morning on, the app is no longer a demo, whatever the code says.

I write this from the seat that gets the call a few weeks later. Conectia takes over apps built with Claude Code, Cursor, Lovable, v0, Bolt and Replit and runs them for real customers; I spent years in enterprise DevOps and incident response before that, and my part of these engagements is the first two weeks: reading what exists and writing down what to do with it. This is not a tutorial on taking a Cursor app to production. I have already written what breaks in an AI-built MVP and how I audit a Lovable app on Supabase. This post is about the decision: what happens once the demo stops being a demo, and how a verdict gets made that you can check instead of believe.

The question is never «is the code good». It is «which modules can carry a paying user, and what is the evidence».

The app stops being a demo on one of three mornings

The founder rarely notices the moment. The app does. Three events turn a prototype into an obligation, and each one changes what the same code means.

The first paying user. Until money moves, a bug is a bug. After it, the same bug is a refund, a chargeback or a churned customer who tells three others. Payment also adds the only part of the app that someone else's system drives: the webhook. The provider retries, the event arrives twice or not at all, and your handler runs in whatever order the network chose. A demo never meets that path, because you clicked «pay» once and watched it work.

The second customer. The first customer's data lived in tables that were, in effect, theirs. The second customer's data lands in the same tables, and who can read what stops being theoretical. In a Lovable app the answer is a set of Postgres policies the builder may or may not have written; in a Cursor or Claude Code app it is whatever authorization the agent put in the API, and often that is a hidden button. In May 2025 a researcher scanned 1,645 apps from Lovable's public showcase and found 170 of them readable or writable with nothing but the public key (CVE-2025-48757). Those apps worked. They worked for everybody.

The first security questionnaire. A larger customer wants to buy and sends a spreadsheet: where is the data stored, who has access, how are keys rotated, what is the backup and the recovery point, do you keep logs. The questions are not hard. They are unanswerable for an app nobody has read as a system, and «we built it with AI» is not an answer a procurement team accepts.

Each of these mornings asks for the same thing: someone who reads the whole app and signs a verdict. Not the person who built it, who already knows it will not hold and cannot say why.

The eight symptoms are the app naming the module that failed first

When a founder writes to us, they bring a symptom, not a cause. After enough of these, the symptoms sort themselves into eight, and each points at a module. We publish the list because it saves everyone a week.

1. Login breaks, or users get logged out. Auth left on the builder's defaults: redirect URLs, session expiry, email confirmation. On Supabase, without custom SMTP, the built-in sender stops at two emails an hour, which is the launch-day failure nobody predicts.
2. The database gets slower every week. Queries without indexes, screens that load whole tables, a policy that evaluates auth.uid() per row. Invisible at fifty users.
3. Payments go through and access does not unlock. Webhooks without signature checks, retries or idempotency, so a missed or repeated event leaves the account in the wrong state.
4. It works in preview and fails live. Environment variables and build settings that exist only on the builder's platform, with no staging in between. v0 and Replit apps show this one most, because the platform was the environment.
5. It would not pass a security review. Keys in the browser bundle, access policies nobody tested, no access logs.
6. You cannot onboard a second customer. Tenant isolation by convention: the front end filters by organization_id, the database does not.
7. Nobody dares to deploy. No tests on the paths that move money or personal data, no CI, and every fix the agent makes breaks something else. Replit's agent deleted a production database in July 2025 during a live test, after being told to freeze. The lesson is not about Replit: one environment plus an agent with write access is one environment too few.
8. The cloud bill climbs faster than the users. Model calls without a cap, functions that run on every page view, resources nobody switched off.

Each symptom is a day or two of senior work once it has a name. The expensive part comes before that: deciding which of the eight you have, in which module, and whether the module is worth keeping at all.

The two wrong answers are the rewrite and «ship it and see»

Someone, often your first senior hire, will propose rewriting it «properly». I have watched that advice burn a quarter of runway on products whose screens and data model were fine. Perimeter first, replace what carries risk one piece at a time, keep shipping features throughout: that order wins almost every time, and I made the case for it in the first post of this series.

The other wrong answer is to push on. Founders pick it most, because the app works today and because the people telling them to stop are the people selling the stop. I will concede the strongest version of that objection: nine in ten of the apps in that Lovable scan were not exposed by that flaw, and an app with no paying users and no sensitive data should keep being built with the tool that got it here. A verdict before there is anything to protect is money spent on an asset that may not survive the next pivot.

Once one of the three mornings has happened, though, «ship and see» means letting the customers run the audit. They will. They will report the findings as refunds and questionnaires.

There is a third answer, and it has a name in every discipline that launches things. Before a launch, each station in the room reports go or no-go on its own telemetry. The flight director does not launch on a feeling but on a list of «go» calls, each backed by a number someone can show. I spent years on the enterprise version of that room, where a release got its go only with a tested rollback and a backup someone had restored. That is what I want from the two weeks between «it stopped being a demo» and «we start the work».

A discovery sprint ends in a go/no-go per module, with the measurement next to it

The Diagnostic & Blueprint is that discovery sprint: two weeks, read-only access to the repository, the database and the cloud console, a working session with whoever knows the product best, and a written verdict at the end. The page says what the document contains. What I want to set out here is the standard the verdict has to meet, because a verdict you cannot check is an opinion on letterhead.

The unit is the module, not the app. Login, data, payments, integrations, the AI layer: each gets one of three words. Rescue means the module carries a paying user with a bounded list of fixes. Rebuild means the fixes cost more than a clean version that fits the target architecture. Drop means nobody uses it and it carries risk. No module is left at «it depends».

Each verdict carries its evidence, and the evidence is a measurement, not an impression:

• Critical paths executed. Sign-up, login, payment, the one query that would be a breach if it leaked, run end to end against a copy of the data, with what happened written down. Not «the auth looks fine»: this request, this user, this response.
• Queries timed. The slow screen has a query, the query has a plan, and the plan has a number. A «rescue» on the data module comes with the index that fixes it and the timing before and after.
• Costs measured. What one request to the model layer costs, what a page view costs in function invocations, what the bill would be at ten times the users. If nobody can produce those three numbers, symptom eight is already in the mail.
• For AI features, an evaluation set and a metric. This is the one most founders have not met. An AI feature with no evals is a feature nobody can change: the next prompt edit may improve it or break it, and nobody will know until a customer does. The verdict on an AI module is a go/no-go against a set of cases the model has to pass and the metric it has to reach, and that set becomes the regression suite for every change afterwards.

The measurements come with the files, so the next person, whether your hire, our team or the same agent that wrote version one, can rerun them. That is the difference between a discovery sprint and a slide deck.

What I'd do the week after the first invoice

If the app were mine and the first stranger had just paid, in this order:

1. Write down which morning you are on. First payment, second customer or questionnaire. It sets the order of everything below.
2. Take agent write access away from production. One environment with a coding agent inside it is the Replit story waiting to repeat. Give the agent a branch and a preview database; keep production for humans and CI.
3. Rotate every key that has ever been in the repository, and search the built bundle for the secret or service-role key. An afternoon's work, and it closes the finding every questionnaire asks about first.
4. Run the three critical paths yourself and write down what you saw. If you cannot draw the request path for the riskiest action, that is the audit's first job.
5. Get a verdict per module from someone who has done this before, in writing, with the measurements attached. Two weeks is the right length: longer means the auditor has started building, shorter means they are guessing.
6. Decide with the numbers in front of you. Rescue, rebuild or drop, module by module, and only then the build. In most AI-built apps the screens and most of the data model stay, auth and payments get rebuilt, and when the core has to be rebuilt it is an MVP in 6 weeks.
7. Leave the context files behind. CLAUDE.md, AGENTS.md, the tests and the evals, so Cursor or Claude Code keep building inside the plan instead of around it.

The demo proved demand; the verdict is what you owe the people who paid

A vibe-coded app does the expensive thing in a weekend: it shows that someone wants the product. What it cannot do is decide what it owes the person who paid, and that decision is the whole of what happens after. Not a rewrite and not a shrug: a go/no-go per module, each with a measurement someone can rerun.

That is the first step of how we take an AI-built app to production: a two-week Diagnostic & Blueprint that ends in exactly that verdict, which you can execute with us, with your own hire or with the agent that wrote the first version. If you want to weigh us against other firms that do this job, I compared them in the guide to who to hire for an AI-built MVP, and we are listed in vibecoding.app's agency directory, in its full-stack rescue category, next to the others.