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.
Top comments (0)