Stalled software project: what to check before the next payment

A nearly ready demo proves little. A screen can look finished while every button does nothing, so ask to use the system yourself, entering your own test order while the developer only watches in silence.

Press every button. Log in as two different roles, such as an admin and a store clerk, and compare what each can see on the order screen and the reports. Refresh the page and see whether your entry survives, then type a wrong value on purpose and read the validation message that comes back.

Vanishing data means a mock up. That is not a crime. It does change what your instalments bought, and it changes what the next one should buy, so say so before the next invoice arrives.

Ask where the code is kept. A repository on GitHub or GitLab inside your company’s account is the safe answer, while a zip file on the developer’s laptop is not. Insist on owner access. Guest access is no protection.

Ask about the database, the domain registration, the cloud server account and the app store developer account, since each should name you as owner or co-owner. Request a recent database dump. Keep a copy offline.

Check the keys as well, meaning the payment gateway, the SMS provider, the map service and the email sender, because those accounts belong to your business. Nobody else should hold them.

List every feature in the contract and write beside each one of four words: working, partly working, mock up or not started. Judge by using the feature yourself, never by the developer’s own description of how far it has got, which tends to run ahead of the screen.

Look at what runs on a server, then ask for the staging or live address and open it from your own phone. If it only runs on the developer’s machine, deployment has not begun, and the launch date you were quoted means little until a server exists.

Ask who else has read the code. If one person holds all the code and has gone quiet, you carry a risk that no payment schedule covers, whatever the contract says about delivery dates. Check the commit history. A long gap tells its own story.

Continue means paying to finish. Cost the remaining features and the delay, then ask for a dated plan in which each payment is tied to a deliverable you can demonstrate on a test server.

Moving the work means a new team reviews the code, then completes it or rebuilds the weakest parts, starting with a technical review of the repository. That review tells you how much of the existing code, schema and API is reusable and how much must be redone, before you commit more money.

Stop means accepting the loss and restarting from your requirement document, perhaps by a different route altogether, such as a packaged product configured to your workflow. Put figures in every column. Count your own staff hours and the months already lost, since both belong in the cost of continuing, moving or stopping alike.

Pause payments in writing. State that the next instalment will be released against a working milestone, shown to you on a test server, with a named date for the demonstration. Keep the tone calm. Keep the message short.

Ask for the code, database dump and credentials in the same message, because a developer acting in good faith will agree within a day or two. Delay or refusal tells you something about the real state of the work, and that is worth knowing before the next transfer is made.

Then book an independent technical review. A few days of a senior engineer reading the repository, the schema and the deployment settings will settle the choice between continue, move and stop. Share the feature list first.