Our Methodology

Why methodology matters

A calculator is only as good as its formula and its implementation. This page documents exactly how Calculate All calculators are designed, built, and tested — so you don't have to take our accuracy on faith.

1. Spec-driven design

Every calculator begins as a written specification, not code. The spec defines:

• The formula with its authoritative source (textbook, standard, or official documentation).
• Every input: label, unit, type, valid range, and default.
• Every output: label and display format (currency, percentage, integer).
• Worked examples with hand-computed expected answers, including edge cases: zeros, negative values, very large and very small numbers.
• FAQs addressing the most common misunderstandings of the topic.

2. Formula verification

Before implementation, each formula is cross-checked against at least one independent authoritative reference. Where competing conventions exist (for example, flat-rate vs. reducing-balance interest), the page states which convention it uses and why. The formula itself is displayed on every calculator page under "How it's calculated" — if we can't show the math, we don't ship the tool.

3. The 242-assertion automated test suite

All calculator logic lives in versioned formula modules (data/formulas-*.js) that are exercised by an automated test suite — tools/test.js — which currently runs 242 assertions across every tool on the site. The suite checks:

• Known-answer tests: each formula is evaluated against hand-verified expected values.
• Edge cases: zero, negative, and extreme inputs behave sanely instead of producing NaN or Infinity.
• Round-trip consistency: inverse conversions (e.g., kg → lb → kg) return to the starting value within rounding tolerance.
• Spec integrity: every calculator has a valid formula mapping, sane SEO metadata lengths, and complete FAQ entries.

A calculator page is only generated when the full suite passes — the build fails otherwise, so a broken formula can never reach the site silently.

4. Precision and rounding

Calculations use JavaScript double-precision arithmetic. Display rounding is deliberate and documented per output: currency to two decimals, percentages to two decimals, counts to integers. Intermediate values are never rounded before the final display, so chained math stays accurate. Where floating-point representation could confuse (e.g., 0.1 + 0.2), outputs are formatted to hide representation artifacts.

5. Human review and dating

Automated tests catch implementation errors; humans catch conceptual ones. Every page is reviewed by a person for formula choice, unit correctness, example clarity, and FAQ accuracy before publication. Each page shows a published date and an updated date, plus a byline naming the author and the editorial reviewer.

6. Ongoing verification

• The test suite runs on every build — any spec or formula change is re-verified automatically.
• Calculators are re-reviewed at least annually (quarterly for money and health tools).
• Reader-reported errors are investigated and, when confirmed, fixed with a public updated date.

Limitations

No methodology is perfect. Tests verify implementation against specs, not the spec against reality — a wrong formula choice would pass every test, which is why human sourcing and review come first. And calculators are simplifications: real-world outcomes include factors no formula captures. See our Disclaimer.