A construction calculator on a web page is only worth using if it gives the same answer as the one you would trust on the job. A free rafter calculator that is off by a quarter inch at the ridge is worse than no calculator, because you will not notice until the board is already cut. So when we put the CutOnce calculators on the web, we did not rewrite the math for the browser. The web pages run the same tested code as the app.
The problem with rewriting math twice
The usual way to build a web version of an app feature is to write it again in a new language. The app does its stair math in Swift and Kotlin; the obvious move is to redo it in JavaScript for the site. The trouble is that two implementations drift. Someone fixes a rounding rule in the app, the web copy keeps the old one, and now the same inputs give two answers. For a marketing page that would be a small bug. For a calculator a framer relies on, it breaks the one promise that matters.
We took the other path. Each web calculator is a direct port of the app function, and a build-time check re-runs the app's own test cases against the ported code. If the web result and the app result disagree on any case, the build fails and the page does not ship.
What a test vector is
A test vector is a fixed input paired with a stored expected output, checked automatically on every build. A stair vector says a 108 inch total rise produces 14 risers at a certain height, 13 treads at a certain depth, and a stringer of a certain length. A rafter vector says a given span and pitch produce a given line length, birdsmouth, and set of saw angles. The app is covered by more than 9,000 automated tests, including more than 1,100 shared vectors that run identically on iOS and Android, so both apps are held to the same answers.
That coverage is spread across the calculators: the stair math carries 283 shared vectors, the rafter math 156, the hip and valley math 134, board feet 111. Those are the app's tests. The job on the web side is to make the ported code produce the same answers those tests already pin down.
The gate that keeps them honest
The web port does not get its own separate suite of thousands of tests. Instead, a parity check pins it to the app's answers. It carries a set of vectors copied straight from the app's real test cases, each labeled with the test ID and file it came from, feeds the input to the web function, and compares the output to the app's stored answer within a tight tolerance. The set is representative rather than exhaustive: it covers the worked examples, the boundaries, and the cases most likely to drift, not all 1,100 shared vectors. A mismatch is a failed build, not a warning someone can wave through. The web calculators cannot silently disagree with the app on a checked case, because a disagreement stops the release.
The check runs in the same lifecycle as the rest of the build, next to the type check and the translation parity check. It also keeps the honest scope visible. Some web pages cover a subset of what the app does: the rafter page handles common rafters, while the app handles the irregular hips, valleys, and jacks. The web pages say so rather than pretending to full coverage, and the gate verifies the part they do show.
Why we bother
Most free construction calculators are a formula someone typed into a web form once and never checked against anything. Ours are tied to a shipped app that people pay for and use in the field, and to the test suite that app is held to. The point of the tie is trust: the answer you read on the page for free is the answer you would get from the paid tool on your phone, because it is the same code checked the same way.
You can see the full picture, calculator by calculator with the current vector counts, on the how we verify page. Or just open a calculator and check it against a cut you already know. The rafter length calculator is a good one to test: run a span and pitch you have framed before, and the line length, birdsmouth, and angles should match the board on the ground.