Agree what "done" means before you pay for software

A restaurant owner asks for something like a well-known delivery app, but for his three outlets, simple only. Two lines, sent by message.

What he gets quoted is not what he had in mind, because in his mind it was obvious that the thing talks to the tills, prints to the kitchen, knows which staff member may discount an order, and produces a tax invoice that his accountant will accept. He never said any of it. It was not a secret he was keeping; it was the shape of his own business, and you do not narrate the shape of your own business to someone who is building software for it.

That gap is where the money goes. Not in bad briefs - in the requirements that were too obvious to state.

The trap is called "well, obviously"

Developers who have been through this describe the same pattern from the other side. A project triples in scope because the owner mentions in week six that it needs to handle two currencies. Nobody was careless. It simply was not a feature in his head; it was a fact about his business, like the address.

So the useful question is not "what do you want it to do". You will get an answer that covers the interesting parts and skips the load-bearing ones. The useful question is closer to: what is true about how you work that a stranger would not know?

If you catch yourself thinking well, obviously while reading a question - that is exactly the line to write a full answer on.

What goes wrong, and in what shape

Two things are worth knowing before anyone quotes a statistic at you.

The first is that the failure almost never looks like a failure while it is happening. Incomplete requirements do not stop a project; they let it run. The build proceeds against the brief as written, the developer delivers what was asked, and the gap between what was asked and what was needed appears on the day somebody tries to use it. That is why the cure has to sit before the work starts, and why it is so easy to skip.

The second is the shape of the risk. Most projects drift: a little over on time, a little over on money, a few things quietly dropped. A few detonate, and the difference between the two is usually visible in the brief. A brief that names what the software has to do on the awkward days produces drift; a brief that describes the happy path produces the other thing.

One more line deserves to be pinned above every small business project. The boring requirements, the ones about backups, access, what happens when a record is deleted, are the ones that look like fat when somebody is trying to make a quote smaller. They are also the ones you will pay for twice if they go.

A requirement is only real if it can be checked

The definition of a usable requirement is short: it can be verified. Somebody can look at the finished thing and say yes or no, and both of you would agree on what they were looking at. A requirement that cannot be checked is not an obligation; it is a hope.

The words that make a requirement uncheckable in practice are easy to list, and worth crossing out of any brief on sight: user-friendly, easy, sufficient, adequate, appropriate, maximise, minimise.

Read your own brief with that list in hand. "The system should make invoicing easy" cannot be tested, so it cannot be delivered or refused. "An invoice can be issued in under a minute by someone who has not been trained" can be tested in front of you.

That is the whole trick, and it is why the phrase to write for every feature is a done-when sentence: this is done when [someone specific] can [do something specific] and [something observable happens].

The best example of the form came from a business owner who had never heard the term. Asked how he would know the payroll system worked, he said: make them show you a terminated guy with an outstanding loan balance before you pay a single peso. That is an acceptance test - a named edge case, a demonstration, and a payment tied to it.

The questions that turn two lines into four months

Answer all of these in writing before a price is agreed, including the ones that look obviously irrelevant to your case. Each is cheaper to answer now than to discover in week six.

• Money: does it take payment, how, and who holds the funds on the way through?
• Paperwork: is there an invoice or receipt, and must it satisfy a tax rule or look a particular way?
• Paper: does anything print to a physical printer?
• Hardware you own: till, card reader, scanner, scales?
• Software you already pay for: accounting, email, calendar, stock?
• Tax: VAT, GST, or anything else a government defines?
• People: do several log in, and do they see different things?
• After the fact: can a saved record be edited, and by whom? Can a closed order be changed? Who sees cost prices?
• Phones: which parts must work on one, and for whom?
• Bad connection: what still has to work when the internet is slow or absent?
• Messages: email, texts or notifications, to whom, when, saying what?
• More than one language, currency or time zone?
• Retention: must records be kept for a legal or accounting reason, how long?
• Getting out: can you export your own data, in what format?
• Erasure: what happens when a customer asks you to delete their personal information?
• Failure: what should happen when a payment declines, a printer is offline, a sync does not run?

