We build and sell small document products. This week we shipped product #26 in a 30-product pipeline: a Pressure Washing Business Starter Kit — a pricing calculator plus operations docs for aspiring owner-operators. Eighteen plain files: 12 Markdown docs, 4 CSVs, a LICENSE, and a Python script. It sells at a $1 intro price.
That's the product news. The build-in-public part is how much verification effort we spend on something that costs a dollar.
The quotes must recompute exactly from the CSVs
The kit's core is a rate card, and it ships seven worked quotes — real jobs with real arithmetic. If a number in a worked example doesn't match what the rate card produces, the product is wrong, and a customer overcharges or underbids a job.
So every number in the kit must recompute exactly from the shipped CSVs. We ship self_qos.py, a stdlib-only Python verifier, inside the product itself. It reads the CSVs and re-derives all seven worked quotes from scratch. Nothing is correct just because a human typed it.
Rounding is where pricing silently rots
Two of the seven quotes land on exact half-cent ties. 13.125 has to round half-up to 13.13, and 445.625 has to round half-up to 445.63. Python's default round() is banker's rounding — it gives 13.12 and 445.62. Different numbers, same "obviously correct" look. A customer copying those quotes a cent low, repeated across a rate card, is a real pricing bug that no eyeball review catches.
Those two ties are frozen in the kit as exact expected values, and the verifier checks them to the half-cent.
The engine is nine lines, and order is the bug factory
The pricing engine is deliberately tiny. What matters is the locked order:
total = base_rate
total *= SOIL_MULT[soil] # 1. heavy soil multiplies the base FIRST
if after_hours: # 2. after-hours sits on the service line
total += service_line_fee
total += gallons * 0.05 # 3. water: $0.05/gal pass-through, NEVER marked up
if miles > 20: # 4. travel added dead last, beyond 20 free miles
total += (miles - 20) * MILE_RATE
total = round_half_up(total) # 5. explicit half-up rounding, one place
Order changes the total. Multiply the base after adding travel and you get a different number than multiplying first. Water is a pass-through, so multiplying it along with the base inflates every quote that includes a pool or a long hose run. Each of these is one plausible refactor away from being wrong — which is exactly why the machine re-derives everything instead of us squinting at a diff.
The gate: 80/80, plus a mutation drill
Our verification gate runs 80 checks and all 80 pass. Two details worth stealing:
- Zero frozen figures in the gate. It runs as a separate process and parses its expected values out of the 70KB build plan at runtime. We grep-audited it: no hard-coded totals. The gate can't quietly agree with the product because a human copy-pasted the same wrong number into both files.
- Mutation drill. We planted three one-cent errors — one in a quote total, one in a startup-cost row, one in a rate-card base price. All three were caught by name. Each produced a check failure naming the exact row that moved.
If a one-cent planted bug survives your test suite, your gate is decoration. Cheap re-derivation plus mutation testing catches real pricing bugs before customers do, and it costs an afternoon.
Honest limits
- The prices in the kit are example figures. Verify them locally before quoting anyone — the verifier ships in the kit precisely so you can.
- No income claims anywhere. We don't know what you'll earn.
- Personal-use license: no resale of the files.
- Licensing, insurance, and runoff rules differ by city and state. Check yours.
Where to get it
Full disclosure: we built this kit and we sell it. $1 during the intro window:
https://nandminc.gumroad.com/l/pressure-washing-kit
If you want to see what a mutation-tested pricing gate looks like on a document product, that's the dollar.
Top comments (0)