The developer's gone. The Slack is unread. The repo hasn't had a commit in three weeks. The launch date was last month. You are holding a half-built product and no idea what's actually done.
This happens more often than any conference talk will tell you. The contractor took another gig, the technical co-founder burned out, the agency went quiet. The result is identical: a codebase in an unknown state, a launch that didn't happen, and a founder who now has to make decisions with incomplete information about whether what they have is worth saving.
What this costs you
Every day of delay is burn rate against a runway that doesn't extend. The average Series A–stage startup burns $80k–$150k per month. If the product was supposed to ship two months ago, you're already down $160k–$300k in runway on the delay alone — before you've spent a dollar on recovery.
The market window is real. If you were going into a specific seasonal cycle, a conference window, an investor demo, a partnership launch — those don't pause. The clock that mattered when the developer was around still matters now.
The subtler cost is the product itself. A half-finished codebase doesn't hold. Dependencies go stale. Incomplete database migrations leave schemas in intermediate states. Background jobs that were half-wired accumulate silently broken assumptions. The longer the repo sits idle, the more work it takes to understand and the more things quietly rot.
The four things that determine whether a build is salvageable
Not every abandoned build is recoverable at reasonable cost. Before any decision is made, four things have to be assessed.
Test coverage. Not whether tests exist — whether they cover the actual behavior. A codebase with 80% coverage of trivial getters and zero coverage of the payment flow is not a testable codebase. What you need to know: can you change things safely? If the answer is no, every day of further development is a gamble.
Documentation. This almost never exists. What matters is whether the absence of documentation can be compensated by reading the code itself. A well-named, reasonably structured codebase can be understood in days. A codebase full of one-letter variable names, no comments on complex logic, and no migration history can take weeks to reverse-engineer.
Architecture clarity. Is the structure comprehensible? Can you trace the flow from a user action to a database write without losing the thread? Or did the developer build it in a way that only made sense to them, with implicit dependencies and undocumented assumptions threaded through everything?
Data model sanity. This is the hardest to fix. A reasonable schema with clear relationships and consistent naming is recoverable even if the application layer is a mess. A schema that was designed on the fly — nullable columns where nullability has no defined meaning, JSON blobs used to avoid adding tables, implicit state managed in application code — is the thing that turns a 4-week stabilization into a rebuild.
What the first 72 hours look like
The first 72 hours are an audit, not a rebuild. The instinct when inheriting a broken build is to start writing code. That instinct is wrong. You cannot make good decisions about what to fix until you know what you have.
The audit covers: read every migration in order to understand the schema history. Read the data model. Understand the relationships before you understand anything else. Run the application locally — does it start? Does the happy path work? Run the tests — do they pass, and do they cover anything meaningful?
Map what's actually complete. Divide the feature set into three buckets: done and working, started but incomplete, and not started. Honest accounting here is the entire value of the 72-hour audit. Founders frequently believe they're 80% done when an audit reveals they're 45% done. That's not a failure — it's information that changes every decision that comes next.
Assess the blast radius of the incomplete work. Some incomplete features are contained — they can be disabled, deferred, or shipped in a later version with no impact on the core. Others are structural: a half-implemented authentication refactor, an incomplete data migration, a background processing system that was rearchitected halfway through. Structural incompleteness is the thing that can make a build unbuildable without a restart.
What you actually find in 80% of these situations
In our experience rescuing stuck builds, the pattern is consistent.
The core functionality — the thing the developer actually spent most of their time on — is usually closer to done than expected. The gaps are almost always in the surrounding infrastructure: error handling, loading states, edge case behavior, deployment configuration, environment variable management, logging, the authentication edge cases (password reset, session expiry, account lockout), and the administrative tooling that the developer deprioritized because it wasn't the product.
The database schema is almost always in a better state than the application layer. Developers tend to think carefully about data even when they're moving fast.
The tests are almost always inadequate and frequently wrong — they test what the developer thought the code did, not what it actually does.
The documentation is almost always absent.
And there is almost always one decision the developer made early on that was reasonable at the time but is now causing cascading problems. Sometimes it's a library choice. Sometimes it's a data model decision. Sometimes it's an architectural pattern that doesn't fit the actual requirements. Finding that decision is the most important thing the audit does.
The decision: salvage or restart
After the audit, the decision has exactly two inputs: what it costs to complete the build from where it is, and what it would cost to restart with the knowledge you now have.
Salvage wins when: the data model is sound, the architecture is comprehensible, the incomplete work is mostly in the application layer rather than the foundation, and the estimate to complete is within a reasonable multiple of what a restart would cost.
Restart wins when: the data model is wrong in ways that will cascade into every feature, the architecture is so specific to how the missing developer thought that no one else can work in it productively, or the incomplete work is structural and touches the parts of the system that everything else depends on.
The partial-restart is often the right answer: keep the schema and the working core, discard the incomplete peripheral work, rebuild the surrounding infrastructure with a proper foundation. This is not a full rewrite — it's a targeted reset of the parts that were never going to work.
What a 4-week stabilization looks like
Week one is the audit, the architecture decision, and the scope lock. The scope has to be fixed before anyone writes a line of new code. What is the minimum shippable version? What gets deferred? That boundary is the contract.
Week two is infrastructure: tests on the working core, environment parity between development and production, deployment pipeline, error tracking, logging. This is not exciting work. It's the work that makes all future work safe.
Weeks three and four are completion: the missing features from the minimum scope, integrated and tested. No new ideas. No scope creep. The goal is a working, deployable product that matches the locked scope.
At the end of four weeks you have a product that can ship, a test suite that catches regressions, and documentation that means the next developer can understand what they're working with.
How to avoid this next time
This situation almost always has a preventable cause. Not the disappearance — that's unpredictable — but the lack of knowledge transfer that makes the disappearance catastrophic.
Require weekly commits with meaningful messages. Require a running, reviewable version of the product at every milestone. Never pay for work you can't see running. Require access to the repo, the deployment environment, and the database from day one — not when you ask, from day one.
The single most important thing: build with a team that has more than one person who understands the system. A single-developer build that goes dark leaves you in exactly this situation. Two developers who both understand the architecture means the disappearance of one is a problem, not a catastrophe.
What resolution looks like
A successfully stabilized build has these properties: it deploys reliably to production. The test suite covers the core flows and catches regressions. The next developer who joins can understand the architecture without a 4-hour onboarding call. The scope is honest — the product does what it says it does and nothing is hidden behind a flag that was never completed.
It's not perfect. Stabilized builds carry the marks of their history — decisions made under pressure, architecture that was good enough for the stage. That's acceptable. What's not acceptable is a product that can't ship, a team that can't maintain it, or a founder who has to call in another rescue in six months.
This is for you if
You're a founder with a stuck build, a missed launch date, and a developer who is no longer reachable or no longer engaged. You need someone to tell you honestly what you have, what it will take to ship it, and whether the path forward is completion or restart.
Rescue engagements of this type run $25k–$100k depending on the state of the build and the scope of what's left to complete. The 72-hour audit is scoped and priced separately — it's the thing that determines everything else.
This is not for teams with no budget and no timeline flexibility. It's for founders who need to ship, have a real product and a real market, and need an engineering team that can walk into an unknown codebase and tell them the truth about what they have.