The last one earns its place. Failure cases are where scope expands most quietly, because everyone imagines the version where things work.

The requirements everyone forgets, with the rules behind them

Four of those questions have real obligations behind them, and they are the ones most often cut as savings.

Deleting personal data reaches further than the database. UK guidance is explicit that the right to erasure extends to backups, and if data cannot be immediately overwritten there it must be put beyond use rather than quietly retained. "We will delete the row" is not the same requirement.

Data export needs a format, and the law gives you the wording. Portability under the GDPR is your customer's right against you, not your right against your developer - but it defines the standard worth borrowing: a structured, commonly used, machine-readable format, not a screen you can print. Write it into the contract in those words, because you will need to satisfy it for your own customers anyway.

Invoice numbering is not a preference. A VAT invoice must carry a unique sequential number in the UK and across the EU, which makes "the invoice number is whatever the system feels like" a defect rather than a design choice for anyone VAT registered.

Retention periods differ by country and by a factor of two or more. The UK expects records kept for around five to six years depending on the entity, the US typically three to seven, Australia five under tax law and seven under some corporate rules. A system that deletes at the wrong time is a compliance problem wearing the mask of a feature.

Access rules belong on this list too - who logs in, who sees what, who can change a saved record. Security guidance treats appropriate access control as a legal obligation, not a nice-to-have, and the practical version of that is the same question I would ask about any automation you commission: whose account does it run on, and what happens when that person leaves.

Acceptance is a contractual event, not a feeling

In the places where this is done properly, acceptance is a defined moment with a document attached.

Government contracting frameworks define acceptance as an act of an authorised representative - for services, approving the specific services rendered, and for goods, assuming ownership. The UK's model services contract runs test success criteria through to a test certificate, which in turn is the gate to the milestone certificate that releases payment. A published municipal software contract template makes the same shape available in plain language: acceptance criteria are agreed in advance, and can only be changed by a written change order.

You do not need a government contract to use the structure. Three sentences in your agreement will do:

1. Payment milestones attach to acceptance, not to elapsed time or to code being written.
2. Acceptance means the done-when sentences pass, demonstrated on your data, on your device, by you.
3. Changes to those sentences happen in writing, with the price consequence stated at the same time.

That third one protects both sides. It is not there to trap the developer; it is there so that "can it also do X" is answered with a number instead of a resentment.

One legal note worth having: for a business buying services in the UK, the implied terms come from business-to-business supply of services legislation rather than consumer law, and US goods-focused commercial code does not map onto a services contract either. If the sums involved matter, that is a question for a lawyer in your jurisdiction, not for a template.

What to do before the money moves

1. Write the day. Describe an ordinary working day in your business, and attach the actual spreadsheet or notebook you use. Assumptions surface there faster than in any specification.
2. Answer every question above in writing, including the ones that seem not to apply. Mark the ones you nearly skipped - those are the expensive ones.
3. Write a done-when sentence for every feature, in the form of a demonstration you could watch. Delete any requirement containing easy, user-friendly, fast or adequate, and replace it with something observable.
4. Tie payment to those sentences, and agree in writing how they change.
5. Ask the developer what they think is obvious. A good one will have a list of their own, and comparing the two lists is the cheapest hour of the project.

A developer with an answer ready to "what happens when this fails" has done this before. One who says you will just use your own login for now is quoting you a price for something with an expiry date they have not mentioned.

If you want the cost side of the same decision, what automation costs a small business walks through where quotes differ and why, and when not to automate covers the projects that should not be commissioned at all.

If you would rather have the requirements written down for you before you go shopping, that is what the process audit is for: $299, three business days, and a written account of what the work actually involves.

Sources

On acceptance as a contractual act: FAR 46.101 and 46.501, the UK model services contract, and San Francisco's published software contract template.

On the obligations behind the forgotten requirements: the ICO on erasure and backups, data portability and data security; HMRC on VAT invoice requirements and how long to keep records; and section 13 of the Supply of Goods and Services Act 1982 for what is implied into a UK business-to-business services contract.