Vibe Coding Works for v0. It Collapses at v1.2. Three Cracks to Watch.

The collapse comes later, and it isn't random. It shows up at three moments. Each one looks like bad luck from the inside, a strange bug here, a refund request there. From the outside it's the same event every time: the product met something the demo never had to handle.

Why v1.2

v0 is you. v1.0 is your friends, who forgive everything. v1.1 is your first real customers, and they mostly use the product the way you demoed it. v1.2 is the release where one of them asks for something the agent never saw a pattern for, like a second seat for a teammate or a security questionnaire.

That's the moment vibe coding stops being speed and turns into debt that nobody on the payroll can read.

The first crack: the second user

You shipped accounts, and the agent said it handled multi-tenancy. Then someone clicks "share with team", or a second company signs up, and two accounts can see each other's data.

It happens because tenancy is a property of the whole system, not of a feature. Each feature was generated in its own session. The organization filter went in where the prompt mentioned it and got left out where it didn't. One missed query is enough.

We found exactly this when we took over Oria, an oral history platform built fast with AI coding agents: organizations could see each other's data. The fix wasn't a patch per screen. It was tenant scoping enforced below the application code, plus a test that logs in as one organization and tries to read another's records.

The tempting first move is to fix the screen where the bug showed up. That treats the symptom, and the same leak turns up somewhere else later.

The second crack: the first payment

Checkout works in the demo. Then a real customer pays and sees the thank-you page, while their account stays on the free plan.

Stripe tells your app about payments through webhooks, not through the success page. An agent will happily scaffold a webhook handler. What it often skips is registering that endpoint in Stripe for live mode and checking the signature. It rarely plans for the same event arriving twice, which Stripe says will happen. The first sign is often a support email asking why a paid account is still locked.

The third crack: the first security review

A bigger customer sends a security questionnaire, or simply asks where their data is stored. Someone opens the repo properly for the first time in months.

What they find tends to rhyme. Keys committed to the repository. No record of who changed what. A server-side key doing a job meant for the public one. Old model versions still wired in because the agent never came back to them. At Oria it included hardcoded secrets and no tests, which is a hard pair of answers to give a procurement team.

The deal stalls while you work out the answers. Sometimes it dies there.

What to do at each crack

At the second user, stop patching screens. Move tenant checks below the application, into database row-level security or a single data-access layer every query goes through, and run the cross-organization test on every build.

Payments need the webhook treated as the source of truth. Register it in live mode, verify signatures, record event IDs so a repeat does nothing, and test the unhappy paths as well as the happy checkout.

Before you answer a security questionnaire, get an engineer who didn't write the code to read it. Rotate every key that was ever in the repository. Then write down where customer data lives and who can reach production.

A test for each crack, this week

• Second user. Create two test organizations. Log in as the first and change a record ID in the URL to one that belongs to the second. You should be refused.
• First payment. In Stripe test mode, subscribe a test account, then cancel the subscription immediately from the Stripe dashboard and check the app downgrades it. Resend the original checkout event from the dashboard and check that nothing doubled.
• First security review. Answer four questions in writing: where customer data lives, who can reach production, how long rotating every key would take, and whether you could tell who changed a customer's record last week.

If one of those goes badly, you've found your crack before a customer did.

Related reading

• We inherited an AI-generated codebase. Here is what we found: the first and third cracks in a real rebuild
• Your AI-built Supabase is one curl away from a leak: the second-user crack, checked at the database
• The 30-minute vibe-coded app audit: run it yourself first: a wider self-check, payments included

Payments already misbehaving: Stripe payments broken. Every change breaks something else: can't add features. Weighing a rebuild: agency transfer vs rebuild. The service: Vibe Code Rescue.