How these tools are built

The arithmetic is separate from the page

Each calculator is two things. The maths lives in a plain module with no user interface in it at all — loan amortization, calendar differences, overtime splits, unit factors — and the page is a separate file that collects the inputs and shows the result. Nothing about a number depends on the layout around it.

That split exists so the arithmetic can be tested directly, against worked examples, rather than by clicking through a form and reading what appears. It is also why a redesign cannot change an answer: the two halves are edited independently, and only one of them computes anything.

What gets tested, and against what

Every tool has tests, and they are written against the source the tool implements rather than against the tool’s own output — a test that only asserts a calculator agrees with itself proves nothing except that it is consistent. Where a published worked example exists for a formula, that example is the test.

• Boundaries, not just the middle. A shift that crosses midnight, a leap day, a loan paid off exactly on the final instalment, a zero, a negative, an empty field. Almost every calculator that gets a detail wrong gets it wrong at an edge.
• The whole suite runs twice, in two time zones. Once in UTC and once in a zone twelve hours the other side of it, whose daylight saving runs against the northern hemisphere’s. Three shipped date bugs were invisible to a UTC-only run and were found exactly there.
• Simple and Advanced cannot disagree. A tool with a mode switch runs the same calculation in both; Simple holds the advanced inputs at their documented defaults rather than using a different method. Each such tool has a test pinning precisely that, so the two modes can never return different answers to the same question.
• Every fix gets a named regression test. A bug that is fixed without one is a bug that is scheduled to come back, and the test is named after the thing that went wrong rather than after the function it touches.

None of that makes a tool correct. It makes a tool that used to be correct stay correct, which is a different and more achievable promise, and it is the one being made here.

Where the numbers come from

Where a tool applies a rule somebody else published — a classification threshold, an equation, a standard size — its own page names that source and links to it, so you can read the rule rather than take this site’s word for the number. A tool that cannot say where its figures come from has no business handing you one.

There is a harder rule behind that one, and it is the reason some obvious tools are missing:

Nothing here invents reference data. Anything that would need an authoritative table that changes — tax brackets, benefit rates, statutory holidays, postal codes — is either an input you supply, or the tool is not published. A calculator carrying a table nobody is maintaining is wrong on a date nobody notices, and it is wrong in the direction of looking authoritative.

The same reasoning keeps whole categories off the site. There are no plumbing, gas, electrical, structural or medical-dosage tools here, and there will not be: those are calculations where being confidently wrong injures somebody, and they belong with the people who are accountable for them.

What a result is allowed to claim

Every tool states the assumptions it ran under, beside the answer rather than in a footnote — which convention, which rounding, which threshold, and what it did not account for. Where a result is an estimate produced from a population-level formula, it says so in those words, and it says what the estimate is not.

That matters most on the tools people arrive at while deciding something. A body-composition estimate is not a diagnosis. A payment schedule is not a lending decision, and the lender’s figure is the one that governs. A retirement projection assumes a constant return that no investment delivers. Each of those sentences is on the tool that needs it, not collected on a disclaimer page nobody opens, and the terms of use set out where the line sits in general.

Several tools also show their working — the intermediate values, in order, so you can find the step you disagree with. That is there for checking the answer, and it is the fastest way to send a useful bug report.

What runs where

Every one of the 175 tools, across 12 categories, calculates in your own browser. There is no application server, so there is nothing you type for us to receive — which is a design decision rather than a policy, and it is why the privacy policy has so little to describe.

The exception is named rather than hedged: the Product Ingredient Checker sends the barcode you type to Open Food Facts to look the product up, only when you press Look up. A tool that needs data this site has no business holding asks the organisation that publishes it, and says so before you press the button rather than afterwards.

Every page is also built to a plain HTML file before anyone visits it, so the headings, labels, units and written explanation are in the document itself rather than assembled afterwards by a script. That is mostly why the pages are quick; it also means a tool keeps working after the network goes away.

When a tool is wrong

Some of them will be. A calculator that is confidently wrong is worse than no calculator, so a demonstrated wrong answer goes ahead of everything else, including whatever was being built that week.

The useful report is a reproducible one: the contact form asks for the tool, the exact inputs including units and options, the number it returned, the number you expected, and where your figure came from — a lender’s statement, a payslip, a published table. Where a tool shows its working, pasting those lines in is usually enough on its own.

When something is corrected, the fix is a change to the arithmetic module and a test named for the case that was wrong, so the same mistake cannot return quietly. Where a correction changes what a tool assumes rather than fixing a slip, the assumption printed beside the result changes with it.

Review dates, and why most pages do not carry one

Some tool pages say when their written explanation was last reviewed. Most do not, and that is deliberate: a date is only useful if somebody genuinely read the page on it. Stamping every page with the date of the last deployment would be a freshness signal rather than a fact, and it would be worth less than the blank it replaced.

So a date appears where a review happened and nowhere else. The absence of one means the page has not been re-read recently — not that it is wrong, and not that it is fresh.

Who wrote this

One person, who builds software for a living and is not a doctor, a financial adviser, a lawyer or an accountant. That is stated plainly because the alternative — implying a review board that does not exist — would be the least trustworthy thing on the site.

What is offered instead is checkable: the source each tool is written against is named on the tool’s own page, the assumptions are printed beside the result, the working is shown where it can be, and a wrong answer you can demonstrate gets fixed. The about page covers the rest.