Your vibe-coded app is in production. Now what?

Something changed in the last eighteen months. Founders no longer arrive with a Figma file and a budget. They arrive with a working app. They built it themselves, with an AI assistant, over three weekends. It has users. It takes payments.

And then something breaks that they cannot explain, and the conversation starts with the same sentence: “I do not actually know what the code does.”

This is not a post about how AI-written code is bad. Plenty of it is fine — better than a lot of the outsourced code we used to be handed. It is a post about the specific, repeatable ways it fails, because the failures are remarkably consistent across every rescue we take on.

The seven things that break

1. Authorisation lives in the browser

The most common flaw, and the most dangerous. The AI built a screen that hides the admin button when you are not an admin. It did not build a server rule that refuses the admin action when the request comes from a normal user.

Hiding a button is not security. Anyone can call your API directly.

The check: open your app, copy a request from the network tab, replay it with a normal user’s token. If it succeeds, you have a hole. In Supabase this means row level security is off or written permissively. In Firebase it means your rules file still allows read and write for everyone.

The fix: every table gets an explicit policy. Every mutation gets a server-side ownership check. Test it by trying to break it, not by reading the code.

2. Secrets shipped to the client

API keys for payment providers, mail services and AI models end up in front-end code because the fastest working version puts them there. Anyone who opens developer tools has them.

The check: search your built output for the prefix your provider uses on secret keys. Search the bundle for anything named SECRET or PRIVATE.

The fix: move every privileged call behind a server route or edge function. Rotate every key that was ever exposed — assume it is compromised, because it is.

3. No migrations, so nobody can rebuild the database

The schema was created by clicking around a dashboard. There is no file describing it. Staging does not match production. New team members cannot reproduce it. A bad afternoon of edits cannot be rolled back.

The fix: dump the current schema into a migration file today, commit it, and stop editing through the dashboard. This takes an hour and saves a week.

4. Queries with no indexes and no limits

This is the one that works perfectly for six months and then falls over on a Tuesday. AI-written data access tends to fetch everything and filter in application code. At 200 rows nobody notices. At 200,000 rows the page takes eleven seconds and your database bill triples.

The check: open the slow query list in your database dashboard. Anything doing a sequential scan on a table over 10,000 rows needs an index.

The fix: index every column you filter or sort on. Paginate every list endpoint. Cap the maximum page size server-side so a client cannot ask for everything.

5. Duplicated logic in four places

Ask an assistant for a feature five times and you get five implementations. Price calculation lives in the cart component, the checkout page, the invoice generator and the admin export — all slightly different. Then GST rules change and three of them get updated.

The fix: find your money-critical logic — pricing, tax, discounts, permissions — and collapse it into one module that everything imports. This is the single highest-value refactor in most rescues.

6. Nothing tells you when it breaks

No error tracking, no uptime monitor, no log retention. You find out about outages from a customer on WhatsApp.

The fix: an hour of setup. Error tracking on client and server, an uptime ping on your three critical routes, and alerts going somewhere you actually read.

7. No tests on the things that touch money

Full test coverage is a luxury for a young product. Zero tests on checkout is not a luxury, it is a liability. You need roughly eight tests: signup, login, add to cart, payment success, payment failure, duplicate webhook, refund, and permission denied.

The fix: write those eight. Run them before every deploy. Ignore coverage percentages entirely.

The 48-hour triage

When a rescue lands on our desk, we do not open the code and start fixing. We spend two days answering four questions, in this order.

Day one, morning — is it leaking? Auth boundaries, exposed secrets, public storage buckets, anything touching personal data. Security findings jump the queue regardless of everything else.

Day one, afternoon — is the data model right? Everything else is cosmetic compared to this. If users, organisations and permissions are modelled wrong, no amount of patching helps. This is the question that decides patch versus rebuild.

Day two, morning — what is the blast radius of a deploy? Can we ship a change safely? Is there a staging environment, a rollback path, a migration history? If deploying is scary, fixing anything is slow.

Day two, afternoon — what does it cost to run? Database, hosting, AI tokens, third-party services. We have seen ₹18,000 monthly bills that should be ₹2,000, entirely from unindexed queries and a cron job polling every ten seconds.

The output is a written report: findings ranked by severity, each with an effort estimate. You own that document whether or not you hire anyone to act on it.

Patch or rebuild

The honest decision rule, after doing this many times:

Patch when the schema is sound, the framework is current, and the failures sit in a handful of files. Cost band ₹1.5L to ₹4L, two to four weeks, no user-visible disruption.

Rebuild the core, keep the shell when the data model is wrong but the interface is fine. Rewrite the backend and the schema, migrate data, keep the screens users already know. Cost band ₹4L to ₹10L.

Full rebuild only when the product also changed direction. If you are rewriting because the code is ugly, you are buying an expensive coat of paint. If you are rewriting because the product is now something different, that is a real reason.

The mistake founders make is treating this as a code-quality question. It is a business question: what breaks first, what does that cost you, and what is the cheapest change that removes the risk. If you are weighing who should do that work, our in-house versus studio framework applies here too.

Keeping it clean next time

You are going to keep building with AI. Good — so do we. The difference between a codebase that stays healthy and one that decays is whether the rules are written down where the model can read them.

We keep a CLAUDE.md file in every repository: auth rules, schema conventions, folder layout, forbidden patterns, and the eight tests that must pass. Every prompt inherits it. The assistant stops reinventing the pricing function because the file tells it where the pricing function already lives.

That single file has cut our own rework more than any other practice, which is why we treat it as part of the spec rather than a nice-to-have. If you have not written one, that is the highest-leverage hour available to you this week — and it pairs directly with the one-page spec that prevents most of this.

Where to start today

1. Replay one admin request with a normal user token.
2. Search your production bundle for secrets.
3. Add indexes to the three slowest queries.
4. Turn on error tracking.
5. Write the eight money tests.

That is a week of work that removes most of the risk. Everything after that is craft.

If you would rather have someone else do the triage, that is a two-day engagement and you keep the report. Tell us what broke.