You vibe-coded a prototype. Now it has to work on a Tuesday morning.

The moment it stops being a demo

Six weeks ago you had an idea and a Sunday afternoon.

You described it to an AI coding site — Bolt, Lovable, v0, Replit, pick your flavour — and by teatime you had something you could click through. A dashboard. A form. Maybe a little workflow that felt like your business, not a generic SaaS. You showed it to the team on Monday. People got excited. Someone said "can we use this for real?"

That question is where the interesting work starts.

Vibe coding is brilliant at one job: making the abstract concrete, fast. You find out whether the shape of the thing is right before anyone writes a spec or signs a cheque. What it is not brilliant at — yet — is the boring, load-bearing work that business software actually lives on: your customer data in the CRM, your stock in the warehouse system, your invoices in Xero, your team logging in with the right permissions, your backups when someone deletes the wrong row at 4:55 on a Friday.

None of that is a moral failure. It's just a different phase of the project. The prototype answered "is this worth building properly?" The next question is "what do we do with what we've got?"

What usually breaks first

We see a steady stream of these now. The details vary; the pattern doesn't.

It only knows about itself

The prototype has its own little database — often SQLite or a hosted Postgres instance the platform manages. Your real business lives in five other places. So your team ends up doing exactly what they did before, plus copying data into the new tool, plus wondering why they bothered.

The fix isn't "add an integration button". It's deciding which system is the source of truth for each kind of data, and building proper pipes — with error handling, retries, and someone who gets paged when Xero's API is having a day.

Auth and permissions were an afterthought

Demo apps often have one login, or a magic link, or "admin / user" as the whole security model. Real businesses need "Sarah can approve up to £5k, Dave can see margin, the warehouse tablets can't touch pricing". Retrofitting that into generated code is fiddly because the data model underneath was never designed for it.

The happy path is the only path

AI tools are very good at the flow you described out loud on Sunday. They are less good at the edge cases that show up on week three:

• What happens when the customer on the PO doesn't exist in the CRM yet?
• What if two people edit the same job at once?
• What if the courier API times out mid-label-print?
• What if someone uploads a 40MB PDF?

Each of those is a small decision. Together they're what separates software your team trusts from software they work around.

You can't see inside the box

Generated projects often arrive as a lump: frontend, backend, hosting, database, all bundled. That's fine for a prototype. It's awkward when you need to pass a security questionnaire, move off the platform's pricing tier, or hand the code to a developer who needs to run it locally, step through with a debugger, and write a proper test for the pricing rule before changing it.

Nobody owns the Tuesday morning

The prototype doesn't send alerts when it breaks. It doesn't have a runbook. It doesn't have a staging environment where you try the scary change first. When it falls over, it falls over into your inbox — or worse, into your customers' experience — and the person who vibe-coded it is back to their day job.

This isn't "you shouldn't have done that"

We want to be clear, because the tone in some corners of the industry is smug: building a quick prototype with AI tools is a sensible thing to do.

It's cheaper and faster than paying an agency to discover, six weeks in, that you'd asked for the wrong thing. It gives your team something to react to — which surfaces requirements no workshop would have found. It might even become the UI reference for the real build: "like this, but connected properly".

The mistake is only one: treating the prototype as production because it looks finished. The purple gradient and the smooth animations are doing a lot of emotional work. Underneath, you might still be at the cardboard model stage of architecture — and that's fine, as long as you know it.

Three sensible paths forward

When someone comes to us with a vibe-coded project, we almost always end up in one of three buckets. The right one depends on how wrong the foundations are versus how right the idea is.

1. Integrate and harden (salvage the core)

When it fits: the data model is roughly right, the UI is genuinely useful, the stack is something a professional team can maintain (Laravel, Next.js, a normal Postgres — not an opaque black box), and the gap is mostly plumbing and hardening.

What it involves:

• Audit what's there — security, data model, hosting, dependencies
• Decide system-of-record for each entity (customers, orders, stock…)
• Build real integrations (we've written about what that actually means)
• Add proper auth, roles, audit trails
• Move to infrastructure you control (your AWS account, your domain, your backups)
• Fill in the edge cases and write tests for the rules that matter

Typical shape: a focused phase of four to ten weeks, depending on how many systems it needs to talk to and how messy the generated code is.

Watch out for: "integrate" slowly becoming "rewrite in place" because every change breaks something unexpected. Be honest at week two if you're patching over sand.

2. Rebuild properly, keep the prototype (the common one)

When it fits: the idea is validated, the team loves the flow, but the implementation is not something you'd want to maintain — tangled generated code, wrong framework for the job, no tests, security holes you don't have time to chase.

What it involves:

• Treat the prototype as a specification, not a codebase
• Run a short discovery: what's essential for v1 in production, what's nice-to-have
• Rebuild on a stack that matches your long-term needs (for us, usually Laravel + PostgreSQL + the integrations you already pay for)
• Migrate any real data you've accumulated in the prototype
• Retire the old URL when the new system is ready — often running both briefly in parallel

Why it's not wasted money: you didn't pay for six months of wrong direction. You paid for a clickable answer to "is this worth doing?" That's one of the highest-leverage spends in software.

Typical shape: similar to any small bespoke build — discovery, then build in phases. The prototype shortens discovery dramatically because nobody's arguing about what the screen should look like.

3. Fold the learnings back into what you already have

When it fits: the prototype proved you need a capability, but the right home for it is a system you already own — extending the CRM, the portal, the ops tool — not a new standalone app.

What it involves:

• Strip the prototype back to requirements: which screens, which rules, which notifications
• Design the feature as part of the existing platform so you don't multiply logins and data silos
• Build there, with the same integration and security standards as everything else

Typical shape: a feature phase inside a larger roadmap, not a new product.

How to decide in an afternoon

You don't need a committee. Walk through these honestly:

If more than two rows point to Rebuild, don't sink months into salvage out of attachment to the repo. The repo isn't the asset. The validated idea is.

What to bring when you talk to a developer

The better the handover, the cheaper the next phase. If you're about to say hello, these make the first conversation sharply more useful:

1. The live URL and how to log in — plus a test account if auth exists
2. A five-minute Loom of the happy path — "this is what we want to keep"
3. A list of systems it needs to talk to — even if it doesn't yet (Xero, Shopify, your CRM, the spreadsheet Karen maintains)
4. Who uses it today — and what they do when it doesn't work
5. What's already gone wrong — the Friday afternoon stories are gold
6. Your actual constraint — budget band, deadline, "must be live before peak season"

You don't need a technical document. You need the truth about how the business works around the tool.

What good looks like on the other side

Production software — whether salvaged or rebuilt — tends to share the same traits:

• One source of truth per thing — customers live in the CRM; the new tool reads and writes there, not in a shadow database
• Humans still in charge of the sharp edges — especially money, contracts, and anything a customer will quote back at you in an email
• You can get at your own data — exports, reporting, no lock-in to a vibe platform's hosting tier
• Someone answers when it breaks — monitoring, backups, a person who knows how it was built
• Changes happen in staging first — sounds obvious; prototypes skip it; production can't

That's the same bar we apply to greenfield builds. The prototype just got you there with less guessing.

The sentence we find ourselves saying

Keep the demo. Don't marry the demo.

Use the vibe-coded version to align the room. Use the production version to run the business. If you're at the hinge between the two, you're not behind — you're exactly where most sensible projects are in 2026.

If you've got a prototype that's outgrown its Sunday-afternoon clothes and you want a straight conversation about fix versus rebuild, say hello. We'll look at what you've got and tell you which bucket we'd pick — even if the answer is "you don't need us yet, fix these three things first."