How to rescue a software project that stopped before launch

Secure access before judging anything. Ask the previous team for the repository itself, not a zip file, because you want the full commit history, every branch and the deployment scripts. A zip hides force-pushes.

Then move ownership. The Git organisation, domain registrar, cloud console, Apple developer account and Google Play account should all sit under your company email with two-factor sign-in.

Do it even when everyone is friendly. It costs an afternoon. Projects stall for reasons nobody planned for, and a departing developer holding the only login to the staging server is a common second problem.

Find the original scope document, quotation or milestone list, pair each line with the code, then run the application locally and click through every screen beside it.

A reviewer should also read the structure. Check how the database tables are laid out, whether passwords are hashed and whether secrets sit in the repository, because these findings decide if the foundation holds.

Expect surprises both ways. Some screens look polished with nothing behind them, while unglamorous back-end work such as invoice numbering or the stock ledger turns out solid.

Make a plain table. Each row is a feature from the scope, and the columns say if it works fully, partly, only as a screen or not at all.

Test with real data. Dummy rows hide faults that real ones expose, such as a duplicate customer record or a timezone bug, and nobody sees them until launch week. A login that works for the test account may fail for a long email address, and a report with ten rows may time out at ten thousand.

Rate the effort to finish each row. A rough band of small, medium or large is enough at this stage, because the sum only has to show whether completion costs less than a restart.

Finish when the foundation is sound and the gaps are mostly features, and restructure when the data model is wrong but the screens are usable. Restart only when the code is unreadable, untestable or insecure beyond a sensible repair cost, and a second look at the database design should confirm it.

Sunk cost pulls hard. The money already spent should not decide the next step, because only the cost of reaching a working release from today matters, including testing and the deployment itself. Nothing else counts.

Ask a second team for an independent view whenever the first assessment came from the people who wrote the code, since authors rarely rate their own structure harshly.

Cut the scope to the smallest set of features that lets a real user complete a real job, such as raising an order and printing its invoice. Everything else goes on a later list. The finish line kept moving. That is why it stalled.

Write the plan in dated milestones, each with a demo you can click, and name one person on your side who approves every milestone. Agree where the code lives. Decide who may merge into the main branch, who reviews each change before merging, and who can approve an emergency fix on the production server.

Book the production deployment date early, with a rollback plan for the database migration and a named person who can authorise the switch on the day. Print the plan. Pin it where the team works.