The software works. You have seen it work.
Someone sat down with you, opened it, clicked through the things you had asked for, and the things you had asked for happened. The invoice for the balance is in your inbox. Everybody behaved as though the job was finished, and on the evidence you were shown, it was.
This is the moment worth slowing down over — and not because anyone has done anything wrong. Most of the people who build software for small businesses are honest and reasonably good at it. The difficulty here is more structural than that, and it survives everyone involved being perfectly decent.
The demonstration you were shown was built to answer one question: does it work? Releasing the final payment asks a different one: am I willing to be responsible for this? The evidence that answers the first question does surprisingly little to answer the second.
It is fashionable to attach all of this to AI, and there is something in that — more software is being built more quickly, and by more people, than used to be possible. But nothing in this article depends on it. The gap between it works and I can be responsible for it was there long before, and it would still be there if every one of the new tools disappeared tomorrow.
“does it work?”
“I can be responsible for it”
Before the final payment, you have someone’s attention. Questions get answered because there is a live reason to answer them.
After the final payment, you have their goodwill. Goodwill is a real thing and it is often generous — but it is not a schedule and it is not an obligation. Anything you might need that requires somebody to sit down for two days is very much easier to arrange while an invoice is still open.
That is the entire argument for asking now rather than later. It is not suspicion. It is sequencing.
A demonstration shows you one person, using the software the way it was meant to be used, on a day when nothing else is happening. That is worth something. It is not worth what most people take it for.
Here are five things a working demonstration is simply not capable of telling you. None of them asks you to understand code.
Who actually holds the keys.
The app store listing, the domain name, the hosting, the login to the payment provider – each of these lives inside somebody’s account, and that somebody is not automatically you. Where a mobile app is involved, Apple’s own documentation describes a transfer between developer accounts that keeps the app’s reviews, ratings and existing users intact, so this is usually recoverable rather than lost. The catch is in who has to act: the transfer must be started by the party currently holding the app, and the app has to meet Apple’s criteria for transfer. Your recourse, in other words, runs through the continued cooperation of somebody you have just stopped paying.
Whether messages from your payment provider are checked.
When a customer pays, the payment company sends your software a message saying so, and your software acts on it – marks the order paid, unlocks the account, releases the goods. Stripe’s documentation is direct about what happens when those messages are not verified: someone could send your software a fake one and trigger exactly those actions, which is why it tells developers to always confirm that a message genuinely came from Stripe before acting on it. Whether that confirmation happens inside your software is a yes-or-no question. Watching a real payment succeed will not answer it, because a real payment succeeds either way.
Whether the price is decided by your server or by your customer’s browser.
When someone buys something, the amount to be charged has to be worked out somewhere. If it is worked out in the customer’s browser and your server simply accepts the figure it is handed, then that figure can be edited on the way through. This is one of the oldest recognised weaknesses in web applications, and the textbook example of it is precisely this case: a hidden price field, quietly changed. A demonstration purchase at the correct price tells you nothing here, because the person demonstrating had no reason to alter it.
Whether anybody else can build it.
Being handed a copy of the source code is not the same as being able to do anything with it. The test is unglamorous and completely decisive: put the code on a machine that nobody involved in writing it has ever touched, and see whether somebody can get it running. If that has never once been tried, then nobody knows the answer – and that includes the people who wrote it.
Whether it holds up with more than one person.
A demonstration is one person clicking slowly and waiting politely for each screen to load. A business is not. Whether the software still behaves itself when two customers do the same thing in the same second – book the last appointment, buy the last item in stock – is a different question from whether it works, and two people with two phones can answer it in an afternoon.
None of these is exotic. They are ordinary engineering questions, the sort a competent builder will have views about and may well have handled already. The point is not that your software fails them; it may pass every one. The point is that not a single one of them is answered by watching the interface work – and watching the interface work is, in most handovers, the entire body of evidence on offer.
The trap in a conversation like this is asking questions you cannot evaluate the answers to. “Is it secure?” invites a confident yes, and you are no better off than before, because you had no way to judge the answer and both of you know it.
Ask instead for things that either exist or do not. A written list of every outside service the software depends on. The name on each account. A record of what was tested. An answer to whether the code has ever been built by anyone else.
You do not have to assess these things. You only have to notice whether they exist. A prepared builder should be able to produce many of them quickly; if they do not exist, that is useful information in itself, because it is evidence of the work they did. A blank look is not proof that anything is wrong – but it does tell you that the answers are not written down anywhere, and that whatever is in somebody’s head leaves when they do.
And if the answer to some of it is we never checked that, this is a far better week to find out than the week after the money has gone.
“we never checked that”
You should know the interest behind the argument. I sell software review services. That is what I do for a living, and it is the reason I have opinions about this. So read the above as coming from someone with a stake in you taking it seriously. The five items are checkable against the documentation of the companies named, and against your own software, without involving me at all – which is the test I would apply to anybody making this case, including me.
These come from a longer set still being worked on, so treat them as candidates rather than a finished checklist.