Most half-built apps arrive the same way. A freelancer went quiet. A codebase was inherited and no one understands it. Or an AI build got to "almost done" and then simply stopped moving. All three are common, and all three are usually recoverable. The first step is never more code; it is an honest look at what you actually have.
Why builds stall
Projects rarely fail for one dramatic reason. They stall because scope crept while the budget did not, because the wrong person was doing the work, because there was never a clear spec to build against, or because the founder and the developer slowly stopped understanding each other. And increasingly, they stall at the 80% wall: an AI or no-code build that looks nearly finished but cannot cross into production, a gap we cover in from AI prototype to real product.
Step one: the audit
Before anyone promises a timeline, the code has to be read. A proper audit answers a short list of questions honestly:
- Can we run it? A build that only works on the last developer's laptop is a warning sign, and a fixable one.
- Is it readable? Clear, conventional code can be picked up. A tangle written in a hurry sometimes cannot, and that changes the maths.
- Is your data safe? Exposed keys, open databases and missing backups are the first things to find and the first to fix.
- What is actually done? "Ninety percent finished" often means the visible parts work and the hard parts were skipped. The audit separates the two.
- What is the fastest safe path? The point of the audit is a decision, not a report.
Rescue, rebuild, or restart
An audit points to one of three outcomes, and being honest about which is the whole value:
- Rescue. The foundation is sound and the work is genuinely most of the way there. We finish it, harden it and ship it. This is the best and most common case.
- Rebuild the foundation. The interface and idea are worth keeping, but the plumbing underneath is not. We keep what is good and re-lay the rest, which is often faster than untangling it.
- Restart. Occasionally the fastest route really is a clean build, using the old work as a detailed brief. We only say this when it is true, because it is the least welcome answer.
Almost done is the most expensive place a project can sit. The cost is the momentum you lose while it waits.
Handling the handover safely
If a previous developer is out of the picture, protecting your project comes before any new work. That means getting the source code, the hosting and domain accounts and any service keys into your own name, rotating passwords and keys the old team knew, and writing down how the thing runs so you are never again one person away from being stuck. If you cannot get the code at all, an audit will tell you honestly how much has to be rebuilt.
What a rescue costs
An audit is a small, fixed piece of work, and it is worth doing on its own: even if you take the findings elsewhere, you will finally know what you have. The finish or rebuild that follows depends entirely on what the audit finds, which is exactly why no one should quote it blind. Be cautious of anyone who names a price before they have seen the code, in either direction.
How to avoid needing a rescue next time
- Start with a clear, written spec. Even a page. It is the thing you build against and measure against.
- Work in milestones. Small, visible deliverables catch a project drifting before it is lost.
- Own everything from day one. Your code, your accounts, your keys, in your name.
- Choose a proven stack. Common technology means the next person can pick it up if they have to.
The bottom line
A stalled build is rarely as broken as it feels from the outside. Most are a clear audit and a focused push away from launch. The worst thing you can do is leave it sitting at almost done, or pour more money into the same approach that stalled it. If that is where you are, start with the audit, and if you are weighing a fresh build instead, here is what an MVP costs in 2026.
