1
0 Comments

We built 3,800+ calculators by taking small problems seriously

In 2011, Omni Calculator didn't exist. There was one percentage calculator.

Mateusz Mucha built it while learning JavaScript. It wasn't meant to become a company, and percentage calculations hardly looked like a startup opportunity. What bothered him was that most online calculators worked in one direction: enter the values the tool asked for, press a button, get an answer. His version let people fill in different fields and calculate the missing value immediately.

It was a small improvement to a small tool.

People used it.

That experiment eventually became Omni Calculator. Today, we have more than 3,800 calculators covering everything from mortgages and statistics to concrete, calories, physics, and problems most of us wouldn't think about until the moment we need to solve one.

Looking back, one lesson stands out: something can look too narrow to build and still be genuinely useful.

Small problems can have real demand

Startup advice usually pushes founders toward big problems. Find a large market. Solve a painful need. Build something customers can't live without.

That logic makes sense when one product has to support an entire company. But it can also make useful ideas look trivial.

Take converting a salary into an hourly wage. Nobody describes that as a major technology problem. Yet someone comparing job offers may suddenly want to know what a $70,000 salary works out to per hour. At that moment, the problem is real.

The same thing happens when someone needs to know how much concrete to order, what grade they need on a final exam, or how much a price increased.

These are often short-lived needs. The user may want an answer in two minutes and never need the tool again. That doesn't make the problem imaginary.

We gradually stopped asking whether a calculation sounded important enough to build and started asking whether there was a specific situation in which someone genuinely needed the answer.

One tiny problem may never justify a company. Thousands of them can become a product strategy.

The formula is rarely the whole product

It is easy to think a calculator is just a formula with an interface attached.

In practice, the formula is often the easy part.

Consider margin. One person knows cost and selling price. Another knows revenue and profit. Someone else wants to work backwards from a target margin to the selling price they need.

The math is closely related. The situations are not.

That taught us something useful: the equation is not necessarily the product. The user's situation is.

A good calculator has to understand what information someone is likely to have, what they are trying to find, which units make sense, and which assumptions could change the result.

This is why a general-purpose tool does not always replace a specific one. More flexibility can mean more work for the user. Someone calculating roof slope may be better served by two obvious fields --- rise and run --- than by a more powerful interface that first requires them to figure out how to use it.

Search became a source of product ideas

A surprising number of calculator ideas start with the language people use when they search.

People are often very literal when there is a calculation between them and a decision. They search for things such as how much house they can afford, how many tiles they need, or what score they need to pass.

Those queries expose problems that would be easy to miss in an internal brainstorming session.

This is one reason search data can be useful as product research. Google Trends, for example, lets you distinguish between exact search terms and broader topics, making it possible to examine the specific wording people use rather than only broad categories.

Search volume is not a product strategy by itself. A popular query may already be served perfectly well. A smaller query may represent a more useful professional need. Judgment still matters.

But search has one advantage over brainstorming: it shows what people are already trying to do.

Scale changes the problem

When Omni had a handful of calculators, building another one was mostly a creation problem.

At more than 3,800, the harder questions are different. Is the calculation correct? Are the assumptions clear? Has a regulation, medical guideline, or source changed? Does this calculator deserve to exist separately, or are we creating a slightly different version of something we already have?

Scale makes quality expensive.

That matters because a calculator can look finished long before it is trustworthy. The page can load, accept inputs, and produce a number while still being wrong in ways that are hard for the user to spot.

When people use a tool to make decisions about money, health, construction, education, or work, producing a number is a very low bar.

The original idea still holds

Omni now serves millions of users each month. The scale is completely different from the JavaScript project Mateusz built in 2011, but the basic idea hasn't changed much.

Someone has a question involving numbers. They shouldn't need to become an expert in the underlying math before getting a useful answer.

There is a broader lesson in that for people building software.

Products don't have to begin with grand problems. Sometimes the opportunity is hidden in a task that sounds boring, takes thirty seconds to explain, and matters intensely to one person for about five minutes.

The first Omni calculator solved percentages.

If we had judged the idea by how large that problem sounded, there probably wouldn't have been a second one.

on September 13, 2026