Father builds free photo-based carb counter: 3,000 users in 17 days

Before every meal, a person with type 1 diabetes needs to estimate how many carbohydrates are on the plate, convert them into bread units (BU, in Russian KhE), and then calculate the insulin dose from that. At home, scales and tables help. At school, at friends' houses, and in cafés they aren't available, and you have to eyeball pasta with a meat patty. This everyday pain point is where the story told by the author on Habr began.

What problem the app solves

Ready-made BU counters exist, but the most useful features, namely photo recognition and barcode scanning, are usually paid. Western services require a foreign card and barely know Russian products: neither our kinds of bread nor the familiar store-bought goods. The author decided to make his own: free, with no registration, and with a diary that lives only on the phone. For a medical topic this is an important product choice: users don't have to send their health data to a server.

The user flow is simple: photograph the plate, get an estimate of carbohydrates and BU, and save it to the diary. The model identifies the dishes from the image and estimates portions, and after that ordinary arithmetic takes over.

What the numbers show

The first version was released on October 20. Over 17 days the app was opened on about 11,800 devices, or roughly 700 per day. About 3,000 people calculated something at least once. That is about a quarter of everyone who opened the app, and for a niche tool with no advertising such a conversion looks decent.

On a typical day about 400 people use the app and recognize about 800 photos, that is, two shots per person. This looks like a real usage scenario: breakfast and lunch, rather than one-off curiosity. It is exactly this frequency that makes the cost of a single recognition the central question for a free product. If every model call costs money and the user is not supposed to pay, the arithmetic has to be done before launch, not after. The author promises to show what this costs in practice. The announcement itself gives no figures; they are in the full article.

Where the catch is

The author honestly warns that the AI makes mistakes and analyzes these cases separately. For a task involving insulin, this is the key point. A single photo cannot tell you exactly what is inside: how much oil is in a side dish, whether there is sugar in the sauce, how thick the patty is, what is hidden under the cheese. A 20–30% error in portion size is tolerable for an ordinary calorie calculator. For calculating an insulin dose it can be dangerous.

The second honest point: the code was written together with an AI assistant, and some decisions were made in a "quick and it works" spirit. For a first version this approach is justified, but in a medical context it has limits, and the author promises to talk about that too.

What to take from this

Practical takeaways for those building similar products on multimodal models:

• Start with a narrow, clear pain point, as here: the problem is personally familiar to the author, and competitors cover it for a fee and don't know local products.
• Local data storage and no registration lower the entry barrier and remove some legal risks.
• Calculate the cost of a single model call together with the expected frequency of use. Two photos per person per day across thousands of users quickly turn into a noticeable bill.
• In products close to health, present the result as an estimate, not as a guide to action. Users must understand that the decision about the dose remains with them and their doctor.

Bottom line: this is not a scientific breakthrough, but a good example of how a single developer with an AI assistant can build a useful niche product in a couple of weeks and gain thousands of users. The key details, namely the cost of recognition and the model's typical errors, are worth reading in the original. They show whether such a model withstands real load.