A Whanganui joinery workshop¹ paid the final invoice for its new quoting and cutting-list system on the day of the demo. The demo looked great. Three weeks later, the owner found that cutting lists for curved benchtops came out with the wrong dimensions, and one mis-cut panel had already cost NZ$480 in material. The developer fixed it, but slowly, because the job was paid and other clients were waiting.
Paying on demo day was the mistake. The software was sound; the owner had simply never decided what "finished" meant, so the developer's definition won. This article sets out how to define it, a payment schedule that keeps both sides focused on it, and the tests to run before you sign off.
What the slow fix cost
While the curved-benchtop bug was open, the office manager checked every curved job's cutting list by hand. Over three weeks:
Checking: 6 hours a week × NZ$55 × 3 weeks = NZ$990 Wasted panel: NZ$480 Total: NZ$1,470
The build cost NZ$7,200. The cost of the bug came to about 20% of the build price, in three weeks.
Write down what "done" means before work starts
A done list is a short set of tests, in plain words, that the system has to pass with your own data. Write it with the brief, agree it with the developer, and attach it to the contract.
For the joinery, a done list would have looked like this:
| # | Test | Passes when |
|---|---|---|
| 1 | Quote a standard kitchen from the price list | Total matches the spreadsheet to the dollar |
| 2 | Quote a kitchen with a curved benchtop | Cutting list dimensions match the workshop's manual calculation |
| 3 | Change a material after quoting | Quote and cutting list both update |
| 4 | Add GST and a discount | Totals match the accounts |
| 5 | Convert a quote to a job | Job card shows every line from the quote |
| 6 | Print a cutting list for the saw | Fits on the saw's sheet format, readable at arm's length |
| 7 | Send the quote to a client | Client receives it and can open it on a mobile |
| 8 | Two people edit different quotes at once | Neither loses work |
| 9 | Export the month's jobs | File opens in a spreadsheet with all fields |
| 10 | Log in as each user type | Each sees only what they should |
Test 2 would have caught the bug. It's the kind of odd case that never appears in a demo, because demos use simple examples.
Ask each person who'll use the system for their three strangest jobs from the last year, and turn them into tests.
A payment schedule built around the done list
A common pattern for fixed-price builds is a deposit, a payment at a midway point, and the rest on delivery. Adding a holdback changes the incentive at the end:
| Stage | Share | On a NZ$7,200 build |
|---|---|---|
| Deposit, on signing | 30% | NZ$2,160 |
| Midway, when the first working version is shown | 40% | NZ$2,880 |
| Delivery, when the done list passes | 20% | NZ$1,440 |
| Holdback, 30 days after go-live with no open defects | 10% | NZ$720 |
| Total | 100% | NZ$7,200 |
The holdback is small enough that a reasonable developer will accept it, and large enough to keep your fixes near the top of their list. On these numbers, NZ$720 is about half of what the joinery's three-week bug cost.
Explain it up front. Most good developers are comfortable with a holdback tied to clear tests, because it protects them too: once the list passes and the 30 days are up, the money is due, with no arguments about whether the job's finished.
Run the tests with real work
Two rules make acceptance testing useful:
- Use your own data. Real price lists, real customers, real awkward jobs. A demo with sample data proves the screens work, and little more.
- Run it alongside the old way for a week or two. The joinery could have quoted every job in both the spreadsheet and the new system for two weeks and compared totals. Any gap is either a bug or a rule nobody wrote down.
Keep a simple log during that period:
Date / What I did / What I expected / What happened / Screenshot
Send the log to the developer daily or every couple of days. A clear log gets bugs fixed faster than a summary from memory a week later.
When a test fails at delivery
Some tests will fail on the first try. That's normal, and it shouldn't turn into a standoff. Agree in advance how failures are handled:
- Sort each failure as critical or minor. Critical means you can't run the business on it: wrong totals, wrong dimensions, lost data. Minor means it's awkward but workable, such as a label in the wrong place.
- Critical failures hold the delivery payment. The developer fixes them, you rerun the test, and the 20% is paid when they pass.
- Minor failures get a fix date. Write them down with an agreed date, pay the delivery stage, and let the holdback cover them.
- Rerun the whole list once, not only the failed tests. A fix in one place can break another.
At the joinery, this would have taken about a day: half a day for the curved-benchtop fix and half a day to rerun all ten tests. A day's delay at delivery is a far smaller cost than three weeks of hand-checking.
Defects versus changes
The holdback only works if both sides agree on the difference between a defect and a change.
- A defect means the system fails a test on the done list, or does something the brief clearly asked for in the wrong way. Fixing it is part of the price.
- A change is something new, or different from the brief. It gets priced separately.
During testing, the joinery's owner realised she wanted quotes to show a photo of the timber. That's a change, and a good one, but holding back money over it would be unfair. Put changes on a separate list and price them once the done list passes.
When to pay in full straight away
A holdback makes less sense when:
- The build is small, say one workflow on a fixed price, and the risk of a costly defect is low.
- You've worked with the developer before and they've always fixed problems promptly.
- The contract has a defects period with response times, for example "critical bugs fixed within two working days", which gives you similar protection.
- The developer is a sole trader who can't carry 10% for a month without strain. Ask, and agree a shorter holdback period instead.
Before you sign off
- Write a done list of eight to twelve tests with pass conditions
- Include each user's three strangest jobs
- Agree a payment schedule with a 10% holdback for 30 days
- Test with real data, alongside the old way, for one to two weeks
- Log every problem with what you expected and what happened
- Separate defects from changes
- Pay the holdback promptly once the list passes and 30 days are clean
When Thogits builds a system for you, you get a written scope and a quote before any work starts. Bring your done list to that first conversation, and your strangest jobs become part of the scope from day one.
¹ The Whanganui workshop, its build price and its bug are illustrative. Prices include GST. Staff time has no GST added.