How we build and test these calculators

This page describes how a calculator on this site is specified, built, tested and documented. It is written to be checkable: if a tool ever behaves differently from what is described here, that is a bug and we want to hear about it.

#1. Specification

Every calculator starts from a question a person actually asks, not from a keyword. We write the question down, decide the smallest set of inputs that can answer it honestly, and identify what the answer is most sensitive to. Inputs that barely move the result are removed -- a form with twenty fields is not more accurate, it is just harder to fill in.

We then decide what the tool will refuse to assume. Anything that varies by location or changes over time -- an electricity rate, a fuel price, a mortgage rate, a savings yield -- becomes an input the reader supplies, never a value we bake in. This is the single most important design rule on the site.

#2. Choosing the formula

Where a standard published formula exists, we use it and name it: the amortization formula for loan payments, the future value of an annuity for savings, Mifflin-St Jeor for basal metabolic rate, Riegel's formula for race-time prediction, the 235.215 constant for converting miles per gallon to liters per 100 kilometers.

Where several conventions compete -- how to count months between two dates, whether to tip on the pre-tax or post-tax total, which waste factor to apply to flooring -- we pick the most common one, say so on the page, and explain how the alternatives differ.

Where no standard formula exists, we build the simplest model that captures the mechanism, and we say explicitly that it is a model.

#3. Implementation

All calculators are implemented in plain JavaScript that runs in your browser. There is no server-side computation, no external API and no library dependency, which means there is nothing between the formula on the page and the number on your screen.

We avoid cleverness in the arithmetic. Loops that simulate month by month are preferred over closed-form shortcuts wherever the closed form would hide an assumption, because a visible loop is easier to verify and easier to explain.

#4. Numerical testing

Before publication, every calculator is tested against an independent implementation of the same formula written in a different language, at multiple input values chosen to include the awkward cases: zero, very large and very small inputs, a zero interest rate, a payment below the monthly interest charge, a shift that crosses midnight, a leap-year date, a February 29 birthday, unit systems switched mid-calculation.

Outputs must agree to the cent, or to the displayed precision, at every tested point. Where they do not, the discrepancy is resolved before the page goes live.

#5. Documentation

The explanation on the page is written against the implementation, not from memory. Every worked example is recomputed and must reproduce the calculator's own output. If the text and the tool would disagree, the page does not ship.

Each page also carries an explicit statement of what the model excludes. We would rather lose a reader to an honest limitation than keep one with a false number.

#6. Review and updates

Calculators are reviewed when the underlying rule changes -- a new tax year, a revised contribution limit, an amended overtime regulation -- and on a rolling schedule otherwise. The "last updated" date on each page reflects the most recent review.

Because our tools take rates as inputs rather than assumptions, they do not silently decay the way calculators with hard-coded prices do. The exceptions are the pages that necessarily contain statutory figures, principally the take-home pay calculator, and those are reviewed each tax year.

#7. Use of AI tools

We use software tools, including AI-assisted drafting and research tools, in the production process. No page is published on the basis of AI output alone. Every formula, worked example and numerical claim is verified against an independent computation by a human reviewer before publication, and the team is responsible for everything on the site. Where a claim could not be verified, it is removed rather than softened.

#8. What we will not build

We do not build calculators that require a license we do not hold, that produce a number people would reasonably treat as a diagnosis or a professional recommendation, or that depend on a data feed we cannot verify. That rules out medical risk scores, structural engineering calculations, legal deadline calculators and anything that prices a specific financial product.