Choosing a MyFitnessPal alternative: four decisions that matter

If you are searching for a MyFitnessPal alternative, you almost certainly do not want a feature-for-feature clone. You want to stop doing the part you have quietly come to dread: opening a search box, typing a food name, choosing between eleven near-identical entries, and estimating a portion. The question worth asking of any replacement is not does it have my foods. It is how quickly can I get a meal recorded when I do not feel like recording it, and does the number it gives me stay still long enough to mean anything. Those two things decide whether you are still tracking in a month. Almost nothing else does.

I build a food and fasting app, so I have had to make decisions on all of this and live with them. Below is the shortlist I would use if I were switching, including the parts that are unflattering to my own approach.

What people actually want from a MyFitnessPal alternative

When someone tells me they are looking to switch, the reason is almost never a missing feature. It is one of three things:

• The logging cost is too high for the value returned. Four taps and a judgement call per item, several times a day, in exchange for a number that gets glanced at.
• The numbers stopped feeling trustworthy. Either the target moved for reasons that were never explained, or the app kept saying encouraging things that clearly had nothing to do with them.
• The data never became insight. Months of entries, and no answer to the only interesting question: what do I actually do repeatedly?

Those are three different problems and they point at different replacements. Be honest about which one you have before you download anything.

Logging debt: the number that predicts whether you will still be tracking in a month

Here is the pattern I would most like other people to use, because I have not seen it named and it explains most tracker abandonment better than any story about motivation.

Logging debt is the number of meals you have eaten but not yet recorded. It compounds, and past roughly one day it changes the rational decision from catch up to write off the week.

This is why abandonment almost never happens on day one. It happens on day nine. You skip a lunch entry because you are in a meeting. Now dinner is guesswork too, because you cannot remember what the lunch was. By Wednesday the week has three holes in it, the weekly average is meaningless, and starting fresh on Monday is genuinely the more sensible option. Then Monday arrives and the same thing happens.

So when you evaluate a candidate app, do not test it on a well-behaved Tuesday breakfast. Test it on the meal you would normally skip logging: a shared plate, something someone else cooked, a thing you ate standing up. Time it. If clearing a three-meal backlog takes more than a couple of minutes, the app will not survive contact with a bad week, no matter how good its database is.

There is a corollary that people find counterintuitive. Per-meal precision matters less than weekly coverage. An estimate that is consistently a bit off shifts the level of your weekly average while preserving its shape, and the shape is where all the useful information lives: which days run high, whether protein collapses at breakfast, what Fridays do to you. A missing third of your meals destroys the shape entirely. Unlogged food is the dominant error term in every food diary I have ever looked at, and it is the one nobody optimises for.

Ask how many activity levels it offers, then do the arithmetic

This is the fastest quality signal available during a sign-up flow, and it takes ten seconds to check.

Most calorie targets start from a resting energy estimate, commonly Mifflin-St Jeor, multiplied by an activity factor. The published factors run from about 1.2 for sedentary to about 1.9 for very heavy daily training or physical work. Take a 35-year-old man, 80 kg, 180 cm. Resting estimate: 10 x 80 + 6.25 x 180 - 5 x 35 + 5 = 1755 kcal.

• At 1.375 (light activity): about 2,410 kcal
• At 1.55 (moderate): about 2,720 kcal
• At 1.725 (very active): about 3,030 kcal

Adjacent steps are worth roughly 300 kcal a day. An app that offers three buttons has to map that whole range onto three of those numbers, which means people at the ends get a target that is out by 300 to 600 kcal every single day. That error does not average out. It compounds, and it compounds in the direction of the user concluding that tracking does not work for them.

Five levels across the full 1.2 to 1.9 range is not a sophistication flourish. It is the minimum resolution at which the output is worth calculating at all. If the onboarding gives you sedentary, normal and active, you have learned something about how much attention went into everything downstream.

Ask whether the target moves when the scale moves

Weigh yourself for a week and you will see swings of a kilo or more that have nothing to do with fat. Water, sodium, food still in transit, time of day, how well you slept.

Some apps respond to that daily number by recalculating your target. It feels attentive. It is mostly reacting to noise, and it teaches you something corrosive: that the number is soft. Once you believe the target is soft, you stop treating it as a reference and start treating it as a suggestion, and at that point it has no function.

In Numi I made weight a seven-day trend rather than a daily figure, and a stored target only changes on a persistent shift, not on a single reading. That means the app is sometimes slower to react than the scale. I consider that the correct trade. A reference value that moves under you is not a reference value.

