The scale · Decision 11 of 12

How fast the app will let you lose weight

During setup the app asks how fast you want to lose weight, and then refuses some of the answers. The choice stops at 0.8% of your body weight per week. That is not a round number, and it is not the one usually quoted from the study it comes from.

Written and maintained by Mattias Geniar. Last updated .

What the app does
Limits the pace to 0.8% of body weight a week, and separately to 35% of what you burn, whichever limit is reached first. The backend fallback is 0.5%; current onboarding preselects its lower, rounded Steady option.
How sure we are Thin , One small study, or an engineering choice.
This rests on one trial of 24 elite athletes. It is the weakest evidence behind any number in the app, and a number we can defend is still better than no number.

The evidence for it, and it is one trial

One small trial informed the choice. It did not test the app’s 0.8% limit or establish a universal safe rate.

+2.1% lean body mass, in the athletes losing 0.7% of body weight a week Garthe et al. (2011) · ± 0.4% (reported ±; not a confidence interval) · 24 elite athletes
−0.2% lean body mass in the group told to lose twice as fast, for the same total weight lost The same trial · ± 0.7% (reported ±; not a confidence interval), p < .01 between groups
1.0% what the fast group actually lost per week, not the 1.4% it was told to. The app stops at 0.8% The same trial · ± 0.4% (reported ±; not a confidence interval) · the 0.8% limit sits under this rate

The calorie-target audit separates the implemented calculation from its assumptions, including gain and maintenance. The 0.8% limit is a product choice informed by this trial, not a tested safety threshold. The calorie lower bound now rounds upwards so the stated deficit cap survives rounding.

The trial the limit comes from

Garthe et al. (2011) assigned 24 elite athletes to lose weight at either 0.7% or 1.4% of body weight per week. All of them did four strength training sessions a week. Both groups lost about the same total weight (5.6% and 5.5%). The difference was in what they lost.

+2.1% lean body mass, losing at 0.7% a week ± 0.4%
−0.2% lean body mass, in the fast group ± 0.7% (reported ±; not a confidence interval), p < .01 between groups
−31% / −21% fat mass, slow group against fast Same total weight lost, different make-up
Where 0.8% comes from, why not 1%, and why the default is well below it Weekly rate of weight loss, as a share of body weight.
Where the app starts, if you never answer 0.5%

About 0.4 kg a week for an 80 kg person. Not taken from the trial, but chosen to stay well under the limit

What the slow group achieved 0.7%

Lean body mass rose 2.1%. This is the group that did well

Where the app stops 0.8%

Above the slow group, below what the fast group actually managed

What the fast group achieved 1.0%

± 0.4%. Lean body mass did not change: −0.2% ± 0.7%

What the fast group was told to lose 1.4%

The number everyone quotes, and the prescribed group target, not the achieved group average

0 1.5% of body weight a week
The fast group never lost at 1.4%. It managed 1.0% ± 0.4%. So 1.0% is not a cautious reading of this trial. The fast group did not gain lean mass; its small measured change was statistically unchanged, not evidence of muscle loss. Stopping the choice at 1%, which the usual “0.7 versus 1.4” summary suggests, would put the top end exactly on the group that did worse. 0.8% sits above what the slow group did and below what the fast group actually did. The rate an account gets for never answering the question sits well under both.

Why the default is 0.5% and not the limit

If you never answer that question, you get 0.5% a week, about 0.4 kg a week for an 80 kg person. That number is deliberately well below the limit. A default at four fifths of a maximum is not really a default. It is the maximum with a choice drawn next to it, and somebody who was never asked has not agreed to the top of our product’s permitted range. That range is not a clinical safety guarantee.

The backend fallback and the onboarding selection are different. Current onboarding preselects Steady; the 0.5% fallback applies to calculator requests with no pace. The old 800-profile comparison has been removed: its exact profile grid was not reproducible from the page, and being below resting expenditure is not a test of dietary safety.

