I built a quoting tool, then spent two audits proving it was wrong

A supplier sends a price list. A customer asks for eleven things. Someone types the prices into a quote and hopes the arithmetic is right. It is a small job that a lot of small businesses do badly, and it is the sort of thing worth automating carefully rather than cleverly.

So I built the tool. Then I tried to break it, twice. This is what that found, because how someone behaves when their own work is wrong tells you more than a feature list does.

What it does

quotekit reads a supplier price list and a list of requested items, prices every line it can, and flags every line it cannot — an unknown code, a missing price, a quantity that is not a whole number of packs, a product name that matches two items, a code that appears twice in the price list. It writes a draft marked DRAFT — NOT APPROVED, DO NOT SEND, plus a checklist restating every priced line for a person to check.

There is no language model anywhere in the pricing path. Every amount is integer-cent arithmetic in plain code. No API key, no account, no network access at all. A quote that is wrong by one cent is still wrong, and a tool that guesses a product code will eventually guess wrong on a real job.

It also cannot send anything. Producing the approved document is the last thing it does.

How it is tested

Its own test suite is eight files, which is table stakes. The part that matters is the second implementation.

I wrote the quoting rules twice. The second version shares no code with the first: it parses money by splitting the decimal string into BigInt where the first uses a regex into Number, and it rounds by doubling the remainder where the first adds an integer numerator. Then I fuzzed them against each other over 30,007 randomly generated request lines, including the boundary where an amount becomes too large to hold exactly. Zero disagreements.

A test suite that cannot fail is worse than none, so I checked that this one can: flipping half-up rounding to half-down produces 66 disagreements, making part-packs round up produces 999, and swapping two clarification reason codes produces 141. The check is real.

The bug that matters

The tool watermarks its drafts and requires a person to type a confirmation phrase before it produces a sendable quote. It hashes the draft so an edited draft cannot be approved. I wrote that, tested it, documented it in four places, and it was wrong.

The sendable document was never the draft. It was re-rendered from a JSON record that nothing authenticated. So I edited one amount in that record, left the draft file untouched, and approval passed cleanly — producing a signed, sendable quote reading $0.01 where the reviewed draft said $30.00.

The gate was hashing the wrong artefact. It passed every test I had written for it, because I had written tests for the thing I believed it did.

The fix re-renders the draft from the record and requires the reviewed hash back, so an edit to any amount, name or term is caught. A second audit then found the same class of mistake one layer up: the approval block stored hashes of what was reviewed, and nothing ever read them — so regenerating the record, the draft and the document together at new prices passed every check. That is fixed too, and a quote-verify command now exists because integrity hashes that nothing reads are the same as not having them.

Also found and fixed in those audits: a pipe character in a supplier's product name silently deleted the line total from the customer's quote, a repeated line id let the omit flag drop a line that was priced and billed, and re-drafting an approved quote left a stale still-sendable document in the send folder while printing that it had done the opposite.

What it does not do

No PDFs or scans. No tax, freight or currency conversion. No tiered or customer-specific pricing. No fuzzy matching — a near-miss name produces candidates for a person to choose from, never a choice. And no measured time saving, because nobody has sat down with a stopwatch and done the job by hand, so there is no baseline to compare against and I will not claim one.

What this is meant to tell you

Two things. A check that is never read, and a guard that is never tested against the thing it guards, both pass indefinitely — so I go looking for that pattern specifically. And when my own work turns out to be wrong, the finding gets written down at the top of the page rather than quietly patched.

The code, the tests, the audit record and every claim above are in the repository, including the failures.

Who built this

Salior. I build small, carefully tested tools.

The method behind this package is written up in how I build: a quoting tool, two adversarial audits, and the approval gate that turned out to be checking the wrong file.

If you have a small job that needs doing carefully, write to Salior.RealityLab@proton.me.