How do you maintain an app you didn’t really write?

What is a vibe-coded app?

A vibe-coded app is an application built primarily by describing what you want to an AI tool — Lovable, Bolt, v0, Replit, Cursor — and accepting the generated result, rather than writing and reviewing the code line by line. The approach is fast and legitimate, but it produces a working product whose owner has never seen most of its internals — which changes how the app must be maintained.

Nothing in that definition is a criticism. Vibe coding collapsed the distance between an idea and a working product from months to an afternoon — that's a genuine shift, and the apps are real: they take payments, hold customer data, and book appointments. The maintenance problem isn't that the code is bad. It's that the usual safety net — a person who remembers writing it — doesn't exist.

What is the vibe-coding maintenance wall?

The vibe-coding maintenance wall is the point where an AI-built app stops being improvable by prompting alone: the first production break the AI can't explain, the integration that fails silently, the regenerated feature that quietly breaks another. You hit it after launch, when real users, real data, and real integrations create failure modes that don't reproduce inside the builder — and someone has to diagnose, not just generate.

The wall has a shape we see weekly: the app worked for a month, then Stripe webhooks stopped syncing orders, or login emails quietly died after a domain change, or a regenerated feature broke checkout — and there's no developer on the team. The builder can't see the break because the break isn't in the builder: it's in an environment variable, a webhook destination, a quota, an expired key. Everything in this guide exists to keep you on the working side of that wall.

The vibe-coded app maintenance lifecycle

1. Ship — launch day is when maintenance starts

   Before announcing: custom domain and SSL working, environment variables set in production (not just preview), webhooks pointed at live endpoints, a data export path confirmed, and the two or three flows that earn money named out loud. Most week-one incidents are publish-seam config, not code.

2. Watch — flows, continuously

   A vibe-coded app fails at the seams while every page still loads. Watch the journeys end to end — checkout reaches payment, login round-trips land signed-in, forms deliver, scheduled jobs leave evidence. Weekly manual checks are the floor; if the app earns real money, the checks should run around the clock without you.

3. Change — every prompt session is a deploy

   Accepted AI changes can touch code you didn't ask about. After each session: re-test the changed flow and the two nearest it, on the published URL, in incognito; confirm secrets and env vars survived; write a one-line changelog entry. "What changed?" is always the first incident question — make it answerable.

4. Break — diagnose before you regenerate

   When something breaks, the instinct is to paste the error into the builder and re-prompt. Resist it until you know what broke: capture the evidence, check what changed last, and check the seams — status pages, env vars, webhook destinations, quotas, auth redirects — before touching code. One targeted fix beats three speculative regenerations.

5. Grow — know when to add humans

   Re-prompting is for features; humans are for the wall. A monitoring service with engineer diagnosis covers detection and root cause from $79–$279/month. For rebuilds and big features, your platform's agency ecosystem is the right tool — and arriving with a written diagnosis makes that engagement cheaper and faster.

The maintenance checklist — on this page and on paper

The whole routine fits four lists. They're reproduced here in full, and the printable one-pager is a direct link — no email required.

Vibe-coded app maintenance — FAQ