DEV Community: Efficienco

Why I Relaunched a 77-Calculator Website Around 4 Production-Ready Tools

Efficienco — Fri, 11 Sep 2026 08:23:10 +0000

A few weeks ago, I could say I had built 77 browser-based calculators.

That sounded productive. It was also becoming a misleading way to measure the project.

The early versions were useful for testing ideas, page structures, formulas, and search demand. But after working across dozens of tools, I started noticing a gap between a calculator that technically works and one I would actually call finished.

So I changed the way I was building Efficienco.

Instead of treating every published calculator as equally complete, I started rebuilding the site around a much smaller set of production-ready tools. At the time of writing, the homepage focuses on four: Bitumen, Concrete Block, Home Addition Cost, and HVAC Duct.

The interesting part was not deleting work or chasing a smaller number.

It was defining what "finished" should mean.

1. Tool count turned out to be a bad quality metric

When I started building calculators at scale, counting pages was useful.

It answered simple questions:

Can the shared layout support very different calculators?
Can the same unit system work across materials, home projects, and building trades?
Which inputs keep repeating?
Which validation problems appear everywhere?
Which topics actually get discovered?

But "77 calculators" gradually stopped telling me anything useful about quality.

A page could have a correct formula and still have several problems:

The default assumptions were hidden.
The result had no useful breakdown.
Unit switching was inconsistent.
Advanced inputs overwhelmed the first screen.
A valid-looking number could be produced from a bad combination of inputs.
The calculator gave no explanation of what the answer included or excluded.

None of those problems are solved by publishing calculator number 78.

At that point, adding more tools was less valuable than making the existing ones easier to trust.

2. Launching broadly was still useful

I do not think the first phase was a mistake.

If I had spent weeks perfecting every calculator before putting anything online, I would have been making a lot of decisions without real feedback.

Publishing a broader first version gave me two kinds of information.

The first was technical.

I learned which problems were shared across calculators: numeric parsing, unit normalization, rounding, saved state, responsive tables, warnings, editable assumptions, and result formatting.

The second was discovery data.

Google Search Console started showing the queries for which different pages were receiving impressions. I could see that some calculators were being tested across several closely related searches, while other pages had almost no signal.

That changed how I decided what to rebuild next.

I stopped asking:

Which calculator do I personally feel like improving?

and started asking:

Where is there already evidence that people are looking for this kind of tool?

That does not mean an impression guarantees future traffic. Search Console data has aggregation, privacy, and reporting limitations, and a query appearing once is not a business case by itself.

But query clusters are useful evidence.

If one unfinished calculator is appearing for several variations of the same problem, that is a stronger reason to invest in it than a tool with no observable demand at all.

3. I needed a definition of "production-ready"

The biggest change was creating a quality bar that did not depend on how impressive the formula looked.

For this project, I now expect a finished calculator to answer several questions.

Can the user start quickly?

The first view should ask for the few inputs needed to solve the common case.

A user should not need to understand the entire model before getting a useful result.

Can an experienced user go deeper?

Real projects usually need more control than a three-field calculator can provide.

That is why I started separating common inputs from advanced assumptions instead of putting every possible control on the screen at once.

Are assumptions visible?

If waste, density, markup, friction rate, local pricing, or another assumption can materially change the result, it should not live invisibly inside a JavaScript file.

The user should be able to see it, understand it, and change it when appropriate.

Does the result explain itself?

A large number at the top of a results card is not enough.

The calculator should expose the important intermediate quantities, selected assumptions, units, warnings, and purchasing or planning logic behind the result.

Can invalid states fail safely?

Empty, zero, negative, out-of-range, and contradictory inputs need different treatment.

A calculator should not produce a polished answer from a state that makes no physical or financial sense.

That quality bar immediately made the difference between "published" and "finished" much clearer.

4. Progressive disclosure solved a surprising amount of UI complexity

One of the recurring problems was deciding how much control to show.

A basic calculator can be pleasantly small:

Length
Width
Depth
Calculate

But real tools rarely stay that simple.

A material estimator may need waste, density, package size, openings, reinforcement, pricing, and unit-system choices.

A cost estimator may need regional adjustments, contingency, taxes, line-item rates, project scope, and low/typical/high scenarios.

Showing everything at once makes the calculator powerful but exhausting.

Hiding everything makes it easy to use but too simplistic.

The pattern I settled on was roughly:

Quick inputs
    ↓
Immediate result
    ↓
Advanced / Customize
    ↓
Assumptions, scope and professional controls

