The worked example that disagreed with its own calculator

I run a small site of home-improvement cost calculators (costto.build) — pick a project, get a low / average / high estimate with a materials-and-labor breakdown. Boring on the surface. The interesting part is that every page has the same number in four different places, and for a while, those four places didn't agree.

This is a post about that bug, why it was inevitable, and the one rule that made it impossible to repeat.

Four sources of truth for one number

A single calculator page — say, the room-addition one — shows a cost in four spots:

1. The interactive widget, driven by a calculate() function (low/avg/high).
2. A static "cost by size" reference table above the fold.
3. A couple of worked examples written out in prose ("a 20×20 in-law suite runs about…").
4. The FAQ, with its own cost bands.

When I built the first batch, I wrote all four by hand. The widget had its formula. The table had numbers I'd typed from research. The prose examples had numbers I'd reasoned out while writing the paragraph. They were close enough that nothing looked wrong.

Then I ran a consistency pass and found this: the in-law-suite worked example said $62,300. The widget, fed the exact same square footage and finish level, returned $56,779.

Same project. Two pages of the same page. A $5,500 gap.

Why it happened (and why it was always going to)

The numbers weren't random — they came from different assumptions that nobody had written down.

The prose example assumed a brand-new HVAC unit for the addition. The calculate() function assumed you extend the existing system. Both are defensible. But one lived in my head as I wrote a paragraph at 11pm, and the other lived in a TypeScript function I'd written two weeks earlier. Nothing connected them.

This is the ordinary failure mode of derived data: the moment you store the same fact in two spots, they start drifting the instant you look away. It's the DRY principle, except the duplicated thing isn't code — it's a value a function already knows how to produce. I'd just chosen to retype it.

A static table of "costs by size" is, definitionally, a table of calculate() outputs. A worked example is calculate() plus a sentence explaining it. I had been hand-copying a function's return value into prose and calling it content.

The fix: compute the page from the calculator

The rule I landed on — I call it source-first — has two halves.

Half one: calculate() is the only place a cost is born. Everything else is derived from it at build time. The reference table isn't typed; it's generated by calling calculate() across a range of sizes. Same for the example numbers.

// Before: a hand-typed table that rots independently
const costBySize = [
  { sqft: 200, low: 22000, avg: 32000, high: 48000 }, // typed from "research"
  { sqft: 400, low: 40000, avg: 58000, high: 86000 }, // ...probably
];

// After: the table IS the calculator, sampled at build time
const costBySize = [200, 300, 400, 500].map((sqft) => ({
  sqft,
  ...calculate({ sqft, finish: "mid" }), // single source of truth
}));

Static export makes this clean — it all runs once at build, ships as plain HTML, and there's no way for the table to disagree with the widget because they're the same function. (This is Next.js 16 with output: export, so the page is fully rendered text by the time Google or a user sees it. That matters more than it sounds — but that's a different post.)

The worked examples got the same treatment. Instead of writing "$62,300," the example pulls the real figure and the prose explains the assumption around it:

const inLaw = calculate({ sqft: 400, finish: "mid", hvac: "extend" });
// example text references inLaw.avg, and states the "extend existing" assumption out loud

The $62,300 figure didn't get corrected to $56,800. It stopped existing. There was no longer a number to be wrong.

Half two: every born number carries where it came from. A calculate() is only as honest as its anchor, so each calculator now ships a small provenance object that renders on the page:

costBasis: {
  scenario: "Mid-range room addition, national average",
  nationalAvg: 56800,
  source: "Industry cost data, 2026",
  accessed: "2026-06",
  reviewBy: "2026-12",
}

That reviewBy date is the part I'd push on anyone building this kind of site. Cost data isn't a fact, it's a perishable fact. Putting an expiry on it — visible to the reader, and a reminder to me — is the difference between "numbers I sourced once" and "numbers I maintain."

The counterpoint, because there is one

Generating everything from one function has a failure mode: if the anchor is wrong, it's now wrong consistently, across all four spots, very convincingly. Hand-written numbers at least disagree loudly enough to tip you off — which is exactly how I caught this bug in the first place.

So source-first only pays off if you pair it with the provenance half. The single anchor has to be sourced and dated, not vibes. Otherwise you've just made it easier to be uniformly wrong. I'd still take that trade — a contradiction a user can spot destroys trust faster than an error they can't — but it's a trade, not a free win.

There's also real content this approach can't generate: the why. A function can tell you a 400 sq ft addition averages $56,800. It can't tell you the permit will hold you up six weeks or that the HVAC decision is where people overspend. That part stays hand-written. The rule is narrow: stop hand-writing numbers a function already computes — not stop writing.

What I'd take to the next project

• If two places on a page show the same number, one of them should be importing it, not retyping it. This is just DRY, but it's weirdly easy to forget that data is code.
• Build-time generation (static export, or any SSG) turns "keep these in sync" from a discipline problem into an impossibility-of-drift property. Let the build do the copying.
• Any number that can go stale should ship with a visible source and a review date. It costs five lines and it's the most honest thing on the page.

The whole thing was maybe a day of refactoring across the calculators on costto.build, most of it deleting numbers rather than writing them. The codebase got smaller and stopped lying about itself. That's a good day.