Key takeaways
- →Assume 72 hours of access: recover source code with full git history, a complete database dump, and owner-level access to cloud, domains and app stores before anything else.
- →A zip file of source code is not a handover. Without history, migrations and environment config, a new team loses two to three weeks before it can run the product locally.
- →Read the IP assignment clause first. Many contracts transfer ownership only on project completion, which is exactly what never happens in a collapse.
- →Pay for a 3 to 5 day code audit before choosing between inheriting, refactoring and rebuilding. Inheriting a working codebase is often 2 to 6 weeks to a deployable build against 3 to 6 months for a rebuild.
- →Hire a tech lead and a DevOps engineer first, then full-stack developers. Diagnosis does not parallelize, so volume hiring in week one slows the recovery down.
When your software vendor shuts down, assume roughly 72 hours of usable access remain and use them to recover three things, in this order: the source code with its full history, a complete database export, and ownership of the accounts your product runs on (cloud, domains, app stores, payment processor). The rest can wait. A company that loses its vendor overnight rarely loses the product because of bad code. It loses it because nobody could log in where the code lived, and the credentials were gone by the time a new team showed up.
This is not a hypothetical risk. In May 2025, Builder.ai, an app-building platform with large enterprise backers, entered insolvency proceedings and the platform was shut down, leaving the companies whose products had been built on it dependent on a vendor that no longer existed. Smaller agencies fail far more often and far more quietly. The playbook below is what we would run in the first 30 days, and what we would put in the next contract so it cannot happen twice.
The first 72 hours decide how much you keep
When a vendor collapses, access disappears unpredictably. Cloud accounts get suspended for nonpayment, repositories hosted under the vendor's organization vanish with the subscription, and the one engineer who still answers email stops answering. Treat the first three days as a salvage operation, not a planning exercise.
Work the list below in parallel, not in sequence, and give each item to a named person on your side. The single most common mistake is accepting a zip file of source code and calling it a handover. A zip file without git history, environment configuration, or migration scripts can cost a new team two to three weeks of archaeology before they can even run the thing locally.
- Source code with history. Clone each repository with its full history, branches and tags included. When a repository lives in the vendor's organization, mirror it the same day to an account you own.
- Data. Take a full database dump along with the schema and migration files. A second dump 24 hours later lets you prove nothing was silently truncated.
- Accounts and billing. Get root or owner access to cloud accounts and move billing to your own card. An account in the vendor's name can be frozen by the vendor's creditors.
- Distribution. Begin the app store and Play Console ownership transfers right away. They are approval processes, not button clicks, and can take days.
- Secrets. Gather environment variables, API keys, signing certificates, and webhook endpoints, then rotate every one of them as soon as you are in control.
If you get nothing else, get the code, the data, and the domain. Those three let you rebuild. Missing any one of them turns a recovery into a restart.
Find out what you actually own, because it is usually less than you think
Most buyers assume paying for software means they own it. Ownership actually lives in the contract. A surprising number of development agreements assign intellectual property only on final payment or at project completion, neither of which may ever happen now. Before spending a dollar on recovery, pull the master services agreement and every statement of work, then have someone read the assignment clause, the license clause, and the termination clause.
Four questions settle almost every case. Does the contract assign IP to you, and is that assignment conditional? Are there third-party components licensed to the vendor rather than to you, such as a paid UI kit, a mapping SDK, or a proprietary module the vendor reused across clients? Is there a source code escrow agreement, and do its release triggers include insolvency rather than only breach? And who is the registered owner of your domains and store listings?
Ask the escrow question even if you do not remember signing one, since escrow often sits in an appendix nobody read. With narrowly written release triggers, an administrator can refuse to release code during an insolvency, exactly the moment you need it.
If the vendor has already entered formal insolvency, file your claim with the administrator and talk to your payment provider about chargebacks on recent invoices, but do not let either process delay the technical work. Legal recovery runs on a timeline of months. Your product runs on a timeline of days.
Triage: what must stay alive, and what can break for a week
Once the assets are under your control, resist the urge to fix everything. Divide the system into three buckets and staff only the first one right away.
Must not break: anything that takes money, stores customer data, or carries a contractual uptime promise. In most cases that covers payments, authentication, the production database and its backups, and whichever integration your largest customers depend on. Check that automated backups still run and still restore. Backups configured inside the vendor's cloud account are often the first thing to die.
Can degrade: admin tooling, internal dashboards, reporting, scheduled emails. Here, a week of manual workarounds costs less than a rushed deployment by a team that does not yet know the system.
Can stop entirely: the roadmap. Freeze new features for 30 days. Each hour a new team spends shipping features is an hour it does not spend learning the codebase it will own for the next three years.
A practical rule: deploy nothing to production during the first week unless it is a security fix or a payment fix. You do not yet know what the deployment process really does, and whoever did know has left.
Rebuild, inherit, or re-platform: run the numbers before you choose
When people inherit a dead vendor's codebase, the emotional reaction is to throw it away. Sometimes that is right. More often it is an expensive overreaction, since the code encodes years of business rules found nowhere else, your own documentation included. Pay for a short technical audit before deciding: a senior engineer spends three to five days reading the code, running it, and reporting on test coverage, dependency health, and how far the architecture sits from what you need next. Our guide to auditing a codebase before an acquisition follows the same checklist, which applies cleanly here.
| Option | What it costs you first | Time to a deployable build | Choose it when |
|---|---|---|---|
| Inherit the codebase | A 3 to 5 day audit, then onboarding time for the new team | 2 to 6 weeks | The app works in production, tests exist, and the stack is mainstream |
| Inherit, then refactor in place | Audit plus a scoped remediation sprint | 4 to 10 weeks | The product is sound but the deployment, tests, or security are not |
| Rebuild the core, keep the data | Full discovery and a new build, with migration scripts | 3 to 6 months | The code is undocumented, untestable, or built on a dead framework |
| Move to an off-the-shelf product | Licensing plus data migration plus process change | 1 to 3 months | Your product was never the differentiator, only the workflow was |
Two warnings on this table. Ranges are planning estimates for a mid-sized web or mobile product, not quotes, and they assume you already have the code and data in hand. And if the answer is rebuild, do not let the rebuild quietly become a re-platform onto another closed system. Trading one vendor's lock-in for another's is how companies end up doing this twice. If you are reopening the stack question, choosing a tech stack deliberately matters more now than it did the first time, and estimating the development cost properly will keep the board conversation honest.
Staff the recovery in the right order
Instinct says to hire a full team at once. That is the wrong shape. Because the early work is diagnosis, and diagnosis does not parallelize, a recovery needs a small, senior group first. Add volume only once someone can explain how the system fits together.
Hire in this sequence. First comes one senior engineer or tech lead who can read unfamiliar code quickly and will own the audit. Second, a DevOps engineer, since in a vendor collapse the infrastructure is nearly always the weakest link: undocumented deploys, expiring certificates, backups nobody has tested. Third, one or two full-stack developers to pick up feature work and absorb what the lead has learned. It is worth adding a QA analyst before the first production deployment, not after it. A solution architect earns their rate only if you are truly rebuilding.
On budget, US hourly bands on vetted marketplaces top out around $200 for a solution architect, $160 for a tech lead, $150 for a DevOps engineer, $145 for a full-stack developer, and $80 for a QA analyst. Agency rates run meaningfully higher. For a 30-day recovery, a lead plus a DevOps engineer part-time is a realistic opening position, far cheaper than a six-person team learning the codebase all at once.
Whoever you bring in, give them a written handover from your side on day one: what the product does, who the customers are, what is on fire. The people who recover fastest are the ones who treat this like a normal onboarding under time pressure rather than an emergency. Our notes on working with dedicated developers apply here too, with the schedule compressed.
Five clauses that end lock-in for good
Any vendor failure carries the same structural lesson: control was handed over long before the vendor collapsed. Independent analysts who advise buyers on large software programs argue the same point. Whoever owns the roadmap, the accounts, and the internal knowledge controls the relationship, while a party that owns none of those is managed by its vendor instead of managing it. The fix is contractual, and it takes five clauses.
- Unconditional IP assignment on payment. The code becomes yours as each invoice is paid, not when someone declares the project complete. In a collapse, completion is exactly what never happens.
- Continuous handover. Work gets pushed every day to a repository your company owns, inside your organization, with your admins. The clause that strands people is the milestone-based handover.
- Escrow with the right triggers. If you rely on source escrow, list insolvency, administration, and sustained non-performance as release triggers, not breach alone.
- Infrastructure in your name. Cloud accounts, domains, store listings, and payment processors are registered to you and billed to you. The vendor receives delegated access that you can revoke in a minute.
- A testable exit runbook. Documentation only counts if a new team can use it to deploy from scratch. Once a year, test it by having someone outside the project follow it.
Two further habits cut exposure with no contract at all. Avoid putting a whole program in one supplier's hands when it can be split, and keep enough internal technical competence to judge what you are told. A buyer unable to evaluate the work cannot tell a delay from a disaster until the invoices stop being paid.
What to do this week
Where your vendor has already gone dark, work the 72-hour list today and book a technical audit for next week. With a vendor still operating, spend an hour on something cheaper: open your contract, check who owns the repository and the cloud account, and try to answer one question honestly. If this vendor disappeared on Friday, could a new team deploy your product by the following Friday? Should the answer be no, the gap you just found is your real risk, and it can be fixed now for a fraction of what it costs during a collapse.
Once you are ready to staff the recovery, begin with one senior lead and one infrastructure engineer instead of a full team. You can hire DevOps engineers and full-stack developers on short engagements. That is the right level of commitment while you are still deciding whether to inherit the codebase or rebuild it.
Frequently asked questions
What should I do first if my software vendor shuts down?
Access comes before anything else. Clone every repository with its full history into an account you control, take a complete database dump that includes schema and migration files, and move cloud, domain and app store ownership into your own name. App store transfers should start the same day: they are approval processes, and they take days. Look at the code itself or talk to lawyers only after those are secured.
Do I own the source code if the development company goes bankrupt?
That depends entirely on your contract. Many development agreements assign intellectual property on final payment or on project completion, so when either condition is unmet, the code may still sit with the vendor's estate. Check the assignment clause, any third-party components licensed to the vendor instead of to you, and whether a source code escrow exists that lists insolvency as a release trigger. Register a claim with the administrator, but start technical recovery without waiting for it.
Is it cheaper to rebuild or to take over the existing codebase?
When the product runs in production, tests exist and the stack is mainstream, taking over is usually cheaper: plan 2 to 6 weeks to reach a deployable build, against 3 to 6 months to fully rebuild a mid-sized product. A rebuild wins if the code is undocumented, untestable or built on a framework nobody maintains. The cheapest way to tell the two situations apart is a short senior audit lasting three to five days.
How do I stop this happening with the next vendor?
Five things belong in the contract: unconditional IP assignment as invoices are paid, daily pushes to a repository your company owns, escrow that has insolvency as a release trigger, cloud and domain accounts registered and billed in your name, and an exit runbook that someone outside the project tests once a year. Keeping enough internal technical judgment to evaluate the work is the non-contractual half of the same protection.
Hire vetted talent