Vibe Coding in Production: Where AI-Built Apps Hold Up

Vibe coding means building software by describing intent to an AI system and steering the result, instead of typing every line. The output is real code in a real repository — the shift is in who writes the first draft and how quickly a bad direction can be thrown away.

The honest framing is that it collapses the cost of the first eighty per cent. A working prototype with a database, authentication and a deployed URL in a day is now ordinary. The last twenty per cent — edge cases, permissions, migrations, money, other people's APIs — still costs roughly what it always did, and that is where projects either land or unravel.

Internal tools are the standout. A dashboard, an intake queue, a quoting calculator, a client portal, an approvals workflow — small, known user set, forgiving failure modes, and enormous value compared to the spreadsheet and inbox they replace. These ship in days and stay in use for years.

Marketing sites and content-driven products hold up because the requirements are visual and the data model is shallow. So do integration glue and automations: pull from a form, enrich, write to a sheet or CRM, notify a human. And crucially, so do prototypes whose job is to make a decision — building the thing is now cheaper than a month of arguing about a specification.

Anything with real money and real consequence needs deliberate engineering. Payments, payouts, subscriptions with proration, anything where a duplicate write costs someone money — the failure is not visible in the happy path you demo, which is exactly what makes it dangerous.

Multi-tenant permissions are the second trap. Getting a screen to look right for a logged-in user is easy; guaranteeing no user can read another tenant's data requires modelling access at the data layer and testing it adversarially. Add to the list: schema changes on live data, compliance-bound systems, heavy real-time collaboration, and anything with a hard performance budget.

Decide up front whether you are building a decision or building a product. A prototype exists to answer a question and can be discarded without regret. A product carries data other people rely on, and needs the boring parts specified before the exciting part is built: who can see what, what happens when a write fails, what gets logged, how it is backed up.

Then constrain the surface. One database, one deployment target, few dependencies, no bespoke infrastructure. Speed comes from a small, conventional stack that AI systems and future maintainers both already understand.

Finally, treat every generated boundary as unverified until you have tested it — auth, permissions, input validation, third-party calls. AI is a fast, confident collaborator, not a reviewer of its own work. The value of experience in this workflow is knowing exactly where to look.

The real gain is not cheaper software; it is a shorter distance between an idea and something you can react to. Clients change their minds when they see the thing, and seeing the thing in three days instead of three months means the change is cheap.

That reframes the risk. The question is no longer "can this be built quickly" — it usually can — but "if this becomes important, does anything need to be rebuilt". Answer that at the start and vibe coding becomes a genuine advantage rather than a debt you discover later.