The common case remains fast, while the detailed model is still available.

The Home Addition Cost Calculator pushed this problem the furthest. A home addition cannot honestly be estimated from square footage alone, but asking for every line item before showing anything would make the tool unusable.

The solution was not removing complexity.

It was organizing complexity.

5. A calculator needs a model, not just a formula

My earliest mental model was often:

const result = inputA * inputB;

That works for a unit converter.

It is not enough for most practical estimators.

A more useful structure looks like this:

const config = normalizeInputs(rawInputs);
const validation = validateConfig(config);

if (!validation.ok) {
  return validation;
}

const result = calculate(config);

return {
  inputs: config,
  result,
  assumptions: buildAssumptions(config),
  warnings: buildWarnings(config, result),
  breakdown: buildBreakdown(config, result)
};

The exact implementation differs from tool to tool, but the separation matters.

The calculation engine should not have to know how an input field is styled.

The view should not be responsible for deciding engineering assumptions.

The formatter should not change the value being calculated.

Once those responsibilities are separated, it becomes much easier to test equivalent units, edge cases, presets, and result invariants.

6. Rebuilding one tool exposed requirements for the next one

The useful part of rebuilding calculators is that improvements are rarely isolated.

For example, the Concrete Block Calculator forced me to think more carefully about several concepts:

Multiple wall segments.
Openings that subtract from wall area.
Waste applied at the correct stage.
Blocks versus mortar versus grout/core fill.
Reinforcement as a separate quantity.
Purchasing quantities such as pallets.
Existing walls where the user may only need a fill calculation.

Those are not "concrete block" problems only.

They are examples of a broader problem: one project can contain several related quantities that should not be collapsed into one result.

The HVAC Duct Calculator created a different set of requirements.

Duct sizing involves airflow, dimensions, velocity, friction, material assumptions, and pressure constraints. A tool can easily give a diameter that looks precise while hiding the condition that produced it.

That reinforced the idea that an output should carry its context with it.

Every finished calculator made the shared system slightly more demanding, but also more reusable.

7. Search data now helps decide the rebuild order

Once I had a quality bar, the next problem was prioritization.

There are far more calculators I could improve than I can finish at once.

So I started grouping Search Console queries by intent rather than looking only at the largest single keyword.

For example, a calculator may appear for:

linear feet calculator
linear foot calculator
how to calculate linear feet
fence linear feet calculator
price per linear foot calculator

Those are not five unrelated ideas.

They are evidence of one underlying task with several use cases.

That is much more useful to me than seeing a single impression count in isolation.

It also influences the product itself. If users repeatedly search for a fence-specific variation, that may justify a fence mode inside the calculator instead of a separate near-duplicate page.

The search data is not writing the product specification for me.

It is helping me decide which real problems deserve the next engineering cycle.

8. "Finished" now includes the report, not only the answer

Another change was treating the result area as a report instead of a number.

A useful result can contain:

{
  primaryResult,
  supportingQuantities,
  assumptions,
  warnings,
  includedScope,
  excludedScope,
  unitSystem
}

That structure creates several benefits.

The user can understand why the answer changed.

A copied result contains enough context to make sense later.

A printed report is more useful on a job or during planning.

And when two scenarios are compared, the difference is not just two numbers with no explanation.

The calculation itself may still be only a few equations.

The product is everything around those equations.

9. I stopped treating more features as automatic improvement

A calculator can also become worse by becoming more powerful.

Every additional field creates another decision for the user, another state to validate, another mobile layout problem, and another interaction to test.

I now ask a simpler question before adding an option:

Does this control materially improve the decision the calculator helps someone make?

If the answer is no, it probably does not belong in the main interface.

If it matters only in unusual projects, it may belong under Advanced.

If it changes the mathematical model entirely, it may deserve a separate mode.

This has made the finished tools smaller in some places and much deeper in others.

10. The relaunch is slower, but the work compounds

Building 77 first versions made the site look larger.

Finishing four calculators properly has taught me more about the architecture.

The work now compounds differently.

A better unit system helps every future calculator.

A better validation layer helps every future calculator.

A better report component helps every future calculator.

A better Quick/Advanced pattern helps every future calculator.

A better way to expose assumptions helps every future calculator.

That is the part I missed when page count was the main progress metric.

The biggest lesson

Launching many small tools was useful because it gave me breadth, technical repetition, and real discovery data.

But breadth and completion are not the same thing.

The second phase of Efficienco is much less about asking how many calculators I can publish.

