If you are trying to fix a vibe-coded app, something has probably just gone wrong in a way that felt sudden. It usually is not sudden. AI-built apps fail on a schedule: they work beautifully until the moment real people, real data or real money arrive, and then several things go at once.
Here is the reassuring part. Most of these apps are more salvageable than they feel at 11pm. The panic move is to accept the first rewrite quote you are offered. The correct move is to spend a few hours finding out what you actually have, because repair and rebuild differ by a factor of ten in cost and the difference is not obvious from the symptoms.
This post is a triage order. What to check first, how to tell repair from rebuild, what each costs, and how to hand the thing over without paying for a rewrite you did not need. If you are earlier than this and still deciding how to build, read vibe coding versus hiring a developer instead.
First, work out which kind of broken you have
Three very different problems get described with the same sentence. Naming yours changes everything that follows.
Broken as in visibly failing. It crashes, it is slow, it shows an error, a feature stopped working. This looks like the worst kind and is usually the mildest. Visible problems have visible causes and are the normal work of software.
Broken as in structurally stuck. The app runs, but you cannot move it forward. Every change breaks something unrelated. Adding the next feature takes four times longer than the last one. This is the serious one, because it is about how the pieces fit rather than any single fault.
Broken as in quietly unsafe. Nothing looks wrong at all. Keys are exposed, the database is readable, nobody checks whether the person asking for a record is allowed to have it. This is the dangerous one precisely because there are no symptoms.
Most founders arrive worrying about the first kind. The order of urgency is the reverse: unsafe, then stuck, then visibly failing.
The five checks to run before anything else
Do these before you change a line, and do them even if the app seems fine. They are cheap and they decide how much time you have.
- Where are the keys? Any password, API key or secret that lives in the app's code, or in a file that shipped with it, should be treated as already public. Move them and change them.
- Who can read the database? Open your data store and ask what a stranger with the address could see. On AI-built apps the answer is often more than you expect, because permissive settings are what makes the first version work.
- Does the app check permission, or just hide the button? Hiding a button is not security. If someone can ask for another user's record directly and get it, you have a real problem regardless of what the interface shows.
- What happens on failure? Try it with no internet, a declined card, a huge file, an empty form. Generated code handles the path where everything works, because that is what was requested.
- Can you get your data out? If the answer is no or unclear, fix that before anything else. Every other option in this post assumes your data is portable.
If any of the first three turn up something, that is now the whole job until it is closed. Everything else can wait.
Rebuild or repair? How to actually decide
This is where the money is, so be systematic rather than emotional about it.
| Signal | Points to repair | Points to rebuild |
|---|---|---|
| The data | Stored sensibly, right things in right places | Cannot represent how the business really works |
| Making changes | One change touches one area | Every change touches ten unrelated files |
| The core flow | Does roughly the right thing | Solves a problem you no longer have |
| Failures | Handled badly but handled | No idea what happens, no way to find out |
| Size | Big enough that rewriting is real work | Small enough to redo in a fortnight |
| Your certainty | You know what version two should do | The product direction has changed anyway |
Two things worth knowing. A rebuild is not a defeat, and it is genuinely the right answer when the foundation cannot hold what you need next. But "this code is messy" is not by itself a reason to rebuild, and it is the most common reason offered, because reading someone else's code is less pleasant than writing your own.
The other thing: whatever you decide, the app you have is not wasted. It told you what people actually use, which is information the original version was built without. That makes it the best brief you will ever have, and how to brief a developer explains how to turn it into one.
Get a straight read on repair versus rebuild
Describe what the app does and where it is straining. You will get a free itemised plan with the modules, the phases and an estimated total, so you can compare fixing it against building it properly.
Get your build planWhat does it cost to fix a vibe-coded app?
Four different numbers get muddled together here. Separating them makes the decision much easier.
The review. A few hours of a competent person's time to read the code and tell you what you have. This is the highest-value spend available to you right now and it is small. Do not skip it to save money, because it is the thing that prevents the large mistake.
The security fixes. Usually days rather than weeks, if caught early. They are also non-negotiable, so treat them as part of the cost of having launched rather than as an option.
The repair. On a sound foundation, typically a fraction of what building the app cost in the first place. This is the good outcome and it is more common than the rebuild sales pitch suggests.
The rebuild. Realistically close to building the app fresh. What you save is not code, it is certainty, and certainty is worth a lot. You know what the product is now. Our figures for a build from scratch are in how much it costs to build an app, and a rebuild with a working prototype in hand usually prices at the friendlier end of that range because the scope is no longer a guess.
The trap is paying for the fourth number when the third would have done. The review is what tells them apart, and it costs almost nothing by comparison.
How to hand it over without buying a rewrite you did not need
Four rules that will save you a lot of money.
Pay for the reading, separately. Commission a short review as its own piece of work, with a written answer to one question: repair or rebuild, and why. Do not attach it to a proposal for the work itself, since that changes the incentive.
Ask if they have done this before. Working on AI-generated code is a specific skill now. Someone who has done it will start triaging. Someone who has not will start recoiling.
Be honest about how it was built. Hiding it wastes everyone's first week. There is no stigma left in this and any developer worth hiring has seen several by now.
Get the scope written down in plain English. A rebuild priced against a vague description is how quotes triple. Modules and phases, in language you can check, which is the same discipline behind an app requirements document.
Three questions before you accept a rewrite quote
If someone has told you the whole thing needs rebuilding, these three questions separate a real assessment from a preference for writing fresh code.
Which specific part of the foundation cannot hold version two? A good answer names the thing: the data is shaped wrong for how your business actually works, or the platform cannot do what you need next. A vague answer about the code being messy is a preference, not a finding.
What would a repair get me, and where exactly does it run out? There is almost always a cheaper option than starting over. Someone who has genuinely weighed it can tell you what a repair buys you and at what point it stops being enough.
Can the security fixes happen first, this week, as their own small job? The urgent work should never wait on a decision about the large work. Anyone unwilling to separate the two is selling you a project rather than solving your problem.
What to keep, always
Even in a full rebuild, three things survive and they are the valuable ones.
What you learned about users. Which features they touch, which they ignore, where they get confused. This is worth more than the code and it cannot be bought.
The interface decisions that worked. Screens and flows that people understood can be carried straight over. Design is not the part AI got wrong.
Your scope, cut down to what matters. Almost every working prototype reveals that a third of the planned features are unnecessary. That discovery makes version two cheaper on any route, and it is exactly the thinking in what to build first.
Get the read before you get the quote
An AI-built app that started breaking is not a failure, it is a project that reached the point where it needs to be real. That is a better problem than never getting a user.
Do the security checks tonight. Get someone to read the code this week. Do not agree to a rebuild before someone has told you in writing why a repair will not do.
Get an itemised build plan: describe what the app does and what is going wrong, and get the modules, the phases and an estimated total for free. Then you can weigh fixing what you have against building it properly with two real numbers instead of a bad feeling.
Common questions
How do I fix a vibe-coded app?
Triage before you touch anything. Check the security items first, since those are the only ones that can hurt you while you think: exposed keys, a database anyone can read, and missing checks on who is allowed to do what. Then get one person who can read code to spend a few hours mapping what you actually have. Fixing in the dark is how a two-week repair turns into a three-month rewrite.
Should I rebuild my vibe-coded app or fix it?
Repair when the app does roughly the right thing and the trouble is quality: crashes, slowness, messy handling of errors. Rebuild when the foundation is wrong, meaning the data is stored in a shape that cannot represent your real business, or every small change breaks things in unrelated places. Most apps that feel unfixable are actually the first case, so get a professional opinion before accepting a rewrite quote.
How much does it cost to fix an AI-built app?
A review that tells you what you have is usually a few hours of someone's time and it is the best money in the whole process. Repairs on a sound foundation are typically a small fraction of what the app cost to build. A genuine rebuild lands close to building it fresh, minus the value of everything you learned, which is real. The variable that decides the number is how much of the foundation survives.
Is my vibe-coded app secure?
Assume not until someone has checked, because the failures here are invisible from the outside. The recurring three are secret keys left in the code, a database open wider than intended, and no check on whether the person asking for data is allowed to see it. The app works perfectly with all three problems present, which is exactly why they reach launch.
Can I hire someone to take over an AI-built codebase?
Yes, and it is a specific skill worth asking about directly. Someone who has worked on AI-generated code before will triage it in hours rather than recoiling from it. Be wary of anyone who quotes a full rewrite before reading what you have, and be equally wary of anyone who promises to fix it without looking. Pay for the reading first, then decide.
Get a build plan for your idea
Describe what you want to build and get a clear, itemized plan in a couple of minutes.
Get your build plan
