Questions to ask before signing a software contract
A short list for non-technical buyers. Most disputes trace back to something that was never agreed in writing at the start.
6 min read
If you are commissioning software without a technical person on your side, the contract is your main protection. The questions below are the ones whose absence causes the most expensive arguments later. None of them require technical knowledge to ask, and a supplier who cannot answer them plainly is telling you something.
Who owns the code when this ends?
Ownership should be stated explicitly and should transfer to you. Ask where the code lives during development, and confirm that you have access to that repository from the first week rather than at handover. If the source only reaches you at the end of the project, you are dependent on the relationship staying good.
What happens if we stop working together?
Ask what you would receive on the day the contract ends: the code, the infrastructure configuration, the credentials, the documentation. A supplier confident in their work will be comfortable making this concrete. Exit terms are easiest to negotiate at the beginning, when nobody expects to need them.
Who tests it, and against what?
"We test our own work" is the answer most likely to cost you later. Ask whether testing is done by someone other than the person who wrote the feature, whether there is an automated test suite you will inherit, and what specifically has to be true before something is called finished. Vague definitions of done are where timelines quietly expand.
What is not included?
Proposals describe what will be built. The costly gaps are usually in what was assumed away: data migration from your current system, staff training, support after launch, third-party licence fees, and hosting costs. Ask for these to be named, even where the answer is that they are excluded. An explicit exclusion is a planning input; a silent one is a surprise invoice.
How will I know whether it is going well?
You should see working software early and regularly, not a status percentage. Ask how often you will be shown something running, and in what form you will receive progress updates. A project that shows you nothing for three months is not necessarily failing, but you will have no way of telling.
Every question here is easier to ask before signing than after something has gone wrong. None of them are unreasonable, and a good supplier will have answered them before.
On price
The lowest quote is often the one that has understood the problem least. That is not an argument for paying more; it is an argument for comparing what each quote actually covers before comparing their totals. Where two proposals differ sharply in price, the difference is usually scope, testing, or support, and it is worth finding out which.