A few months ago, I built a small tool for one person: my father.
He likes playing Lotofácil, a popular Brazilian lottery, and used to spend a lot of time doing combinations and calculations manually on paper.
One day I sat with him, tried to understand what he was doing and asked myself a very simple question:
Why is this still being done by hand?
So I started coding.
What was supposed to be a small personal tool eventually became the starting point of a much bigger project.
The first version was very simple
My original goal was not to create a startup or a large platform.
I just wanted to make my father's life easier.
I created two tools:
Lotofácil Closing Calculator
https://valorfinal.com.br/calculadora-fechamento-lotofacil
Lotofácil Combination Calculator
https://valorfinal.com.br/calculadora-desdobramento-lotofacil
Instead of writing combinations on paper, he could now open the browser, enter the numbers and test different scenarios.
He started using the tools constantly.
That was the first signal that there was something interesting there.
Then I started seeing the same pattern everywhere
Once I finished those calculators, I started noticing how many small problems people still solve manually.
People use:
- spreadsheets
- calculators
- formulas copied from websites
- notes on paper
- random online tools
- long articles just to find one number
That gave me an idea.
What if I built a platform focused on simple tools that solve these small problems directly?
That is how ValorFinal started growing.
My rule became: utility first
One of the principles I adopted early was:
the tool should be more important than the article around it.
If someone searches for a calculation, I don't want to give them only a long explanation.
I want to give them the answer.
So instead of building pages around content only, I try to build pages around functionality.
The explanation exists to help the user understand the result.
But the calculator or tool is the main product.
This changed the way I think about SEO too.
Instead of asking:
"What article should I write?"
I started asking:
"What problem can I solve?"
The stack is simple on purpose
ValorFinal is built with Next.js.
A large part of the platform can run directly in the browser.
For many calculators, there is no real reason to send data to a backend.
If the calculation can be executed safely on the client side, that's usually what I prefer.
This keeps things:
- fast
- simple
- inexpensive
- easier to maintain
I try to avoid adding infrastructure just because I can.
No database if I don't need one.
No API if a local function solves the problem.
No extra service if the browser can do the job.
This sounds obvious, but it is very easy for side projects to become overengineered.
The difficult part is not always the code
One thing this project taught me is that understanding the problem is often harder than implementing it.
Before building a calculator, I need to understand:
- what the user is actually trying to calculate
- which inputs are really necessary
- what can confuse the user
- which edge cases exist
- how the result should be explained
- whether the result can be misunderstood
The Lotofácil tools were a perfect example.
Writing the code only became possible after I understood what my father was doing manually.
That lesson stayed with me:
problem understanding comes before implementation.
The project started getting traffic
At first, almost nobody visited the site.
I kept publishing tools and improving existing pages.
Then Google started indexing more of them.
Slowly, users started arriving.
First a few.
Then more.
Eventually, the project started receiving hundreds of users per day.
That was probably the most surprising part.
A project that started because my father was doing calculations on paper was suddenly being used by people I had never met.
Real usage changed my priorities
Another lesson came from watching what people actually use.
Sometimes I build something I think will be important and it gets very little traffic.
Then I build a simple calculator and it performs much better than expected.
That changed how I prioritize development.
I now try to follow a much simpler loop:
Build → publish → measure → improve
Instead of trying to predict everything in advance, I let usage help decide what deserves more attention.
Small problems can be great products
Developers often feel that a project needs to be technically impressive to be valuable.
I'm starting to believe the opposite.
Many useful products are simple.
They solve repetitive problems.
They save a few minutes.
They remove uncertainty.
They replace a spreadsheet.
They replace a manual calculation.
They replace a piece of paper.
That may not sound exciting from a technical perspective.
But if people keep using it, it solves a real problem.
And that's what matters.
What ValorFinal is today
Today, ValorFinal has tools covering different areas, including:
- personal finance
- employment calculations
- lotteries
- technology utilities
- engineering
- other everyday calculations
The topics are different, but the idea behind them is always the same:
make something complicated feel simple.
There is still a lot I want to improve, and the project is still young.
But I like where it is going.
And the funny part is that my father is still using the original Lotofácil tools.
He also keeps finding things to test.
So, without realizing it, he became the first user, the first tester and probably the person responsible for the entire project existing.
If you want to take a look:
ValorFinal
https://valorfinal.com.br/
If you're also building small tools, calculators or utility projects, I'd be interested to know what you've learned from real users.
Top comments (0)