Software Project Rescue: What It Costs to Take Over a Stalled or Broken Build

A stalled build is rarely a coding problem by the time it reaches us. It is an access problem, a knowledge problem, and a trust problem, in that order — and the sequence you work them in decides whether the next quarter costs you a few weeks or the whole product. What follows is the process we actually run when a founder calls with a half-finished app and an agency that has stopped answering email.

If you are mid-crisis, do these three things first

Before you send a termination email, do three things: take a full database dump and store it somewhere the outgoing vendor cannot reach, confirm that you personally control the domain registrar account, and confirm that your card — not theirs — is the billing owner on the cloud account. Everything else in a takeover is recoverable with money and patience. Those three are the ones that turn a bad month into starting over.

Get control before you terminate: the access recovery checklist in priority order

Work the list in order of how hard each asset is to recover, not in order of how much it irritates you. Domain and DNS first, then cloud billing ownership, then repository organization ownership, then the app store developer accounts, then payments and email authentication, then every API key. Almost everything below can be recovered through the platform itself with proof of payment and identity — the exception is the domain, which is exactly why it goes first.

Domain registrar and DNS — the one thing that is genuinely hard to get back

The domain is the only asset on that list with no clean technical escape hatch. If the registrant contact is the agency and the registrar account is in their name, you are relying on a registrar dispute process and on evidence: invoices showing you paid for the domain, incorporation documents, prior correspondence. Build that evidence pack before you escalate. Note also that under ICANN's transfer policy a change of registrant has historically triggered a 60-day lock on moving the domain to a different registrar, and that rule has been under revision through 2026 — so check your registrar's current terms rather than assuming either way. Plan for the lock and be pleased if it does not apply.

Repository organization ownership, not just collaborator access

Being able to see the code is not the same as owning where it lives. If the repository sits inside the agency's organization, they can revoke you in one click, and your local clone — while it holds the full commit history — does not hold the issues, the pull request discussion, the CI configuration, the deployment hooks or the secrets stored at organization level. Ask for a repository transfer into an organization you own. If that request goes unanswered, clone every branch and every tag immediately, export the issue tracker, and treat the CI configuration as something you will rebuild rather than inherit.

Cloud root account, billing owner and IAM

Ownership of a cloud account follows the root credentials and the payment method, not the org chart. If your company card is on the account, providers will generally work with you on recovery. If the agency's card is on it, you are asking them for a favor — and the practical fallback is to stand up a new account you own and migrate into it, which is roughly a week of work on a small stack and considerably more once managed databases, queues and private networking are involved. This is the point where experienced hands pay for themselves; it is most of what our cloud infrastructure team does during a takeover.

App Store and Play Console developer accounts

You do not take over somebody's developer account — you transfer the app into yours. Apple's process requires the Account Holder on both teams to initiate and accept, requires the app to have shipped at least one released version, and requires both sides to be clear of pending agreements and reviews; the listing keeps its URL, its ratings and its reviews, and users see no interruption. Google Play has an equivalent transfer flow. If the agency will not cooperate at all, you are republishing under a new bundle identifier and losing your reviews and your install base, which is unpleasant but survivable. As of 2026 the Apple Developer Program costs $99 per year and Google Play charges a one-time $25 registration fee, so standing up your own accounts is never the expensive part.

Payments, analytics, email authentication and every API key

Stripe ownership transfers from the account owner in team settings, and Stripe support will act on documentation if the previous owner is gone. Analytics and Search Console re-verify off DNS, so they resolve themselves the moment the domain is yours. Everything else — the payment gateway keys, the transactional email provider, the SMS gateway, the map tiles, the model API keys — you do not recover. You rotate. Assume every key the outgoing team ever saw is compromised, issue new ones, revoke the old ones, and redeploy. Budget half a day and do it in one sitting so nothing is left half-migrated.

The 10-day takeover audit, day by day

A takeover audit is 10 working days of two engineers reading, running and instrumenting what you already own, ending in a written risk register and a re-estimate you can take to any agency. We change nothing in production during the audit. The point is to replace the question you cannot answer — is this salvageable? — with a number you can budget against.

