Tools Methodology

A calculator that shows a number tells you nothing about whether the number applies to you. Motifuse publishes 105 public tools across 11 categories, plus three premium products. This page describes the process behind all of them, so you can judge how much weight a given result deserves.

Tools are built to finish a specific task, not to fill a category. A candidate has to survive four questions before it is built:

Requests from visitors feed this directly. If you have a task no tool covers, describe it — the input, the expected output, and who would use it are the useful parts.

Where a tool computes something, the method comes from a documented source rather than from memory or from another website’s implementation.

• Finance tools use standard percentage, amortisation, compound-interest, GST, discount, and projection mathematics, with the convention used stated on the page.
• Health tools use published population formulas — BMI categories, established BMR equations, activity multipliers for TDEE, common gestational-age conventions — and name the formula rather than presenting a number from nowhere.
• Unit converters use fixed, exact conversion factors, with a precision control wherever rounding could change a decision.
• Developer tools use native parsers and established libraries in preference to string manipulation, because a hand-rolled parser is a subtle-bug generator.
• File and image tools use browser file, canvas, and codec APIs, so behaviour matches what the browser itself would do.
• Where a rule varies by jurisdiction — tax slabs, date conventions, statutory thresholds — the tool states which version it implements.

When two credible sources disagree, we implement the more widely used one and say so on the page, rather than presenting the choice as settled.

The default is your device. A tool reaches a server only when the task genuinely cannot be done locally — and when it does, the interface says so before you act.

The full boundary, including which providers receive what, is in the Privacy Policy and on Security.

Most wrong answers come from accepting an input the tool should have questioned. Validation is part of the method, not a usability nicety:

• Numeric fields reject non-numeric input rather than coercing it to zero — the classic way a calculator confidently returns nonsense.
• Identifier-shaped values such as account references and anything with leading zeros are preserved as text by default. Converting them to numbers must be an explicit, previewed choice.
• Dates are parsed against a stated format. Ambiguous dates are flagged rather than guessed.
• Ranges are bounded where a value outside them cannot be meaningful, and the tool explains the bound instead of silently clamping.
• File inputs are checked for type and size before processing, and say plainly when they exceed what the browser or the plan allows.
• Server routes validate every request body against an explicit schema before a handler runs.

The cases a tool handles badly are the ones worth designing for. Recurring ones we test against:

• Empty input, whitespace-only input, and a single character.
• Zero, negative numbers, and very large numbers where floating point starts to lose precision.
• Unicode: accented characters, right-to-left text, emoji, zero-width and invisible characters, and mixed encodings.
• Files that are empty, truncated, mislabelled by extension, or far larger than expected.
• Datasets that are wide as well as long — the combination is what exhausts browser memory, not either alone.
• Rows that are valid individually but conflict as a set, such as duplicate output filenames in a document batch.
• Timezone and daylight-saving boundaries in date tools.

Pure logic — calculation, parsing, validation, formatting, matching — is kept separate from the interface so it can be tested directly. The repository carries an automated test suite over that logic which runs on every change, alongside linting and type checking.

• Unit tests cover calculation and transformation logic, including the edge cases listed above.
• Integration tests exercise API routes end to end, including the failure paths — an error response is part of the contract.
• Tools are exercised manually against representative real inputs before release, and in more than one browser.
• A bug that reaches users gets a regression test as part of the fix, so the same failure cannot ship twice.

Every tool page is expected to say what the tool assumes, where the result should not be relied on, and what to check instead. That is not legal cover — it is the difference between a tool that helps and one that misleads.

• Educational estimators say so, and name the profession to check with for a consequential decision.
• Tools with a jurisdictional dependency name the jurisdiction they implement.
• Tools whose accuracy depends on input quality — text extraction, OCR, fuzzy matching — report confidence and mark uncertain results rather than presenting them as fact.
• We publish no accuracy percentages. A figure measured on our own test data would say nothing useful about yours.
• Where a capability is planned rather than shipped, it is labelled as planned everywhere it appears.

Both are build constraints rather than later passes. Tools use semantic controls with real labels, keyboard-operable interactions, visible focus, and error messages that name the field and the problem. Results that update without a page load are announced to assistive technology. Current gaps, and how to report one, are on the Accessibility page.

On privacy, the design rule is that a tool should not need your data to leave the device unless the task demands it. That is why so much of the platform runs in the browser, and why every exception is labelled.