It is about asking whether each calculator deserves to be trusted as a useful piece of software.

For me, that now means visible assumptions, defensible inputs, clear failure states, useful breakdowns, consistent units, and enough context that the result can be understood after the calculation is over.

The number of finished tools grows more slowly this way.

The quality of the system underneath them grows much faster.

References

Google Search Console: Performance report — common tasks and use cases — useful background on analyzing queries, impressions, clicks, and groups of similar searches.
Google Search Console: Performance report dimensions and data groupings — important context on query reporting, anonymized queries, and data truncation.

What Building a Bitumen Calculator Taught Me About Coding the Physical World

Efficienco — Mon, 31 Aug 2026 22:09:05 +0000

Building a calculator for a digital concept—like pixels or file sizes—is straightforward. The rules are absolute. But building a calculator for a physical construction material is an entirely different challenge.

While building the Bitumen Calculator for Efficienco, I quickly realized that the mathematical formula is the easiest part of the project. The difficult part is translating the messy, unpredictable physical world into a clean digital interface.

This article covers the product and UX patterns that emerged when trying to calculate physical materials. It does not cover the JavaScript implementation. The focus is on bridging the gap between theoretical math and a contractor standing on a job site.

1. The real world does not use perfect geometry

In code, calculating volume is incredibly clean: Length × Width × Depth.

In the physical world, you are pouring hot asphalt onto a graded dirt sub-base. The ground is not perfectly flat. It has dips, ruts, and uneven compaction. If a user calculates the exact mathematical volume of their driveway and orders precisely that much material, they will run out before the job is finished.

The software must account for physical reality. The solution wasn't to change the core formula, but to explicitly separate the "perfect math" from the "practical reality." We added an automatic 10% wastage and compaction buffer, displaying both the raw mathematical volume and the realistic order quantity side-by-side[cite: 16].

2. "Constants" are rarely constant

If you look up the density of bitumen, a textbook might give you a single number. But textbooks don't pave roads.

In practice, the density changes based on the specific grade of the material. A standard 60/70 penetration grade has a different density than a Polymer Modified Bitumen (PMB) designed for heavy traffic[cite: 16].

Hardcoding a single density constant makes the code cleaner, but it makes the tool useless for edge cases. I found it necessary to provide a dropdown for material grades, mapping each to its specific real-world density (e.g., 145 lb/ft³ for standard, 148 lb/ft³ for PMB)[cite: 16]. Let the user decide how precise they need to be.

3. Calculate in math, display in commerce

A common mistake when building engineering tools is outputting the result in the same unit the formula uses.

If a user inputs feet and inches, the native volumetric result is cubic feet. But you cannot call a local quarry and order 300 cubic feet of bitumen. They sell it by the ton[cite: 16].

The internal logic must normalize the geometry into a base unit, calculate the mass using the specific material density, and then convert that mass into the exact unit the industry uses for commerce[cite: 16]. The final output must match the unit on the supplier's invoice.

4. Sensible defaults prevent blank-page paralysis

A homeowner using a calculator likely knows the length and width of their driveway. They almost certainly do not know the standard paving depth.

If you leave all inputs blank and wait for the user, you create friction. If you force them to go search for "standard driveway asphalt depth," they will leave your site and find a competitor's tool.

Providing sensible, industry-standard defaults—like a 4-inch depth and a standard 60/70 grade—allows a user to get a highly accurate estimate with only two inputs[cite: 16]. They can adjust the advanced fields if they need to, but they aren't forced to become an expert just to get a baseline number.

5. Assumptions belong on the screen

When your code makes an assumption on behalf of the user, you must tell them.

If the calculator assumes a density of 145 lb/ft³, that number needs to be visible on the screen next to the result[cite: 16]. If the final tonnage includes a buffer, the UI needs to explicitly state "Includes 10% buffer"[cite: 16].

Hiding these assumptions in the source code makes the result look like absolute magic. Showing the assumptions builds trust, because a professional knows that material estimation is an educated guess, not magic.

The biggest lesson

Users don't care how elegant your JavaScript is. They care if your tool prevents them from under-ordering material and delaying a $10,000 paving job.

Dependability in material estimation comes from respecting the physical world: acknowledging waste, surfacing assumptions, aligning with commercial units, and guiding the user with standard defaults.

You can see these concepts applied in practice on the free Bitumen Calculator, where dimensions, material grades, and purchasing quantities are treated as distinct steps in the user journey. The interface manages the messy reality of construction, while the exact implementation stays out of the way.

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.