How a tool earns its place.

We treat a technical utility as a compact piece of reference software: the result matters, but so do the assumptions, evidence, and failure modes.

Method last reviewed:

1. Begin with a real operational task

A proposed tool must answer a specific question more clearly or safely than a generic calculator. We define its audience, inputs, output, edge cases, and stop conditions before interface work begins.

2. Separate evidence from judgement

FactDirectly supported by a dated primary source or repeatable test.
EstimateA quantified projection with its inputs and uncertainty visible.
HypothesisAn idea to test, never presented as observed demand or performance.

3. Prefer local, deterministic computation

Calculators that do not need a server run in the browser. Raw tool inputs and results are excluded from analytics. Any future network inspection feature requires a reviewed destination-control design before it can launch.

4. Review before publishing

Launch gates cover calculation correctness, source quality, keyboard and screen-reader use, responsive layout, privacy behavior, security headers, indexing, and human inspection of the built pages. Owner approval is a separate final gate.

5. Maintain or retire

Every live utility carries a review date and changelog. Material source or platform changes trigger a fresh review. A stale or misleading tool should be corrected, clearly limited, or removed—not left to accumulate traffic.