What changing a requested rate does to simple arithmetic Illustration: 80 kg starting weight, 10 kg to lose, holding the initial weekly rate constant.
Illustrative 0.65% rate 19.2 weeks
Illustrative 0.5% rate 25 weeks
0 30 weeks
0.65% × 80 = 0.52 kg/week; 0.5% × 80 = 0.40 kg/week. Dividing 10 kg by each gives about 19.2 versus 25 weeks. This ignores expenditure adaptation and calorie caps, so it is not an app forecast.
A Snapkin onboarding screen headed “How fast?” offering Steady at about 0.2 kg a week, Normal at 0.5 and Brisk at 0.7, with a note explaining that the fast end stops at 0.8% of body weight a week as a product guardrail rather than a proven safety threshold.
The screen where the limit is applied, and says so.

The limit is not hidden in a settings screen or a help article. The screen that asks the question also says where the limit is and, in one sentence, what the trial found. If the app is going to refuse somebody the answer they wanted, it should tell them why right there.

The three paces you can pick are shown in kilograms rather than percentages, because kilograms are what people think in. The percentage is what does the refusing underneath. Current onboarding preselects Steady. The 0.5% backend fallback is used only if a calculator request supplies no pace.

The evidence against, and it is a small study

24 people, split 13 and 11. That is a very small trial, and the confidence intervals around everything above are wide. They were also elite athletes: young, lean, lifting weights four times a week under supervision, with their diets prescribed. Almost nobody using this app is that person, and nobody knows which way the difference goes for everyone else. Training experience, starting body composition and intervention duration can all change the response.

The trial also lasted 8.5 weeks in the slow group and 5.3 in the fast one, so it says nothing about a year. And it measured lean body mass with a DEXA scan, which cannot tell muscle apart from the water and glycogen that shift with a bigger calorie deficit. A −0.2% non-significant change cannot establish muscle loss.

We used it anyway, because a number we can defend is better than no number. The alternative was the fixed rule this app started with, 20% under what you burn, which gave lighter, active people a loss rate above 1% a week without ever asking them. But it is one small study on people unlike you, and it is the weakest evidence on these pages.

Why a heavy person gets a second, tighter limit

A percentage of body weight does not protect heavy people, because their body weight is what makes the number large. At 180 kg, 1% a week is 1.8 kg a week, about 1,980 kcal a day below what that person burns.

54% deficit, for an inactive 180 kg man at 1% a week Illustration: age 38, 178 cm; estimated expenditure 3,682 kcal/day
≈1,700 kcal a day that leaves him Above our 1,500 kcal minimum, so the minimum never applies
35% the hard limit on any deficit Applies before the body-weight limit for heavy, inactive people

So there is a second limit: the pre-rounding deficit is capped at 35% of estimated expenditure. For heavy, inactive people it applies before the body-weight limit does, which is the right way round.

We are not aware of a trial that tested 35% specifically. We chose it as a product guardrail rather than deriving it from a study, and we would rather say that plainly than attach a citation that does not test it.

The goal date is the least reliable number we show you

A Snapkin onboarding screen reading “Losing 8.3 kg by March 2027” over a falling line from 90.3 kg today to a goal of 82 kg, with an uncertainty band around it, and a paragraph explaining that real weight moves in steps and that the app follows your trend chart rather than this drawing.
The screen, including the paragraph that says not to trust it.

The date converts your calorie deficit into weeks using 7,700 kcal per kilogram of body weight, a straight line based on the energy stored in body fat. It assumes everything you lose is fat, and that what you burn does not fall as you get lighter. The calculation omits important physiology, and often overpredicts long-term loss as expenditure falls. Early water and lean-tissue changes can instead make scale loss faster than a fat-only calculation.

Early water and glycogen changes vary by diet and person. The line cannot forecast them or identify how much of a change is fat.

The proper, dynamic version of this calculation is the subject of Hall et al. (2011). Their starting point is that you cannot predict body weight over time accurately with a fixed rule. You have to account for how energy balance changes as you go. We have read that paper's abstract and its title, not its full model, and we are not implementing it.

What we do instead is limit the error. Weeks are rounded up, because a plan that finishes late is a smaller error than one that finishes early. No date is shown beyond two years, which is where the straight line is most wrong and a date is least useful. And when the calorie minimum is what limits your pace, the screen says so and shows no date at all. The alternative would be printing a technically correct 75 weeks, worked out from a rate of 0.04 kg a week.

Treat it as an illustration of the arithmetic you chose, not a forecast. The trend chart is a smoothed summary of measured body weights, not a measurement of fat loss or a guarantee that the calorie estimate is correct.