So ask: what has to happen before this app changes my number? If the answer is a Tuesday morning weigh-in, be sceptical.

Separate what you decided from what the app worked out

Here is the distinction I would want every tracker to make explicit, because collapsing it is how software ends up quietly overruling a decision you made on purpose.

• Declared: your intent. Lose, gain or maintain. A target weight. A pace you are comfortable with. This is yours, it rarely changes, and nothing should touch it without you.
• Derived: calories, macro split, hydration target, projected timelines. These are computed from the declared intent plus your measurements. They can and should be recalculated.

When the two live in the same place, you get the failure everyone has experienced: you set out to gain slowly, the app recalculates something, and three weeks later you notice you have been eating at maintenance. Nobody chose that. It emerged.

The test is simple. Open the settings of a candidate app and see whether you can tell, at a glance, which numbers you chose and which numbers were worked out for you. If you cannot, you will not notice when one overwrites the other.

Plateaus: detection and action are different jobs

Progress stalling is normal and an app noticing it is genuinely useful. What it does next is where the design position shows.

An app that silently lowers your intake when the trend flattens has made a decision on your behalf that you cannot see, cannot audit and cannot argue with. It might even be the decision you would have made. That is not the point. The point is that you now cannot tell whether your plan is working or whether the plan changed.

Detection and action are separate jobs. The right behaviour is to say plainly: your trend weight has been flat for eighteen days, here are two things you could change. Then let the person decide. Same for insights, incidentally: if an app tells you "great choice!" after a photo, it is not talking about you, and you will know that instantly. An observation that references something real, such as what you have already eaten today or what you have done four days running, earns attention. A generic one spends it.

What you should expect to lose

Switching costs something. Anyone who tells you otherwise is selling.

• Exact figures for packaged products. A barcode scan against a maintained database gives you the label, to the gram. A photo estimate does not. If your diet is mostly packaged food and you care about single-gram fidelity, that is a real downgrade.
• Years of history. Do not expect it to migrate cleanly. Export it, keep the file, treat it as an archive rather than something to reconcile.
• Deep exercise integrations and community features. Established apps have had a decade to build these out.
• Familiarity. You know where everything is. That is worth more than people account for, and it is why the first three days of any switch feel worse than they are.

The thing you get back is time and a lower chance of accumulating logging debt. Whether that trade is good depends entirely on which of the three problems above you actually have.

Who should not switch

I would rather say this plainly than pretend a photo-first approach suits everyone.

If you are in a contest prep, working with a clinician on a specific intake, managing a condition where precise carbohydrate figures matter, or otherwise in a situation where being 15% out on a meal has consequences, weigh your food and log it by weight. That is the right tool for that job. Estimation from images is a proposal with a confidence range, and no interface design changes that.

The rest of us are not in that situation. We are trying to find out whether protein is consistently low, whether the evening is where the day gets away from us, whether hydration collapses on working days. Those questions are answered by two weeks of complete-ish data, not by one week of very precise data with holes in it.

How to judge a replacement in fourteen days

1. Day one: check the onboarding. Count the activity levels. Look at whether your goal intent is stored separately from the numbers derived from it. This tells you most of what you need to know before you log a single meal.
2. Days one to fourteen: log everything, badly. Accept estimates. Do not correct portion sizes unless they are obviously wrong. You are testing coverage, not precision.
3. Deliberately create logging debt. Skip a day on purpose, then try to catch up. This is the single most predictive test and nobody runs it.
4. Weigh daily if you weigh at all, and only look at the trend. Ignore the daily figure entirely for two weeks. If the app makes that hard, that is information.
5. On day fourteen, read the weekly summary and ask: could I have guessed this? If it tells you something you already knew, or something so generic it could apply to anyone, the pattern intelligence is decorative.

One caveat on the numbers. Your new target will almost certainly differ from your old one, often by a few hundred calories, mostly because of the activity multiplier and rounding. That is not one app being right and the other wrong. Both are estimates of a quantity nobody can measure directly outside a lab. The useful property of a target is not that it is true, it is that it is stable enough for you to learn what happens when you sit above or below it.

That is really the whole argument for switching. Not a better database. A number that holds still, a logging cost low enough that a bad Wednesday does not cost you the week, and observations specific enough to be worth reading. If you want to see how one implementation of that looks, Numi is mine, and the four tests above are the ones I would want you to apply to it.