Days 1-2: can we run it from a clean machine? (the runbook test)

We wipe a machine, clone the repository, and try to get the application running from the README alone with a stopwatch on it. Under two hours means the project was maintained by someone who expected to hand it over. Two days, with a list of environment variables reconstructed by grepping the source, means nobody ever onboarded a second developer — which predicts almost everything else we are about to find. If nothing runs at all, the first week of any engagement goes on reconstructing the runbook, and no honest agency can promise you a shipped fix before week two.

Days 3-4: dependency drift, CVE scan, secrets committed to history

We produce a full dependency tree with major versions behind, a vulnerability scan across direct and transitive dependencies, and a scan of the entire git history for committed credentials — not just the current checkout, because a secret deleted in a later commit is still sitting in the history for anyone holding a clone. A framework two majors behind is a scheduled cost, not an emergency. A framework four majors behind with unmaintained plugins pinned to it is a rewrite argument. Our security practice runs this half of the audit.

Days 5-6: data model review and migration state

This is the section that decides the rest of the engagement. We read the schema, check whether it is reproducible from versioned migrations or was changed by hand in a console, look for the usual structural tells — money stored as floating point, no foreign key constraints, soft-delete flags nobody honors, one table doing the work of four — and check whether the production data actually conforms to the model the code expects. A correct data model under a bad application is a repair job. A wrong data model is the one problem you cannot refactor your way out of cheaply.

Days 7-8: infrastructure inventory, orphaned resources and the real monthly bill

We inventory every running resource against the deployed application and flag anything attached to nothing. Orphaned resources — detached volumes, idle load balancers, a staging environment nobody stopped, a database provisioned for a launch that never came — are the most common line item these audits turn up, and cutting them often funds a meaningful slice of the rescue itself. For scale: a small production stack on a managed platform plus a managed Postgres instance typically runs roughly $50 to $400 per month at list prices as of 2026, depending on traffic and how many environments are still switched on. If your bill is an order of magnitude above that for a pre-revenue product, something is running that should not be.

Days 9-10: auth, permissions, deployment path and the written risk register

We review authentication and authorization end to end — session handling, password storage, and whether any endpoint checks ownership as well as identity — then trace the real deployment path from commit to production, including who can trigger it and whether a rollback exists. The deliverable is a risk register: every finding, its blast radius, the effort to fix it in hours, and a recommendation of fix now, fix soon, or accept. You keep that document whether or not you hire us, including if you take it to a different agency. That is deliberate. An audit you cannot take elsewhere is a sales document, not an audit.

Rewrite versus repair: the decision rule

Repair when the data model is broadly right and authentication uses a maintained library; rewrite when the data model is wrong or auth is hand-rolled. Those two dimensions predict the outcome better than code quality, test coverage, or how much you dislike the previous team. Where repair applies, it is typically 40-60% cheaper than a rewrite across the first six months. Where it does not apply, repair becomes more expensive than a rewrite inside the same window, because every fix has to be made compatible with a foundation that keeps being wrong.

The strangler-fig middle path — keep the data, replace the app surface by surface

The honest answer in most rescues is neither pure repair nor a from-scratch rewrite. You keep the database, stand up a new application alongside the old one, put a router in front, and move one surface at a time — the highest-risk or highest-traffic screen first — until nothing routes to the old app and you delete it. It takes more total engineering days than a clean rewrite, and it is the only approach that lets a live product with paying customers keep running throughout. If you have revenue flowing through the thing, this is almost always the right shape, and it is how most of our web platform rescues are structured.

What a rescue actually costs

A rescue is priced on remaining engineering effort plus an inheritance tax, never as a percentage of what you already spent. We publish three tiers and quote rescue work inside them — Launch from $1,900, Build from $6,900, and Scale quoted to scope — and the table below shows where each shape of rescue normally lands. Effort ranges assume a small team on the codebase full time; calendar time runs longer than engineering time because access recovery and approvals move on somebody else's clock.

