What Building 77 Browser-Based Calculators Taught Me About Input Validation

Efficienco — Sun, 30 Aug 2026 05:45:41 +0000

Building one calculator is straightforward. Building dozens of calculators with different units, assumptions, ranges, and failure modes is where input handling becomes the real product.

While building 77 free browser-based calculators for Efficienco, I found that the formula was rarely the part that caused the most trouble. The difficult part was deciding what every input actually meant and what should happen when someone entered something unexpected.

This article covers the validation patterns that became useful across the project. It does not cover the calculation formulas themselves. The focus is everything that must happen before and after a formula runs.

1. Empty, zero, and invalid are different states

A common mistake is treating every falsy value as missing:

if (!value) {
  showError('Enter a value');
}

This rejects 0, even when zero is a valid input. It also fails to explain whether the user left the field empty or entered something the calculator could not parse.

I started handling those states separately:

function readFiniteNumber(input) {
  const raw = input.value.trim();

  if (raw === '') {
    return { ok: false, reason: 'empty' };
  }

  const value = Number(raw);

  if (!Number.isFinite(value)) {
    return { ok: false, reason: 'invalid' };
  }

  return { ok: true, value };
}

The calculator can then give a useful response instead of one generic error for everything.

2. Validate the domain, not only the data type

12 is a valid number, but it may still be invalid for a particular field.

A percentage may need to stay between 0 and 100. A wall length cannot be negative. A pipe diameter of zero makes no physical sense. A financial time period may need to be a whole number.

Type validation answers:

Is this a number?

Domain validation answers:

Is this number meaningful here?

I found it useful to keep those checks explicit:

function requireRange(value, { min, max, label }) {
  if (value < min || value > max) {
    return `${label} must be between ${min} and ${max}.`;
  }

  return null;
}

The ranges should reflect the field's meaning rather than being copied across every calculator.

3. Normalize units at the boundary

When a calculator supports feet, metres, inches, millimetres, gallons, litres, kilograms, and pounds, it becomes tempting to perform conversions throughout the formula.

That quickly becomes difficult to audit.

The cleaner pattern was:

Read the user's value.
Convert it into one internal base unit.
Run the calculation using only base units.
Convert the final result into the requested display unit.

This creates a clear boundary between input formatting and the underlying calculation. It also makes unit-switching tests much easier: equivalent measurements should produce equivalent results.

4. Never round intermediate values

Rounding early can create surprisingly large differences when several stages are involved.

For example, a material estimate might calculate an area, apply a coverage factor, add waste, and finally round up to purchasable units. Rounding after every stage compounds the error.

The safer rule is:

Keep full precision internally and round only for display or purchasing requirements.

Display rounding and operational rounding are also different. Showing 12.47 to a user is a formatting choice. Rounding a purchase requirement up to 13 packages is part of the result's meaning.

5. Assumptions belong beside the input

Many calculators cannot produce a useful result without assumptions. Material waste, labour rates, compaction, occupancy, efficiency, and safety factors are examples.

Hiding those assumptions inside the JavaScript makes the result look more precise than it really is.

I found three things helped:

Provide a sensible default.
Let the user change it when practical.
Explain what the default represents beside the field.

The goal is not to show every implementation detail. It is to ensure users understand which inputs materially affect the answer.

6. Error messages should explain the repair

“Invalid input” describes the software's problem, not the user's next action.

More useful messages are specific:

“Wall length must be greater than zero.”
“Waste percentage must be between 0% and 100%.”
“Enter a valid pipe diameter.”
“The minimum value cannot exceed the maximum value.”

The best validation messages tell users exactly what to change without making them understand the implementation.

7. Test relationships, not just individual values

Some inputs are valid on their own but invalid in combination.

Examples include:

A minimum value greater than the maximum.
A start date later than the end date.
A wall opening larger than the wall.
A down payment greater than the purchase price.
A result unit that does not match the selected measurement system.

These relational checks are easy to miss when every field is tested independently.

The biggest lesson

Users judge a calculator by whether the answer feels dependable, not by how elegant its formula looks in the source code.

That dependability comes from correctly handling messy input, explaining assumptions, preserving precision, and producing useful errors.

One practical example is the Concrete Block Calculator, where dimensions, openings, spacing assumptions, waste, and purchasing quantities all need clearly separated treatment. The public tool demonstrates the experience, while the implementation remains private.

How to Calculate Bitumen Quantity for Roads and Driveways (With Formula)

Efficienco — Thu, 27 Aug 2026 09:31:45 +0000

Getting bitumen quantity wrong on a paving job is expensive in both directions — order too little and you're waiting on a second delivery mid-pour, order too much and you're eating the cost of unused material. Here's the actual math contractors and estimators use, so you can sanity-check any calculator (including automated ones) before you commit to an order.

*The core formula
*
Bitumen requirement for a road or driveway surface comes down to three inputs:

Bitumen quantity (kg) = Area (m²) × Bitumen rate (kg/m²) × Number of coats
Area — length × width of the surface you're covering, in square meters.
Bitumen rate — the application rate, typically expressed in kg per m². This varies by surface type and coat purpose (tack coat, prime coat, or wearing course all have different standard rates).
Coats — most jobs use a prime coat plus a tack coat, and sometimes a separate seal coat — each with its own rate, so don't assume "one number fits all layers."
Typical application rates

As a rough reference (always confirm against your local spec or the binder manufacturer's datasheet, since rates vary by climate and surface type):

Prime coat: ~0.6–1.0 kg/m²
Tack coat: ~0.2–0.5 kg/m²
Surface dressing / wearing course: ~1.0–2.5 kg/m², depending on aggregate size

*A worked example
*
Say you're prime-coating a 500 m² driveway at 0.8 kg/m²:

500 m² × 0.8 kg/m² × 1 coat = 400 kg of bitumen

Add a tack coat at 0.3 kg/m² on the same area and you need another 150 kg — 550 kg total before you account for wastage.

*Don't forget wastage
*
Add 5–10% on top of the calculated figure for spillage, uneven application, and edge overruns. Estimators who skip this step are usually the ones making the emergency second order.

*Why I built a calculator for this anyway
*
The formula above is simple, but juggling multiple coats, unit conversions, and wastage percentages by hand on-site is where errors creep in. I built a free Bitumen Calculator that takes area, rate, and coat count and gives you the total instantly — useful for a quick double-check even if you're running your own spreadsheet for the official estimate.

DEV Community: Efficienco