What can you do with a stalled or abandoned software build?

If a software build has stalled, do four things in order: secure everything you are entitled to, find out what state the work is in, decide whether to repair, rebuild or stop, and restart with a smaller, clearer scope. Skipping straight to hiring a new team is how people pay twice for the same mistakes.

Why do software projects stall?

The reasons are usually ordinary. The scope kept growing while the budget did not. The developer was one person who got busy or left. Requirements lived in chat messages and nobody wrote them down. The first version worked in a demo but not with real users. Or the relationship simply broke down.

Knowing which reason applies matters. If the code is the problem, a new team can help. If the scope was the problem, a new team will hit the same wall.

What do you need to secure first?

Before anything else, gather what you should already have:

• The source code repository (GitHub, GitLab or Bitbucket), with you or your company as the owner.
• Hosting and server access: cloud accounts, panel logins, database access.
• The domain name and its registrar login.
• Third-party accounts: payment gateway, email service, SMS or WhatsApp provider, app store developer accounts, analytics.
• Design files, documents, and any credentials the app uses.

Check each account is registered to you, not to the developer's personal email. If an app store account or domain sits in someone else's name, begin the transfer now, politely and in writing.

Never share passwords by pasting them into chat. Ask for transfers of ownership or new invitations to your own email instead.

How do you check what state the code is in?

Ask an independent technical reviewer to look at it, not the person who wrote it. A useful review answers these questions in plain language:

• Does the app run, and can it be built and deployed from scratch by someone new?
• How is the code organised, and could another developer follow it?
• Are there automated tests, and do they pass?
• Are the libraries up to date, and are there known security problems?
• How are passwords, payments and personal data handled?
• What is finished, what is half-built, and what is missing?

The output should be a short written report with a recommendation. Our tech second opinion is built around this kind of read, whether the build is yours or you are comparing quotes.

Should you fix it, rebuild it or stop?

A rough guide:

Repair when the core design is sound, the main features work, and the problems are bugs, gaps or missing finishing work. This is the typical case for a build that stopped at 70 or 80 percent.

Rebuild when the data model is wrong, the code is tangled enough that every change breaks something else, or the technology is outdated or unsupported. You can still reuse designs, user research, content and some data.

Stop when the original idea no longer makes sense. It is better to say so than to finish something nobody needs. A short discovery stage can tell you quickly.

Be careful with sunk cost. The money already spent is gone either way. The only useful question is which route gets you to a working product with the least additional risk.

How do you restart without repeating the problem?

Make the restart smaller and clearer than the original.

1. Write down the one job the product must do and the first version's scope. Our guide on how much of an MVP to build first helps with this.
2. Split the work into short stages, each ending with something you can see and use.
3. Keep requirements in one document that everyone can read, not scattered across chats.
4. Hold a short review at the end of each stage before the next one starts.
5. Make sure code, accounts and documentation are in your name from the first day.

A new team should also write down how to run the system: how to build it, how to deploy it and where things live. If it is not written down, it is not handed over.

What about the data and the users?

If the app already has users, protect their data first. Take a backup of the database and store it somewhere you control. Check whether personal data is being collected lawfully and kept safely, in line with the Digital Personal Data Protection Act, 2023 for Indian users. If the existing app has weak security, closing the obvious gaps comes before adding features.

What should you ask a new team before hiring them?

Ask how they will review the existing work, whether they will give you a written recommendation before committing to a plan, who will actually do the work, how they handle ownership of code and accounts, and what happens after launch. A team that is happy to say "rebuilding is not the right choice here" is more trustworthy than one that always proposes a rebuild.

You can read how we handle this under product rescue and Product Development. This is the kind of work we do when a build has stalled: review first, then a recommendation, then a plan you can say yes or no to. If you would like us to look at yours, start with a tech second opinion or Let's Talk.