A few Cronometer feature requests I would genuinely pay Gold for
I'm new to Cronometer, and the more I use it, the more I appreciate how powerful it is. That said, I keep running into a few situations where I think Cronometer could become even better, especially for people who care about accuracy beyond just “did I eat roughly 2,000 kcal today?” (Found it really great at supplement stacking)
So here are three feature requests for my biggest pain points, that I would honestly consider Gold-worthy.
1. “Find a better replacement” for scanned foods
One thing that happens quite often:
You are in a store. You find a food, drink, or ingredient. You scan the barcode. Cronometer finds it. Great. (If not, it's super easy to add it as a Custom Food)
But then you add the entry, and it only contains the basic nutrition label values:
Energy, kcal, protein, carbs, fat, salt, sugar, maybe saturated fat if we are lucky.
Basically, the usual “this is technically food” label data.
What I would love is a feature that lets you find a nutritionally similar replacement from a richer sources like NCCDB or USDA.
For example, when selecting a food from their diary, user can have Cronometer compare the added product against database foods and suggest close matches based on things like:
- Calories/Energy
- Protein
- Carbohydrates
- Fat
- Sugar
- Salt/sodium
- Fiber, if available
Then the user could choose one of two options:
- Use the better database item instead
- Enrich the scanned food entry using the better database match
The second option would be especially useful. The barcode item would still represent the actual product I bought, but Cronometer could fill in missing micronutrients and other details using the best available equivalent.
Obviously, it should be clear that the enriched data is estimated, not lab-tested for that exact product. But in many cases, an informed estimate from NCCDB or USDA would be far better than having no data at all.
This would be incredibly useful for generic foods and ingredients like oats, rice, milk, flour, chicken, yogurt, canned tomatoes, protein drinks, and so on.
Right now, I often manually search for a better database item anyway, so having Cronometer assist with this would save time and probably improve data quality.
2. Fitness tracker calorie calibration
Many of us use fitness trackers to estimate energy expenditure, but trackers can be wildly inconsistent. Some overestimate calories burned, some underestimate, and some seem to be powered by optimism and magic numbers.
There are also studies suggesting that many consumer trackers are not very accurate when estimating energy expenditure. One article I found mentions that common trackers may only be around 56.63% accurate for this purpose:
https://wellnesspulse.com/research/accuracy-of-fitness-trackers/
So my feature request is this:
I would love for Cronometer to “learn” how inaccurate a user’s tracker is by comparing:
- Logged calorie intake
- Reported calorie expenditure from the tracker
- Actual weight change over time
In other words, Cronometer could offer a tracker calibration period.
For example, over 1 or 2 weeks, the user would need to:
- Log their weight daily
- Weigh themselves at roughly the same time each day, for example within plus/minus 30 minutes
- Log food intake as accurately as possible
- Keep tracker data connected and active
Cronometer could then compare the expected weight change based on logged intake and reported expenditure against the actual weight trend.
If the tracker says I should have lost 1 kg, but my actual trend suggests I lost 0.5 kg, Cronometer could estimate that the tracker is overreporting expenditure. If the opposite happens, it could estimate that the tracker is underreporting.
After the calibration period, Cronometer could offer something like:
>"Based on your logged intake, weight trend, and tracker data, your tracker appears to overestimate activity calories by approximately 18%. Would you like Cronometer to apply this adjustment going forward?"
The user could then choose to:
- Accept the calibration
- Reject it
After accepting or rejecting, the user can then:
- Continue calibrating for more accuracy
- Abort the calibration
If the user chooses to accept the calibration, the user can then:
- Apply the calibration only going forward
- Optionally backfill the calibration historically for a selected date range
To avoid bad data, Cronometer could abort or pause the calibration if the user skips weight logging or has incomplete calorie logging. That way, it does not try to build a correction factor from messy data.
The longer the user continues the calibration, the better the estimate should become. A minimum period could be 1 or 2 weeks, but Cronometer could continue refining the calibration over time if the user wants. Of course, Cronometer should warn the user that the better and more accurately they log their calories, the better the calibration will be; as the saying goes, "shit in; shit out".
This would make tracker integrations much more useful. Instead of just importing possibly inaccurate calorie burn numbers, Cronometer could interpret them based on the user’s real-world results.
3. Custom columns, serving-size-aware food search, and food comparison
When logging food, I would love more control over the search results table.
Right now, when searching for foods, it can be difficult to compare items quickly. I often want to know things like:
- kcal per 100 g
- protein per 100 g
- carbs per 100 g
- fat per 100 g
- category
- fiber
- sodium
- selected micronutrients
It would be great if users could customize which columns appear in food search results.
Even better, Cronometer could let the user enter a serving size directly in the search view.
For example:
Search: “Greek yogurt”
Serving size: 400 g
Then the search results could show each item’s nutrition for that entered amount:
| Food | kcal for 400 g | Protein | Carbs | Fat | Source |
|---|---|---|---|---|---|
| Greek yogurt A | 240 | 40 g | 16 g | 0 g | NCCDB |
| Greek yogurt B | 380 | 32 g | 22 g | 18 g | CRDB |
| Greek yogurt C | 300 | 36 g | 20 g | 8 g | USDA |
This would make it much easier to compare foods before adding them to the diary.
In addition to custom columns, it would also be extremely useful to select two or more foods directly from the search results and open a detailed comparison view.
For example, if I search for “Greek yogurt” and find several similar entries, I could select two of them and compare their full nutritional profiles side by side. Not just kcal, protein, carbs, and fat, but also micronutrients, serving sizes, database source, completeness of data, and maybe even a “data quality” indicator.
Something like:
| Nutrient | Greek yogurt A | Greek yogurt B |
|---|---|---|
| Calories | 240 kcal | 380 kcal |
| Protein | 40 g | 32 g |
| Carbs | 16 g | 22 g |
| Fat | 0 g | 18 g |
| Calcium | 480 mg | 390 mg |
| Sodium | 140 mg | 260 mg |
| Vitamin B12 | 1.8 µg | Unknown |
| Data source | NCCDB | CRDB |
| Data completeness | High | Basic label only |
This would be especially helpful when choosing between branded foods, generic database foods, and richer entries from NCCDB or USDA.
Right now, comparing multiple entries can involve opening one item, checking the details, going back, opening another item, checking those details, forgetting what the first one said, opening the first one again, questioning your life choices, and eventually just picking the one with the nicest name.
A built-in comparison feature would make Cronometer much faster and more useful for meal planning, ingredient comparison, and choosing the most accurate food entry.
It would also pair really well with the first feature request about finding better replacements for scanned foods. If Cronometer suggests a richer NCCDB or USDA match for a barcode item, the user could compare the scanned product and the suggested replacement side by side before deciding whether to use it or enrich the original entry.
Why I think these would be Gold-worthy features
All three of these features are about the same thing: making Cronometer better at turning imperfect real-world data into useful, accurate tracking.
Barcode foods are convenient, but often nutritionally incomplete.
Fitness trackers are convenient, but often inaccurate.
Food search is powerful, but could be much easier to compare at a glance.
Cronometer is already one of the best tools for detailed nutrition tracking, which is exactly why I think features like these would fit so well.
Personally, these are the kind of features I would happily pay Gold membership for.