How We Build QuickUse Calculator

Every dollar, real, peso, percentage, and basis point on the site is computed using arbitrary-precision decimal math via the decimal.js library. We never use JavaScript floats for money. Floating-point arithmetic accumulates error in ways that are imperceptible in toy examples and catastrophic at scale — round-trip a $1,000 monthly contribution over 30 years of compound interest and you get a final balance that drifts by hundreds of dollars depending on the order of operations.

This is not a theoretical concern. The Patriot missile clock-drift bug, the Vancouver Stock Exchange index bug, and a long tail of payroll-system overpayments all trace back to misuse of binary floating-point in financial domains. We refuse to inherit that class of bug.

Every tax table, contribution limit, FHA cap, deduction threshold, and statutory rate on the site lives in a TypeScript file with a header that names the official source URL, the date the value was last verified, and the date of the next scheduled review. There is no "magic number" lying around in calculator code. If a number governs the result, it is in a versioned table with a footnote.

When you see "$23,500 — 2026 401(k) elective deferral limit" on a US retirement calculator, the underlying source comment names IRS Notice 2025-67, links it, and gives the verification date. The same applies to Brazilian INSS thresholds, IRPF brackets, FGTS multas, and every other input that comes from a government table.

Tax tables change every year. Contribution limits adjust for inflation. State minimum wages move on a different cadence than federal. We treat regulatory data as live infrastructure: every regulatory file on the site has a "next review" date, and the build system will surface stale files when their review window closes.

For each annual update, we re-fetch the official source via web search rather than trusting model-baked memory or last year's value, because table values do change in non-obvious ways and language models trained on a knowledge cutoff will quietly hallucinate them. The git history records the diff: which value changed, when, and against what source.

Universal calculators (compound interest, BMI, mortgage math) ship in both English and Brazilian Portuguese. Country-specific calculators (IRPF for Brazil, 401(k) for the US) live only in the locale where they apply, with the slug naturally untranslated. There is no automated machine translation step. Every Portuguese page is human-edited so that idioms, regional terms (rescisão, MEI, salário-mínimo), and currency formatting work correctly. Same for English: a Brazilian writing about US payroll uses the right terms (FICA, FUTA, W-2) instead of literal translation.

A calculator widget alone is not a useful page. Every calculator on the site ships with a written explanation of how the math works, at least one worked example, two to three practical scenarios with numbers, a "when not to use this calculator" section, an FAQ of five to eight common questions, and a list of cited sources. The editorial floor is roughly 1500 words of original prose per calculator. Below that, we treat the page as a draft, not a reference.

This is not gratuitous word count. Each section answers a real reader question, written from the perspective of someone who has actually thought about when the formula breaks. Worked examples include numbers a real person would recognize — a $300,000 mortgage, not $1,000,000.

Every calculator and post on the site has a named author and a named reviewer, both linkable to a profile page that lists their bio, expertise, and credentials. Editorial team handles (QuickUse Editorial — Brasil, QuickUse Editorial — US) are disclosed openly as team bylines, not presented as fictional individuals. We do not use AI-generated headshots that could be mistaken for real people.

When a reviewer is credentialed (a registered Brazilian contador, a CPA, a CFP), the credential is shown next to the byline. When the slot is reserved for a future credentialed contributor, that is also disclosed. Honesty about authorship is the foundation of E-E-A-T (Experience, Expertise, Authoritativeness, Trust), and we treat it as non-negotiable.

You are reading it. This page is the contract between the site and its readers. If we do something different from what is written here, the page is wrong and we want to update it.

Before any code is written, the contributor reads the underlying law, regulation, or canonical reference. For a Brazilian labor calculator that means reading the CLT articles and any subsequent jurisprudence that materially changes the calculation. For a US tax calculator that means reading the relevant IRS Publication and any state DOL bulletin. For a health calculator that means reading the original peer-reviewed paper for the formula (Mifflin-St Jeor for BMR, Harris-Benedict variants, etc.) — not a secondhand explainer.

The math is implemented as a pure function in TypeScript with all currency and percentage values typed as decimal.js Decimal instances. No console.log, no side effects, no DOM access in the compute. This makes the function testable and reusable.

Every compute function has a test file with at least three cases: a textbook scenario with a known answer, an edge case (zero principal, maximum contribution, retirement at the youngest legal age), and a comparison against the calculator that the issuing regulator publishes. For Brazilian fiscal calculators, that often means testing against the Receita Federal's own simulador. For US retirement, against an IRS worksheet example. The test suite has to pass before any UI work begins.

The author writes the prose around the calculator: introduction, formula explanation, worked example, practical scenarios, when-not-to-use, FAQ, sources. The draft is written for a reader who has just searched the topic and has roughly a high-school math background. No jargon without immediate plain-English unpacking.

For universal calculators, a human editor translates the editorial content into the second locale, adapting idioms and units rather than translating literally. Currency examples switch — a US worked example uses $300,000; the Brazilian version uses R$ 1,2 milhão for an equivalent comparison.

A named reviewer with relevant expertise (or the editorial team handle pending a credentialed contributor) reviews the math, the worked examples, the source citations, and the disclaimer language. The reviewer signs off explicitly. Their name and the date of review appear in the "Reviewed by" badge under the calculator title.

Editorial drafts written with research tooling are run through a humanizer pass to remove AI-text markers — predictable paragraph structure, stock vocabulary ("delve", "robust", "comprehensive"), thesis-support-conclusion templates, lists with exactly three perfectly parallel items. Drafts that survive the humanizer pass with the dataistic content intact (numbers, citations, dates) become the published version.

Every page targets Lighthouse 95+ in Performance, Accessibility, Best Practices, and SEO. Every input has an explicit label. Every interactive element is keyboard-navigable. Color contrast meets WCAG AA. The result region uses aria-live so screen readers announce changes when the calculator updates.

The page deploys via Vercel. We monitor for runtime errors via Sentry and for traffic anomalies via the host's analytics. If a deployment introduces a regression, we roll back; we do not patch forward at the cost of leaving incorrect numbers live for hours.

When the IRS announces 2027 contribution limits, we add a 2027 entry to the relevant table file — we do not overwrite the 2026 entry. Historical calculations remain auditable. A user running a "what-if" with last year's limits gets the right number for last year. A new query gets the current year by default.

Each regulatory file has a header comment declaring the official source URL, the date the values were last verified against that source, and the date of the next scheduled review. Files past their next-review date are flagged in CI. This is the bare-minimum process required to avoid the most common failure mode of finance sites: stale numbers that look authoritative.

When a contributor (human or LLM-assisted) updates a regulatory value, the workflow requires fetching the official source via web search rather than relying on training data or last year's file. Language models will confidently produce wrong values for next year's 401(k) limit, the current Selic rate, or a state's 2026 minimum wage, because those values change after the model's training cutoff. The verification step catches this before merge.

When a regulatory value changes between years, the git commit names the source URL and the diff. This is the audit trail. We have considered surfacing a public-facing changelog on the site for material changes; for now the git history is the canonical record.

In 2026 we shipped a US payroll calculator with a New Jersey Family Leave Insurance rate of 0.432%. The owner spotted that the published 2026 rate had dropped to 0.23% — the original value was correct for an earlier year, not the current one. We hot-fixed the rate within 24 hours, added it to the regression test suite, and tightened the verification step in the file header so the same class of bug surfaces on the next annual review. We document this here because process maturity is built by remembering the failures, not just the successes.