The counter-intuitive line there is the last one. A full rebuild is genuinely cheaper than a repair once the remaining scope is large, because in a rebuild you pay for a feature once, whereas in a repair you pay to understand the existing implementation, pay to change it, and pay again to prove the change did not break something undocumented. Past roughly the halfway mark on remaining scope, that third cost stops being worth paying. Our pricing page sets out what sits inside each tier.

The 20-40% inheritance tax over greenfield, and what drives it

The same feature costs 20-40% more in a codebase you did not write. That is our estimating rule, applied across the whole remaining scope, and four things drive it.

• Comprehension time. Every change starts with reading code written under deadline pressure by someone who is not available to explain it.
• Regression risk without a safety net. With no tests, the only way to prove a change is safe is manual verification of everything near it — which is precisely what you were not paying for before.
• Constraint archaeology. Half the odd decisions in an inherited codebase exist for a reason nobody wrote down, and finding out which half the hard way is a recurring cost.
• Rework from wrong assumptions. The first fortnight produces estimates that are wrong in both directions until the mental model settles. Good teams price that in rather than discovering it in week three.

The seven things we find in almost every inherited codebase

Seven findings turn up in nearly every takeover audit we run, and together they account for most of the gap between the estimate a founder is carrying in their head and the real number. The frequencies below describe what our own audits surface. They are not survey data and we would not present them as such.

What we cannot fix cheaply

Four findings change the conversation from a rescue to a reconstruction, and you deserve to hear about them on day two rather than in week six. None of them are about code quality. All of them are about things that are missing or legally encumbered rather than merely badly done.

• No backups and no point-in-time recovery. If the only copy of your data is the running database and there is no tested restore, you are one bad migration away from having no company. This is the first thing we fix in every engagement, before any feature work, and it is not negotiable.
• License violations and resold templates. A commercial template used beyond its license, a copyleft component linked into a closed product, or stock assets with no receipt are legal exposure that engineering cannot remove. Sometimes the remedy is buying the correct license. Sometimes it is replacing the component outright.
• A custom CMS with no export path. Years of content locked inside a bespoke admin tool with no API and no export is a migration project in its own right, and its cost scales with content volume rather than with code size. It is frequently the largest single line in a rebuild quote.
• Infrastructure owned by the previous vendor's account. If the account is theirs and they will not transfer it, you are rebuilding the environment from an inventory rather than migrating it — and if the data lives there too, you are negotiating rather than engineering.

Getting your code out of an unresponsive agency

Most of what you need does not require the agency's cooperation — it requires proof of ownership routed through each platform, which is why the access table above is ordered the way it is. Cooperation matters for exactly three things: the repository organization, the app store transfers, and any undocumented knowledge living in somebody's head. Everything else you can simply take. Work the recoverable assets first, so that by the time you are negotiating you are negotiating over three items rather than thirty.

The contract levers that actually work

Read your agreement for four clauses specifically: who owns the intellectual property and whether that ownership is conditional on full payment, whether there is a defined handover obligation with a deliverable list, whether there is a termination-for-convenience notice period, and whether disputes go to arbitration. Conditional IP assignment is the clause that most often surprises founders — if the contract assigns ownership on final payment and an invoice is outstanding, withholding the code may be contractually permitted however unreasonable it feels. Establish that fact before you draft anything, because it determines whether you are making a demand or an offer. None of this is legal advice; it is the order we see these situations resolve in.

What to put in writing, and in what order

Vague requests are what stall. Specific, itemized, dated requests are what move.

1. 1A written handover request naming every asset — repository URL, cloud account ID, registrar, developer account team IDs, each third-party service — with a deadline of 5 to 10 business days.
2. 2A short follow-up confirming which items have been delivered and which remain outstanding. This creates the record you may need later and, often, the pressure that resolves it.
3. 3A formal notice referencing the specific handover clause in the agreement, sent to whoever signed the contract rather than into the project channel.
4. 4If an invoice is outstanding and the code is worth more than the balance, an offer that pays it against simultaneous transfer of the named assets. Settling is regularly cheaper than being right.
5. 5Only then a lawyer's letter — and only once you have already recovered everything the platforms will hand you directly.

