Most apps that run are a mix. Sort yours part by part, not as a whole: keep what works with real data, fix what breaks in known ways, and rebuild only a part that can't be made safe or can't grow. Ask for the reason in writing, and for what fixing it instead would cost.
Last checked: 19 October 2026.
Why does everyone tell me to start again?
Because the person quoting often prefers their own code, and you can't read yours to check.
A new developer meets code they didn't write, and some would rather start clean than learn it. You can't read the code to check. Founders' posts are blunt:
- "Both agencies said they will basically use 0% of my AI-generated code" (Reddit r/SaaS, Feb 2026, a founder).
- "I do not want to rebuild from zero unless absolutely necessary." (Bubble forum, Mar 2026, a founder).
The hiring data agrees. Of 632 Upwork jobs where a founder wants an existing app finished or fixed, 24% say it must not be rebuilt and 35% ask for a look at the existing work first. 82 say both.
Onekode coding of founder jobs on Upwork, Aug to Oct 2026. Posted jobs on one marketplace, not prices paid.
Rebuilding isn't always wrong; sometimes it's the cheaper way. The test below shows which parts earn it.
How do I sort my app part by part?
Take six parts. For each, find the sign in the table that matches your app. None needs you to read code.
| Part | Keep it if… | Fix it if… | Rebuild it if… |
|---|---|---|---|
| Screens | Every screen opens and works on a phone and a laptop, with real data in it | Some screens look broken, load slowly or have buttons that do nothing | You need an app-store app and the tool only makes web apps |
| Data and database rules | You make two test accounts and each sees only its own data. Data is still there after a reload | The second account can see the first one's data. The usual cause is missing database rules (Supabase calls them RLS), and the fix is known | Every change to the data breaks a different screen, and a developer says why in writing |
| Login and user roles | You can sign up, log out, reset a password and log in as each kind of user, and each sees the right things | A role sees something it shouldn't, or the reset email never arrives. These are edge cases with known fixes | Fixing one role breaks another, again and again |
| Payments | A test payment in Stripe's test mode goes through, shows in your Stripe account and the customer gets a confirmation | The payment goes through but a refund, a failed card or a cancellation does nothing | The tool can't do the kind of payment you need at all, and a developer confirms it in writing |
| Integrations | Each connected service (email, calendar, Stripe) does its job when you test it | A service works sometimes, or stops after a few days | The service you need has no way in from this tool |
| Hosting and accounts | Your domain, your code store, your database and your hosting are all in your name, and you can log in to each | Some are in the builder's name or a previous developer's name. Move them to yours | Parts of the app exist only inside the builder and nothing can be taken out, confirmed in writing |
Write down one word per row. If most say "keep" or "fix", there's no whole-app rebuild to pay for.
How do I know a part can stay?
It works with real data, a change to it doesn't break other parts, and it sits on accounts you own.
If all three are yes, leave it alone, even if a developer says it isn't how they'd write it. Style is not a reason to pay twice.
- It works with real data, not the sample rows the tool made. Run the main path with your own.
- A change stays where you made it. Change a price and nothing else moves.
- It's on accounts you own. You hold the logins.
A developer who audits AI-built apps wrote: "The apps almost always work." The trouble sits behind login and payments (Facebook group, Sep 2026, a seller of audits).
How do I know a part needs fixing, not rebuilding?
The problem has a name and a known fix. Missing database rules, keys left where anyone can read them, and login or payment edge cases are all of that kind.
People who fix AI-built apps report the same breaks again and again: missing database rules, so anyone can read other people's data; secrets in the wrong place; login and payment edge cases, such as a failed card or a role that sees too much; and no error alerts, so you hear about a break from a customer. Most of these reports come from sellers, people with fixing services to sell, so read them as a pattern, not a count.
Each can be fixed on its own.
When does a part really need rebuilding?
When the tool can't do what you need at all, or every fix to it breaks something else.
Three signs:
- The tool can't make it. A phone app from a web-only builder is the plain case.
- It can't be taken off the platform. A part lives only inside the builder, and a developer says in writing it can't come out.
- Every fix breaks something else. One builder wrote that the app had "grown to around 15,000+ lines of code" and that changes kept breaking other parts (Reddit r/boltnewbuilders, Jul 2026, a builder).
Even then, rebuild that part, not the app.
A rebuild should come with a written reason and two costs: rebuilding this part, and fixing it instead. If rebuilding is cheaper, that's a good reason. Ask to see both.
Is moving my app off the platform a rebuild?
No. Moving takes the same app to accounts you own. Rebuilding writes it again. A founder's post, July 2026:
"Got quoted 60k to rebuild my no-code app from scratch, almost paid it, then found out migration is not a rebuild…"
(Reddit r/nocode, Jul 2026, a founder.)
Moving to your own accounts is work. On Lovable Cloud there's no one-click move of the database, and a Replit user wrote "now I cannot move projects away from Replit" (Trustpilot review, a builder). But the app you have is the app you keep. Ask of any quote: "Is this a move or a rebuild?"
What should a developer put in writing before they rebuild?
What they would keep and why, the reason for each rebuild part by part, what fixing instead would cost, and what you would lose.
Ask these of anyone who looks at your code, before you pay for anything:
- What would you keep, and why?
- Which parts would you rebuild? Give me the reason for each, one by one.
- For each of those parts, what would it cost to fix it instead?
- What would I lose in a rebuild: data, users, features, accounts?
- What would a move to my own accounts cost, compared with a rebuild?
- Will you send all of this in writing before I approve any work?
To draft them for your app, paste this into Claude or ChatGPT.
My app was built with [Lovable, Bolt, Replit, Bubble or another tool], and a developer says it needs rebuilding. Act as a careful developer on my side, and use plain words. Go through six parts of my app one at a time: the screens, the data and database rules, login and user roles, payments, the integrations, and the hosting and accounts. For each part, tell me what I can check myself, without reading code, to see whether it should be kept, fixed or rebuilt. Then write the questions I should send the developer, so they name in writing what they would keep and why, the reason for each rebuild, what fixing instead would cost, and what I would lose. Here is my app, who uses it, what works, what breaks and what I've been quoted: [paste your description here].
What's worth fixing before I launch?
Money first, then customer data, then login, then everything else.
- Payments. A customer is charged once, gets a receipt, and can get a refund.
- Customer data. One customer never sees another's.
- Login. Sign-up, reset and each role work.
- Everything else can wait for after launch.
One founder asked: "When should I have an actual developer review my app before I start charging people?" (Reddit r/replit, Aug 2026, a founder). The answer is before. The whole check is in The Launch List →
Want someone to look?
Send us the link to your app. A person on our team records a walkthrough of what stays, what needs fixing and what blocks launch, with "what stays" first, and sends a one-page note.
If you then want it finished, that's Finish and Launch: nothing is rebuilt without a written reason and your approval, and you can stop after the verdict. Finish and Launch →