How BuildMetric calculators are made

Start with a decision, not a formula

We begin by defining the question a contractor needs to answer. “What does this employee cost per productive hour?” is useful. “What is labor burden?” is only a topic. That distinction controls the inputs, outputs, explanations, and limitations of a calculator.

We then model the smallest complete version of the decision. Optional detail is added only when it materially changes the result. This helps keep a tool usable on a phone at a jobsite without hiding important assumptions.

Formula and implementation review

Every core formula is expressed in plain language and implemented as a pure TypeScript function. We verify it with hand-worked examples, unit tests, boundary cases, and reciprocal checks where applicable. For example, a markup-to-margin conversion should return to the original value when converted back.

Monetary values are calculated at full JavaScript precision and rounded for display. Percent inputs are converted to decimals before arithmetic. Unless a tool states otherwise, values are annualized and results are estimates rather than forecasts.

Sources and assumptions

We prioritize government and first-party institutional sources for definitions and requirements. Tax rates, insurance costs, benefit structures, and productive hours vary by year, jurisdiction, classification, and company. We therefore ask users for their own known rates instead of presenting a national default as fact.

A source supports the method; it does not make a user-provided assumption correct. Each calculator identifies inputs that should come from payroll reports, insurance documents, financial statements, or a qualified adviser.

Maintenance

• Automated tests run on every proposed code change
• Source links and legal references are reviewed when underlying rules change
• Material methodology changes receive a new reviewed date
• Feedback is evaluated against reproducible calculations, not anecdotes alone