In 30 seconds
- First secure what you own: the code repository, the hosting and app store accounts, the domains and every password.
- Then get an independent audit of what actually exists. Most stalled projects are partly reusable.
- Decide to rescue or restart on evidence, and restart progress with a written scope and a demo every week.
It usually happens slowly. Replies take a day, then a week. The demo is “nearly ready”. The deadline moves twice, and nobody can tell you what is actually finished.
The first job is not to finish the project. It is to make sure you own it.
Taking a stalled project back
Five steps, in this order. Do not skip the first one.
How it works
Taking a stalled project back
The steps, in words
- Secure the keys: Code, hosting, app store accounts and domains, in your name.
- Audit what exists: What runs, what is half-built, what is risky.
- Decide: rescue or restart (a person decides): On evidence, with a written estimate for each.
- Write the remaining scope: What is left, in plain words, with priorities.
- Weekly demos again: Working software every Friday, not status emails.
First, secure what you own
The code repository
GitHub, GitLab or Bitbucket, in your company’s account, with the full history. A zip file is not enough.
Hosting and servers
The cloud account or hosting panel, billed to you, with admin access.
App store accounts
Apple and Google developer accounts in your company’s name. Moving an app between accounts later is slow.
Domains and email
The domain registrar login, DNS, and the email services the app sends from.
Every password and key
Payment gateways, SMS, maps and AI services: the keys, and who can see them.
Designs and documents
Design files, requirements and any documentation, however rough.
Ask politely and in writing. Most agreements give you the work you have paid for; if yours is unclear, a short letter from your lawyer usually settles it.
What an audit tells you
Before anyone writes new code, someone independent should read the existing code and run it.
Rescue or restart?
Rescue it
- Most features work, and the code is readable
- The technology is current and supported
- Tests exist, or can be added around what works
- The problems sit in a few places
Restart
- It does not build, or only on the old vendor’s machine
- An outdated framework with no security updates
- Every change breaks something else
- Little of what was paid for actually works
Restarting does not mean starting from nothing. Designs, requirements, data and lessons carry over, and a new build that knows exactly what to make is usually faster than the first one.
In practice
A booking app, eight months late
Say a clinic chain paid for a booking app promised in four months. At month eight, the vendor stops replying.
- Week 1: the clinic moves the code repository, the cloud account and both app store accounts into its own name.
- Week 2: an audit finds the patient booking screens work, the admin panel is half-built, and payment keys are stored in the code.
- Week 3: the decision is to rescue: fix the security issue, finish the admin panel, keep the rest.
- From week 4: a demo every Friday, and a written plan for the launch.
How to stop it happening again
A demo every week
Working software you can click, not a status report.
Your repository from day one
The team works in your account, so nothing can be held back.
A written scope
What is in, what is out, and how changes are priced.
A named lead
One person who answers within a working day.
We have built this
How we run projects: a demo every week
You get a written scope, a demo of working software every week, and launch support from the same team: the same rhythm we bring to a project we take over.
A stalled project is stressful, but it is rarely lost. Secure what you own this week. Everything else can be decided calmly after that.
Frequently asked questions
Who owns the code if the vendor stops replying?
It depends on your contract, but most agreements give you the work you have paid for. Ask for the repository and accounts in writing first; if the contract is unclear, a lawyer’s short letter usually settles it.
Can a new team continue someone else’s code?
Often, yes. An audit shows how much is reusable. Readable code on a current framework can usually be finished; code that only builds on the old vendor’s machine usually cannot.
How long does an audit take?
It depends on the size of the project. For most apps and websites it is days, not months, and you get a written report with the options.
Should we tell the old vendor we are moving?
Yes, politely and in writing. You need their help for the handover, and a calm, specific request gets a better response than a dispute.
Want this for your business?
Ask ET on our website, or book a free 30-minute call with a project lead, not a salesperson.
