Why the Re-quote Test exists
A demo proves that software runs on the demonstration's inputs. It says nothing about your jobs, your rates or your awkward cases. So wherever arithmetic is involved, our acceptance test is different: twenty of your completed jobs, re-computed by the new system and matched against results you already trust, to a tolerance agreed in writing before the build starts. Here is why — and what happens when a number disagrees.
A demo proves the demo, not your quotations
Most software purchases end the same way: a demonstration, prepared by the vendor, on inputs the vendor chose. It goes well — demonstrations always go well, because the inputs were selected to go well. Then the invoice is paid, the tool meets its first awkward job, and the estimator quietly goes back to the workbook. Nothing in that ritual tested the one thing that matters: whether the tool produces your numbers, on your jobs, under your rules. A demo is evidence that the software runs. It is not evidence that it is right.
Engineering already has the correct instinct here. A weld is accepted by inspection and test, not by looking convincing; a pressure test is a number against a gauge, not an impression. A new calculation method is validated the same way everywhere: run it against cases whose answers are already known, and measure the disagreement. The Re-quote Test applies that standard to estimating software — reproduction of known results, to a stated tolerance, before the balance is payable. If a tool cannot re-derive what you already know to be correct, it has no business computing what you don't.
Twenty completed jobs, chosen by you
The sample is twenty jobs from your own history — already priced, checked or submitted, with outcomes you trust. You choose them, and the awkward ones are welcome: the job that went through three revisions, the one with the non-standard section, the one where the client's drawing was wrong. Twenty is enough to exercise the rate table, the weight arithmetic, the labour build-up and the document output across the real spread of your work. One lucky match proves nothing; twenty results inside tolerance is a pattern.
To see what a known result looks like, take the demonstration staircase on our own site. Given a 3.0 m floor height, the engine solves to 17 risers at 176 mm, a going of 267 mm, PFC 150×75 stringers, 14.4 m of weld and 29 shop hours — RM 7,025 at demonstration rates. Every one of those figures is checkable by hand, and the same inputs return the same figures every time, because every number comes from deterministic code. Your past jobs carry numbers of exactly that kind — and you have already signed them once.
The tolerance goes into the Blueprint, in writing
Before the build starts — at the Workflow Blueprint stage, before any code exists — we agree what "matches" means, output by output. Steel weight to the kilogram, or to half a per cent? The quotation total to the ringgit? Labour to the hour, or the tenth of an hour? These are different questions with different answers, and they are settled per output, on paper, while it still costs nothing to disagree. At acceptance, pass or fail is then arithmetic: all twenty jobs inside the written tolerance, or not.
The conversation is worth having even if you never build. Most estimating workbooks have run for years without anyone stating how accurate their outputs are supposed to be — asking "how close is close enough, per figure?" forces a useful distinction between the numbers that are engineering and the numbers that are habit. It also removes the classic end-of-project argument. Nobody negotiates acceptance in the final week, because acceptance was defined in the first one.
When the tool and the spreadsheet disagree, it is usually the spreadsheet
Discrepancies do occur, and each one is refereed the same way: line by line, with your engineer at the table, until the difference is traced to its cause. There are only three verdicts. The tool is wrong — we fix it, and the twenty-job run repeats from the start. The input was ambiguous — the job file supported two defensible readings, and the Blueprint gains a rule. Or the sheet was wrong all along.
The third verdict is the most common, and it should not be surprising. A workbook maintained by hand for years accumulates quiet damage: a rate updated on one tab and not the other, a SUM range that stopped one row short after a line was inserted, a density typed in once and never questioned again. Nobody re-derives a sheet that seems to work. The re-quote is often the first time its arithmetic has ever been checked against an independent computation — and finding the error there is free, where finding it in a submitted quotation costs margin, or the job.
One signed page: system, sample, tolerance, result
The test closes with a Validation Record — a single page stating the system tested, the twenty-job sample, the agreed tolerance and the result, signed by both sides. Its commercial function is blunt: the balance of the build is payable on pass, and not before. That is the whole of the guarantee, and it is only possible because deterministic code gives the same answer to the same inputs, every time it is asked.
Its quieter function is what it does inside your firm. The Record is an artefact your own QA system can hold: cite it in your quality procedures, show it to a client's auditor who asks how your estimating figures are produced and verified, and use it as the baseline the system is re-checked against at the annual review. It also sets a precedent worth keeping — software joins welds and calibrations in being accepted by test, against a record, to a tolerance in writing. The blank format is below; it is exactly the page we sign.
Start here
Bring the workbook.
If you would like to know what twenty of your own jobs would make of a purpose-built tool, start with the free workflow review — it costs an hour, not a budget, and "don't build this" is an answer we actually give.