When rebuilding is cheaper than litigating

For most small and mid-sized products, the arithmetic favors rebuilding. Legal action over a stalled build takes months of your attention, costs real money before anything is recovered, and ends with you holding a codebase written by a team you no longer trust. If the audit says the remaining scope is a rebuild anyway, the code you are fighting over has limited value — what actually matters is your data, your domain and your users, all of which sit further up the recovery list. Pursue the contract where the sums are large or the data is genuinely trapped. Otherwise take the loss, keep the invoices as evidence, and spend the money on shipping instead.

Three rescue shapes, and what each one costs

Rescues fall into three recognizable shapes. These are patterns, not case studies — we do not publish client figures or attach invented outcome metrics to real engagements, and you should be skeptical of any agency that does. The products themselves are on the portfolio if you want to see shipped work rather than numbers.

The ninety-percent app. The build is nearly done, the last 10% has been nearly done for four months, and nobody can articulate what remains. The audit almost always finds that the missing 10% is not features but everything around them: no deployment path, no error tracking, no environment separation, and a handful of flows that work in the demo and fail on real data. Effort is typically 3 to 6 engineer-weeks and it lands in the Build tier. The fix is boring infrastructure work, which is precisely why it never got done.

The silent vendor. The product is live and taking payments, nobody has committed in months, and the developer has stopped replying. Week one goes entirely on access recovery, week two is the audit, and only then does anyone write code. The codebase is frequently more salvageable than the founder fears — a running product with customers has already been tested against reality, and what is missing is ownership rather than engineering.

The wrong foundation. A working product on a data model that cannot express what the business now does, so every new feature takes longer than the last. This is the one where the audit recommends the strangler-fig path: keep the data, migrate the schema in versioned steps, replace surfaces one at a time. It is the largest of the three engagements, usually 10 to 20 engineer-weeks, and it is the only one where doing nothing costs more than the fix.

How we quote a rescue

We do not quote a rescue blind, because the difference between a two-week stabilization and a three-month rebuild is not visible from a demo — it is visible from the repository, the database and the cloud account. The sequence is: a fixed-fee audit agreed in writing before it starts, 10 working days of read-only investigation, a risk register and effort estimate you keep regardless of what you do next, then a phased quote against our published tiers. The audit fee sits below the $1,900 Launch tier and is credited against the first phase if you continue with us. If you take the findings to another agency, they are still yours — and they will make that agency's quote more accurate too.

When a rescue is the wrong call, and when we are the wrong agency

A rescue is the wrong call more often than agencies admit, and there are four cases where we will say so on the first call. If the product has no users, no revenue and a small scope, ignore the sunk cost and start clean with a sharper brief — you will be live faster and the audit fee is better spent on the build. If the original developer is in-house and simply overloaded rather than absent, adding capacity and closing the deployment and testing gaps beats replacing anyone, and it costs less. If the broken thing is a marketing site on a mainstream CMS or a site builder, a formal takeover audit is overkill for the problem. And if the codebase is a stack we do not work in daily, we will tell you rather than learn it on your budget.

There are honest limits on what we offer, too. We do not claim certifications, partnerships or an on-site presence we do not have, and if your situation needs a formal attestation or a local team in the room, that is a real requirement and we are not the right fit for it. What we do well is the engineering: recovering the stack, reading the codebase honestly, and handing you a number you can plan against. If that is the gap you have, talk to us.

Start with the audit

You cannot make a good decision about a stalled build from a demo and a feeling. Ten days of investigation converts the whole situation into a document with numbers in it: what is wrong, what it costs to fix, what is not worth fixing, and how long before something ships. Bring the repository, the cloud account and whatever access you still hold. If you hold none of it, bring that too — it is a more common starting point than you would expect, and the first week's work is the same either way.