A few years ago I started tracking what I ate because my doctor told me I needed to lose weight. Nothing dramatic — just eat a little less.
It wasn't. Every app I tried wanted a sign-up or a subscription before showing me a single number. All I wanted to know was: how many calories should I actually eat in a day? That question turned into a small side project, and the project turned into NutriCounter, a free set of health tools I keep building in my spare time.
Start with the math, not the code
Before I wrote anything, I had to understand what a calorie target even is. It comes down to two things: how much energy your body burns at rest, and how much you burn moving around.
The first part is called your BMR (basal metabolic rate), and the common way to estimate it is the Mifflin-St Jeor equation. It takes your weight, height, age, and sex and gives you a number. Then you multiply that by an activity factor — sedentary, lightly active, and so on — and you get your TDEE, total daily energy expenditure. Want to lose weight? Eat a bit less than that number.
That is all a calorie calculator does. The formulas are public, well-studied, and older than the web itself. The hard part was never the math — it was making the result easy to understand for someone who has never heard the words "Mifflin-St Jeor."
Keep the interface boring
I see a lot of health tools that look like video games. For my own tool I went the opposite direction. One form, four or five fields, one big readable result.
Weight, height, age, sex, activity level — that is all I ask for. The result page shows your BMR, your TDEE, and suggested calorie targets for losing, maintaining, or gaining weight. No account, no email, no paywall. If a tool is supposed to help people, the first screen should not be a pricing page.
The whole thing is plain HTML, CSS, and JavaScript. No framework. That was a deliberate choice: it loads fast on cheap phones and works fine on slow connections, which matters.
Units and languages matter more than features
One early lesson: half the world does not use pounds and inches. If your calculator only accepts imperial units, you have quietly told most of the planet to go away. Adding metric support took a couple of hours.
Same story with language. I translated the site into six languages — not with perfect polish, but good enough to be useful. Most health questions people type into search engines are not in English.
What I would do differently
If I started over, I would talk to real users earlier. I spent weeks on the food diary and exercise tracker before I had any idea whether anyone wanted them. Next time I will ship the smallest useful thing first and let feedback decide what gets built next.
I would also worry less about the design. My first version was ugly and people used it anyway.
Why free
This part is simple. I built the tool I wished existed when my doctor gave me that advice. Putting a paywall on it would defeat the purpose. The site runs on cheap hosting and the calculators are just math — there is nothing to charge for. If you want to try it, it is at nutricounter.net, along with the rest of the toolkit.
Sometimes the most useful thing you can build is the simplest one.
Top comments (1)
Letting guests use the calculators right away, with no signup wall, is the right call for health tools.
Speaking as a Staff SDET, I ran nutricounter.net through an automated scan and the report card came back 97/100 (A). The top flag is form fields missing labels: on /tools/meal-log the Food name, Quantity (g), kcal and P/C/F inputs rely on placeholders only, so screen readers announce them as unlabeled fields and the hint disappears as soon as someone starts typing. An
aria-labelon each input (or a visually hidden<label>) is a quick fix. The scan logged 6 more findings, and it only covered part of a ~124-page site.