When a vibe-coded prototype needs senior engineering

Nobody plans to fix a vibe-coded app. The plan was that the tool would keep going — and for a while it did. This is about the moment the plan changes: how to recognize it early, what it does and doesn’t mean about your code, and what to do in what order.

The Pattern

The prototype did its job. That’s the point.

The same sequence is playing out across the market. Someone with a real problem and no engineering budget builds a working app with AI-assisted tools — a chat window, a low-code builder, an agent that scaffolds the whole thing. It demos well. It picks up first users, sometimes first revenue. The idea is validated at a fraction of what traditional development would have cost.

Then progress changes character. Each fix breaks something else. The assistant confidently rewrites code it wrote last week, differently. Features that took an afternoon in week one take a week in month three. None of this means the tool failed or that you did something wrong. It means the prototype reached the edge of what a prototype is for — and the work remaining is a different kind of work.

The Signals

Six signs you’re past the prototyping stage

Any one of these is worth noticing. Two or more means the question is no longer whether to bring in engineering help, but how.

  • check_circleReal users, real money, or real data have arrived. The cost of a failure stopped being your time and started being someone else’s trust. A prototype can be wrong cheaply; a production system can’t.
  • check_circleThe fix-one-break-another loop. The system has outgrown what the assistant can hold in its head at once, so every change is made partially blind. This loop does not end on its own; it tightens.
  • check_circleNobody can say what happens under load. Ten users work. Will two hundred? If the honest answer is a shrug, you have a demo, not a system.
  • check_circleSecrets live in the code. API keys, database passwords, and tokens pasted where they were convenient. It works until the day it very much does not.
  • check_circleThere is no deployment story. A live URL is not staging, rollbacks, backups, or monitoring. If the only way to change the app is to change production, every edit is a gamble.
  • check_circleYou can’t list your own accounts. Hosting, domain, database, payment processor, third-party APIs — if you don’t know what the app touches and who holds each login, you don’t fully own your app yet.
What It Doesn’t Mean

This is not a verdict on your code

“Needs senior engineering” gets heard as “the AI wrote garbage,” and that’s usually false. Whether the prototype came from Lovable, Bolt, Replit, v0, Cursor, or a long chat with a general assistant, it typically carries real value: validated screens, working flows, a product users have already accepted. What’s missing tends to sit underneath — the data layer, the security model, the integration seams, the tests — and that layer can usually be rebuilt around the product without discarding it.

The expensive mistake is the reflexive rewrite. A developer who opens your codebase, winces, and quotes a from-scratch rebuild is skipping the question that matters: which parts hold up under production conditions and which don’t? That is an evidence question. It deserves an evidence-based answer, in writing, before anyone bills you for a rebuild. We’ve written separately about what a production-readiness audit should actually uncover — it’s the checklist for exactly this decision.

In Order

What to do, in what order

  1. Secure what exists

    Export the code to somewhere you control, save the chat transcript, and write down every account the app touches. If you’re mid-stall right now, the field guide for that exact moment walks through this step by step, including a handoff-brief prompt you can paste into any assistant.

  2. Get an inventory before a quote

    A bounded, fixed-scope assessment that ends in a written plan — what to keep, what to replace, what it costs. Ours is the Production Blueprint, starting at $2,500; whoever you hire, insist on a first step shaped like that rather than an open-ended hourly engagement.

  3. Harden in sequence, keep custody

    Security and data-loss risk first, then the production data layer and tests, then new features. Your repository and accounts stay in your name throughout — that’s the shape of a prototype-to-production rescue done honestly. If you know which tool built your app, we keep specific guides for Lovable, Bolt, and Replit.

One More Thing

Pick engineers who respect what the tools did

The team you bring in should be fluent in both worlds. Engineers who dismiss AI-generated code wholesale will bill you to rewrite value you already own; engineers who trust it wholesale will ship its weaknesses to production. We run AI coding agents in our own delivery every day, behind human review gates, so we know from daily practice what generated code is worth — where it’s strong, and where it quietly cuts corners. That judgment, applied with senior discipline, is the whole job. More on how that works without giving up control: how small senior teams use AI agents without surrendering judgment.

Tell us where the prototype stands.

Joseph reads every note and replies himself. If it isn’t a fit, he’ll say so and point you somewhere useful.

Start a Project arrow_forward