A founder came to us recently with an app that was “80% done.” Six months, one freelancer, and roughly $18,000 in. When we opened the repo, the picture looked different: no tests, three different state-management patterns depending on which screen you tapped, an authentication flow that worked on the developer’s phone but nowhere else, and zero documentation explaining why any of it was built the way it was. That “80% done” app needed something much closer to a rebuild than a patch. This is not a rare story. It’s close to the median.

Founders usually ask us for a quote before they’ve asked the more useful question: what actually makes a stalled build expensive to fix? The answer isn’t “bad code.” It’s almost always some combination of the four things below, and understanding them is what separates a realistic budget from a guess that blows up in month two.

Why “just fix the bugs” turns into a rebuild

When a codebase has been built without tests, without code review, and without a second engineer checking decisions, problems compound silently. Nobody notices until the app is under real load or a new feature touches old code and something unrelated breaks. By the time a founder feels stuck enough to call someone, the issues are usually structural, not cosmetic.

  • Core modules need to be rewritten, not patched. Auth, data sync, and payment handling are the three places we most often find shortcuts that worked in a demo but fail under real usage — race conditions in sync logic, tokens stored insecurely, payment states that don’t reconcile if a request fails midway. These aren’t one-line fixes; they require rebuilding the module with the edge cases considered from the start.
  • Missing tests mean every fix is a gamble. Without automated tests, we can’t verify a fix didn’t break something else without manually re-testing the whole app. That manual verification time is real cost, and it recurs every time you touch the code afterward — not just during the rescue.
  • Undocumented decisions cost discovery time. Why does the app fetch user data twice on launch? Why is there a hardcoded five-second delay before the onboarding screen loads? Sometimes there’s a real reason (a race condition someone worked around badly). Sometimes there’s no reason at all. Either way, someone has to read the code, form a hypothesis, and test it — and that’s billable time before a single improvement gets made.
  • Inconsistent architecture multiplies the surface area. If three different patterns were used for the same problem across the app because the approach changed halfway through, we can’t fix “the pattern” once. We have to find every instance and evaluate each on its own.

Where the $40K actually goes

A number like $40,000 sounds arbitrary until you break it into phases. In our experience, a stalled MVP rescue splits roughly like this:

  • Audit and triage (1–2 weeks). Before any code changes, we read the whole codebase, map what exists against what the founder thinks exists, and rank problems by risk — security issues and data-integrity bugs first, cosmetic issues last. This step alone often resets a founder’s expectations, because it’s the first time anyone has told them plainly what state the app is actually in.
  • Rebuilding the load-bearing modules. This is usually the largest line item, because it’s genuine engineering work, not cleanup. Auth, data sync, and payments get rebuilt with proper error handling and, critically, tests — so the next six months of feature work don’t repeat the same failure mode.
  • Backfilling tests and documentation. Not glamorous, and often the first thing a tight budget tries to cut. It’s also the reason the next developer — whether that’s us or someone else — doesn’t end up in the same spot a year from now.
  • Stabilization and the features that were actually the point. Only after the foundation is sound does new feature work become fast and predictable instead of a source of new bugs.

The founders who budget realistically treat the audit as non-negotiable and the rest as scoped by what the audit finds — not a fixed number pulled from a sales call before anyone has opened the code.

The cheaper alternative is rarely cheaper

The instinct to hire another freelancer for a fast, low-cost patch is understandable — the first one was cheap too, and look how that turned out. A patch job on unstable foundations tends to produce the same outcome: it works in the demo, and breaks in production three weeks later, at which point you’re paying for a third rescue instead of a second one.

The alternative isn’t necessarily “spend more.” It’s spending on the right things in the right order: understand what’s actually there before quoting a fix, rebuild what’s load-bearing instead of working around it, and leave the codebase in a state where the next six months of work don’t require another rescue.

What to ask before you sign anything

If you’re evaluating a rescue quote — from us or anyone else — these questions tend to separate a real assessment from a guess:

  1. Have you actually read the code, or is this quote based on my description of the problem?
  2. Which parts are you rebuilding versus patching, and why?
  3. Will there be tests when this is done, or just fixes?
  4. Who do I talk to when something goes wrong after delivery — you, or a project manager relaying to you?

At orithLabs, this is close to how we approach any stalled build that lands on our desk — audit first, be candid about what’s actually salvageable versus what needs to be rebuilt, and put engineers who wrote the code in direct contact with the founder, not behind a layer of account management. If you’re staring at a half-built app and trying to figure out whether it’s a two-week fix or something bigger, we’re happy to take a look and tell you plainly which one it is.