The deadline has gone. Most of the budget went with it. Your vendor has either stopped replying or is explaining, once again, why the next fortnight will be different.
What follows is the sequence we use when we walk into this. It starts tonight, it starts with something that costs nothing, and it does not require you to have decided yet who builds this software next.
The first 48 hours: get control of what you already own
Do this before the audit. Before the lawyer. Before the difficult conversation.
Founders routinely discover, weeks into a dispute, that the domain sits in the vendor’s registrar account, the repository belongs to a developer’s personal profile, and the cloud bill goes to somebody else’s card. While the relationship works, none of that matters. The moment it turns adversarial, all of it becomes leverage, and getting it back moves at the speed of support tickets and legal letters rather than the speed of your business.
Work through this quietly. Finish it before you signal that you are leaving.
Code and infrastructure
Domains and DNS
Third-party accounts
App stores
Paper
Two ordering details catch people out.
Sequence ownership ahead of payment. If a final invoice is outstanding, that money is the strongest position you hold. Confirm you can log into every account independently, then pay. Not the reverse.
The domain needs particular care. Under ICANN’s transfer policy, changing the registered owner of a domain triggers a sixty-day lock that blocks moving it to a different registrar. So if you may need the domain in your own registrar account, move the registrar first, then update the ownership details. Doing those two steps in the wrong order can strand your production domain in a hostile account for two months. Almost nobody knows this until it happens to them.
A second opinion, before you decide anything. If you want someone technical to look at what you have and tell you plainly what state it is in, book a call with us. It is an assessment conversation, not a pitch, and there is no obligation attached to it.
Keep the lights on, stop everything else
Freeze new feature work. Not the servers, not the payments, nothing your customers touch. Feature development is what burns the remaining budget while nobody can honestly say what state the product is in.
Three things stay running: production, security patches, and anything carrying a legal or contractual deadline. Everything else waits until you have an assessment.
Getting an honest assessment when you are not technical
You need to know what actually exists, and not as a percentage supplied by the people whose work is in question.
A proper technical audit covers architecture and whether it can carry the load you expect; whether the code builds and deploys reproducibly from a clean checkout; dependency health and known vulnerabilities; test coverage; the database schema and data integrity; security exposure; and a tiered list of problems split into blocking, high-risk and cosmetic.
Published market rates put a review of a small to mid-sized web application at roughly $2,000 to $10,000, with enterprise systems running above $20,000. Expect one to two weeks for something of MVP scale, and two to four weeks for a larger multi-service system. No independent benchmark exists for this pricing. Those figures come from what firms publish about themselves, so treat them as a range rather than a quote.
One condition, and it costs us work: engage the auditor on the written understanding that they will not bid on the rebuild. An assessment written by the firm hoping to win the replacement contract has an obvious pull toward “start again.” Ask for that in writing before you engage anyone, ourselves included.
The deliverable you want is short. What works. What is broken. What is salvageable. Roughly what effort each remaining path costs. Anything past about fifteen pages is usually padding.
The decision: four paths
| Path | Choose this when | Rough time and cost | What tends to go wrong |
|---|---|---|---|
| Continue with the current vendor | The audit finds the codebase sound. Communication has been poor but honest. Delays trace to scope changes and slow decisions as much as to the team | Lowest. Weeks, not months. Usually a re-scope plus a revised payment schedule | Nothing changes, because the real cause was never named out loud |
| Replace the vendor, keep the code | The code is workable but the relationship or the team’s capability is not. You have full access and clean IP | Four to eight weeks before comparable velocity returns, plus audit and onboarding | Handover is underestimated. The new team quietly rewrites what it does not understand |
| Rebuild | No reproducible build, no meaningful tests, unsupported dependencies, or a data model that cannot carry the business | Assume most of the original build cost again | You rebuild the same unclear requirements and arrive in the same place |
| Stop | The assumption behind the product has not held, or the remaining cost to launch exceeds any realistic return, or the company needs the runway more than the software | A write-off, plus asset recovery | Sunk cost keeps it breathing for another two quarters |
Stopping deserves more than a table row. It is the right answer more often than it is the chosen one. If the honest response to “would we start this project today, at this price, knowing what we now know?” is no, then money already spent is not a reason to continue. Recover the assets, write down what was learned, and put the remaining runway somewhere it can work.
When you should stay exactly where you are
Switching vendors is expensive, and it is frequently the wrong move.
Stay if the audit comes back clean. A working deployment pipeline, a team that understands why the awkward parts are awkward, and a codebase that builds are worth a great deal. A new team starts at zero on all three, and four to eight weeks of ramp-up is normal even when nothing goes wrong.
Stay if the delays trace back to changing requirements. PMI’s 2018 Pulse of the Profession found 52% of projects experienced scope creep, up from 43% five years earlier. If your specification kept moving, a new vendor will hit the same wall in month three and you will have paid twice to learn it.
Stay if the vendor is still telling you the truth. A team that says “we are eleven weeks behind, and here is why” sits in a completely different position from one that has gone silent. Honesty under pressure is rare and worth more than a fresh start.
A frank re-scope, a revised milestone schedule and a fortnightly demo you personally attend will resolve more of these situations than a change of supplier will. We would rather say that than take the work.
Contracts, ownership and leverage, in practical terms
We are not lawyers and none of this is legal advice. Speak to one in your jurisdiction. What follows is what tends to matter in practice.
Paying for software does not automatically mean you own it. This surprises almost everybody. In the United States, “work made for hire” applies to independent contractors only across nine specified categories of work, and software is not one of them, which makes a written assignment of copyright the reliable mechanism. Under UK law the contractor generally holds the copyright by default absent a written assignment, leaving the client with at best an implied licence. The EU software directive vests economic rights in the employer automatically for employees, not for commissioned contractors. India’s Copyright Act treats work under a contract of service as the employer’s, while work under a contract for service stays with the developer unless assigned, and the commissioning exception covers artworks and films rather than software. For GCC jurisdictions, take local advice, because the position varies.
Search your contract tonight for the words “hereby assigns.” A promise to assign at some future point is weaker than a present assignment, and knowing whether it is there changes how you negotiate.
On leverage. Outstanding payment is usually the strongest card you hold, and it disappears the moment you settle. Withholding payment carries its own consequences, so decide deliberately rather than by drift.
Usually worth pursuing: return of accounts, credentials and source code; a signed IP assignment where one is missing; a defined handover period. These cost little to ask for, and vendors often concede them to close the matter cleanly.
Rarely worth pursuing: damages for delay. Proving loss is slow and expensive, and the money generally costs more to chase than to write off. Litigation also freezes the project while you fight it, which is the opposite of what you need right now. If your contract contains a termination for convenience clause, read that first. Exiting on notice without having to prove breach is dramatically faster than arguing about fault.
Source code escrow comes up at this stage. It runs roughly $1,000 to $6,000 a year and it earns its cost where you depend on a single critical vendor you cannot control. For a typical custom build, owning the repository from day one achieves the same protection for nothing.
Moving to a new team without losing another quarter
Three practices decide whether a handover takes three weeks or three months.
Insist on a deployment in week one. Not a feature. Any change at all, however small, shipped to production by the new team through the existing pipeline. It proves the build works, the access is complete and the environment is understood. Everything else is theory until that happens.
Buy an overlap. Two weeks of the outgoing team’s time, paid for, with specific questions prepared in advance. It feels uncomfortable and it is far cheaper than reverse-engineering a payment integration.
Resist the rewrite. A new team’s instinct on inheriting unfamiliar code is to replace it. Occasionally correct, usually premature. Ask for a stabilise-first plan, and a rewrite proposal with a business case attached, in that order.
Whether the next team is an agency, a dedicated squad or your own hires is a separate question, and the team model that fits is worth settling before you sign anything. When you are choosing your next development partner, ask specifically what they have taken over from someone else, not only what they have built from scratch. You can see a project we took over and shipped in our case studies.
The 30-day recovery plan
Days 1 to 2. Secure access. Owner: you. Work the checklist above, end to end. Announce nothing until it is complete.
Days 3 to 5. Establish the facts. Owner: you. Commission the audit. Assemble the contract file. Write your own one-page account of what was promised, what was paid, and what actually arrived.
Days 6 to 14. Assessment. Owner: the independent auditor. Expect one to three weeks depending on size. While it runs, have a direct conversation with the vendor and ask what they believe it will take. Their answer is useful information either way.
Days 15 to 18. Decide. Owner: you. Use the table above. Write the decision down along with the reasoning, because you will be asked to defend it later and memory drifts.
Days 19 to 25. Set up the next phase. Owner: you and the incoming team. Contract, IP assignment, milestone payments, access from day one. If you are staying put, this is where the re-scope and revised schedule get signed.
Days 26 to 30. Prove it moves. Owner: the delivery team. One deployment to production. One demo. A backlog you can read without a translator.
Thirty days will not finish your software. It ends the uncertainty, which is the thing currently costing you most.
About the failure statistics you will read tonight
You will find plenty of them, and many are older than they appear.
The widely repeated claim that roughly a third of projects get cancelled traces to a survey first published in 1994, still circulating today without a date attached to it. That survey has also been criticised in peer-reviewed work for defining failure purely as estimation accuracy, and its underlying data has never been public.
The best-known research on large IT projects, from McKinsey with Oxford’s Saïd Business School, examined more than 5,400 projects and found they run 45% over budget and 7% over schedule while delivering 56% less value than predicted, with 17% going badly enough to threaten the company’s existence. Solid work. Published in 2012. The academic companion study of 1,471 projects reported an average cost overrun of 27%, but with one in six turning into a “black swan” averaging 200% over budget. That was 2011.
The most current picture comes from public auditors rather than consultancies. The US Government Accountability Office continues to report chronic failure and overruns across federal IT, which spends over $100 billion a year and has sat on its high-risk list since 2015.
Read those figures as reassurance rather than diagnosis. You are not an outlier. What you are dealing with is common enough to have well-worn solutions.
Not ending up here again
Our industry has a real problem with this, and naming it is more useful than defending the profession. Too many agencies sell certainty they cannot deliver, staff projects with whoever is free rather than whoever fits, and hold client assets in their own accounts through inertia rather than malice. The outcome is identical either way.
Some of it does sit on the client side, and this is the right moment to say so rather than while the fire is burning. Requirements that changed every fortnight. Decisions that took three weeks. No single person empowered to sign anything off. Those conditions wreck capable teams too.
What prevents a repeat is mostly contractual and mostly dull:
- Every account in your company’s name from day one. The vendor gets access, not ownership.
- A present-tense IP assignment. “Hereby assigns,” with a further assurances clause attached.
- Milestone payments against accepted deliverables, with the final tranche released only after handover is complete.
- Exit obligations written in: credentials, documentation and knowledge transfer within a defined number of days of termination, for any reason at all.
- A termination for convenience clause, so leaving never depends on proving fault.
- Documentation as an acceptance criterion rather than a favour. A README that lets a new developer run the project locally is a contractual deliverable.
- A demo every two weeks that you personally attend. Not a status report. Working software, on a screen, in front of you.
That last one catches problems earlier than any of the others, and it is free. It also aligns closely with what makes projects succeed more generally, alongside picking from the outsourcing models that work for the size you actually are.
Where to start tonight
Work the 48-hour checklist. It costs nothing, it takes an evening, and it is the only part of this that gets harder every day you wait.
Then get an honest read on the code before you decide anything else.
If you want a second opinion from an engineering team that can take over, we will look at what you have and tell you what we see. Book a technical assessment call whenever suits you. No obligation, and if the answer is that you should stay with your current vendor and renegotiate, we will tell you that instead.
Frequently asked questions
Secure access before anything else. Confirm you own the code repository, cloud account, domain, database and third-party accounts, and that you can log into each one independently. Do this before raising a dispute. Once a relationship turns adversarial, recovering access moves at the pace of support tickets and lawyers.
Not automatically. In the UK, EU and India, the contractor generally retains copyright unless a written assignment exists. In the US, "work made for hire" does not cover software written by contractors. Check your contract for a present-tense assignment clause, and take legal advice in your jurisdiction.
If you already hold repository ownership and cloud access, yes, immediately. If the vendor controls those accounts, your routes are contractual exit clauses, formal legal demand, and platform-level support with proof of ownership. Recovery after the fact is slow and uncertain, which is why securing access first matters so much.
Published market rates suggest roughly $2,000 to $10,000 for a small to mid-sized web application, and above $20,000 for enterprise systems. Expect one to two weeks at MVP scale, two to four weeks for larger systems. Engage an auditor who agrees in writing not to bid on the rebuild.
Rebuild only when the audit finds no reproducible build, no meaningful tests, unsupported dependencies, or a data model that cannot carry the business. Otherwise, fixing is faster and cheaper. Rebuilding on the same unclear requirements usually reproduces the original outcome at full cost.
Plan for four to eight weeks before comparable velocity returns. Shorten it by requiring a production deployment in week one, buying two weeks of paid overlap with the outgoing team, and refusing a rewrite until you have seen a stabilise-first plan with a business case.
