Somewhere between “just a few more weeks” and radio silence, a lot of founders end up owning a codebase nobody can explain. The freelancer stops replying to Slack. The agency’s account manager goes quiet. What’s left is a half-built app, a Firebase console with mystery collections, and an invoice history that doesn’t match what actually got shipped. If this is you, the first question isn’t “who do I hire next” — it’s “what do I actually have.”

That question is more expensive to answer than most founders expect, but it’s also the only way to stop bleeding money on guesses. Here’s what the real recovery process looks like, and why it’s a distinct piece of work from building something new.

Why “just pick up where they left off” doesn’t work

The instinct is to find a new developer, hand them the GitHub repo, and ask them to finish it. In practice, almost no developer will quote you a fair price for that without looking first, and the ones who do are usually the ones you should avoid. A codebase built by someone who’s no longer around carries invisible risk: undocumented decisions, dependencies pinned for reasons no one wrote down, half-finished features that look done in the UI but fail the moment a real user hits an edge case.

We’ve taken over projects where the previous build looked 80% complete from the outside — screens all present, demo running fine — but the backend had no real authentication logic, API keys were hardcoded into the client, or the data model couldn’t actually support the feature the founder thought was already working. None of that shows up in a five-minute look at the app. It shows up when someone reads the code line by line and tries to break it.

What an actual audit involves

A code audit, done properly, isn’t a vibe check or a one-page PDF with a red/yellow/green traffic light. It’s a structured pass through the codebase that answers specific questions a founder needs answered before spending another rupee:

  • Does the architecture support what you’re trying to build, or does every new feature require fighting the existing structure?
  • Is there anything actively dangerous in production right now — exposed credentials, unvalidated inputs, an admin panel with no access control?
  • What’s genuinely finished and tested versus what merely compiles and demos well?
  • What’s the dependency and infrastructure situation — are you tied to services, libraries, or SDKs that are outdated, unsupported, or about to break?
  • Realistically, is this worth rebuilding on, or is it faster and cheaper to start the core over while reusing what’s salvageable?

That last point is the one people resist, because it feels like throwing away money already spent. But sunk cost is sunk either way — the only real decision left is which path costs less from here. Sometimes the backend is solid and only the mobile client needs rework. Sometimes it’s the reverse. Occasionally the honest answer is that everything past the authentication flow needs to be rebuilt, and we say that directly rather than padding a scope document to justify a bigger invoice.

What recovery actually costs, in time and money

The audit itself is typically fast — days, not weeks — because the goal is a clear diagnosis, not a rewrite. What it costs depends entirely on codebase size and how much documentation (or lack of it) you’re starting from. A small MVP with a few screens and one backend service is a very different job than a multi-role platform with payments and background jobs.

What we won’t do is quote a fixed recovery price before opening the code. Anyone who does that is either guessing or padding the number to cover their own risk — and you end up paying for that padding either way. What we can commit to upfront is the audit itself: a fixed, bounded piece of work that ends with a real answer, not a sales pitch dressed up as a technical opinion.

The rebuild that follows — if a rebuild is what’s needed — gets scoped against actual findings, not assumptions. That’s the difference between a quote based on what you think you need and one based on what the code shows you need. It also means you can shop that scope around to other developers if you want a second opinion; a real audit produces a document, not a lock-in.

The part founders underestimate

The hardest cost to plan for isn’t engineering time, it’s the delay itself. Every week spent figuring out what’s salvageable is a week your launch timeline slips, your investors or co-founder ask harder questions, and your original budget stretches further than planned. The founders who recover fastest are the ones who treat the audit as the first deliverable, not a formality before “the real work” — because it’s the thing that turns a vague, anxious “I don’t know what I have” into a scoped plan with a number attached.

If you’re staring at a stalled app right now and don’t know whether to fix it, restart it, or fire whoever’s left on the team, that diagnostic work is exactly what we do at orithLabs — the same close-to-the-code approach we’ve used building things like Crumb Count and Kompete, just pointed at someone else’s code instead of ours. Happy to take a look and tell you plainly what we find.