“Every week a half-built app sits idle, the cost of finishing it goes up - because the codebase drifts, the context fades, and the market moves on.”
The real cost of a stalled buildWhy Half-Built Apps Are So Common
AI coding tools and no-code platforms have made it easier than ever to start building. That is genuinely good news. The side effect is that a lot of apps get to 60 or 70 percent done and then stall. The founder runs out of budget, hits a technical wall they cannot clear alone, or the freelancer they hired disappears mid-project.
When you come to a developer or agency with a half-built app, the first question they will ask is not "what features are left" - it is "what state is the codebase in." The answer to that question drives the cost more than the feature list does.
The Four States a Half-Built App Can Be In
Not all half-built apps are equal. A clean, well-structured codebase that is simply missing features costs far less to finish than one that was built by five different freelancers over eighteen months with no consistent architecture. Before you get any quotes, it helps to know honestly which category you are in.
- Clean and structured - features missing but existing code is readable, tested, and documented
- Functional but messy - works on the happy path, breaks in edge cases, little to no tests
- Technically broken - critical bugs, security holes, or a database schema that doesn't match the UI
- AI-generated sprawl - Lovable, Bolt, or Cursor output that was never reviewed or refactored, meaning hidden assumptions everywhere
The difference in finishing cost between a clean codebase and an AI-generated sprawl can be 3x to 5x. A 2-week engagement becomes a 6 to 10 week one once the team has to reverse-engineer what the original code was trying to do, fix the underlying problems, and then build the missing features on top.
Realistic Cost Ranges by Scenario
For a clean codebase needing two to four features added: expect 2 to 5 weeks of development, typically $4,000 to $12,000 depending on complexity and the developer's rate. This is the best-case scenario and it requires that the existing code is genuinely clean.
For a messy but functional codebase: budget for a week of assessment and light refactoring before any new work begins. Total engagement 4 to 8 weeks, $8,000 to $25,000. The range is wide because "messy" covers a lot of ground.
For a technically broken or AI-generated sprawl codebase: the honest answer is that you may spend as much finishing it as you would rewriting the backend from scratch while keeping the UI. We have seen founders spend $15,000 trying to patch an AI-generated codebase and end up with something still not shippable, then spend another $10,000 on a proper rebuild. The $10,000 rebuild would have taken three weeks if done first.
What a Proper Assessment Looks Like
Before any responsible developer gives you a fixed quote on finishing a half-built app, they need to do a code audit. This typically takes 2 to 5 hours for a small app and involves reading through the codebase, running it locally, checking the data model, and reviewing any existing tests or documentation.
What they are looking for: security vulnerabilities (exposed API keys, missing auth checks, unvalidated inputs), architectural problems that will make new features hard to add, dependencies that are outdated or abandoned, and any gaps between what the code does and what the spec says it should do.
A developer who quotes a fixed price without doing this audit is guessing. And when their guess turns out to be wrong, you pay for it - either in cost overruns or in shortcuts that create problems later.
The Build vs. Rebuild Decision
Keep the UI, rebuild the backend
- You start fresh on the layer that matters most for reliability
- Clean architecture means every future feature costs less to build
- Existing UI can be wired to the new backend - users see no change
- Higher upfront cost but lower total cost of ownership over 12 months
How to Reduce the Cost Before You Hire Anyone
Three things you can do before engaging a developer that will directly reduce what you pay. First, write down what the app is supposed to do - not what it currently does, but what it should do when finished. A clear spec means the developer spends time building, not clarifying.
Second, gather everything you have: the original brief (if any), logins to all services the app uses, the repo URL with full history, and any notes from the previous developer. Context that took weeks to accumulate can be transferred in an hour if it's documented.
Third, be honest about what is broken. Do not describe the app as "almost done" if core features don't work. A developer who walks in expecting a polish job and discovers a structural problem will either reprice or walk. Accurate scoping upfront means you get accurate quotes and no surprises.
What to Ask When You Get a Quote
Ask specifically: does this quote include a code audit before work starts? Is this fixed-price or time-and-materials? What happens if you discover problems during the audit that weren't visible upfront? How are out-of-scope items handled?
A fixed-price quote on a half-built app without an audit is a red flag. The developer is either very confident (which means they did due diligence you didn't see) or they're planning to cut corners when they hit the inevitable surprises. Time-and-materials with a clear scope and a not-to-exceed ceiling is often the fairer structure for both sides.
At Zovintra, we start every Launch & Rescue engagement with a paid audit session. We tell you exactly what we found, what it will take to fix, and give you a clear scope before any build work begins. If the honest answer is "rebuild the backend," we'll say so upfront rather than letting you discover it three weeks in. If your half-built app is sitting idle right now, that audit is the fastest way to get clarity on what it will actually cost to ship it.
