Manual logging is the retention ceiling for Indian health apps

The thesis

The retention ceiling on an Indian health app is set by how much typing its core loop requires, not by the quality of its content, and not by the cleverness of its notifications. Anything that removes typing raises that ceiling more than anything that improves what sits above it.

I argue the input-tax half of this from experience, in the Steps Premier League case study. What that case study does not have is the second half: if manual entry is the ceiling, what actually removes it at national scale, and is that thing real yet.

India is the one market where the answer is a specific piece of public infrastructure with a published dashboard, which means the question can be argued with numbers instead of intuitions.

The mechanism

India has a structural answer that most markets do not.

Under the Ayushman Bharat Digital Mission, launched in September 2021, a person holds an ABHA identifier. With their consent, records held by registered providers can be shared to a registered application. A lab report can arrive in an app because someone consented once, rather than because they photographed it on a kitchen table at 11pm.

That changes what a product is allowed to open on. The first screen stops being a form. Instead of “tell us your numbers so we can help you,” it becomes “here is your last panel, and here is what changed since the one before it.” The difference is not cosmetic. One asks for work before value, and the other delivers value before asking for anything.

Every downstream mechanic gets cheaper. A trend needs two readings; if both arrive by consent, the trend is free. A nudge that references a real value is a different object from a nudge that references a category.

The evidence, and what it actually says

The infrastructure is real, and it is not a pilot. Nearly a billion identifiers and over a billion linked records is not a proof of concept; it is one of the largest health data networks ever built.

Now divide. 1,131,987,043 records across 967,178,326 accounts is 1.17 records per account.

Which sounds like the end of the thesis. The pipes exist at a scale nothing else in the world matches, and the average account behind them holds barely more than one document. A mean also hides its own distribution: records are almost certainly concentrated in a minority of accounts, so the median account probably holds fewer than the mean, not more.

That ratio is a stock, and the decision needs the flow

A lifetime cumulative average is the wrong statistic for a question about direction. It includes every identifier generated in 2021 and averages four years of a growing network into one number, so it will understate the current rate for as long as the network is accelerating.

The same dashboard publishes the flow alongside the stock. Month-to-date for August 2026, against the same 07:46 AM stamp:

The caveat, and it is not small: 7.4 is not “records per new account”. Records linked in August attach to whichever account owns them, most of which were created in earlier years. So this is a comparison of two rates, not a per-person figure, and I would not put it in a deck as one.

What it does support is narrower and still worth having: the network is currently adding records far faster, relative to identities, than it did on average over its life. The stock says the cupboard is nearly bare. The flow says it is filling. Both are true, and a thesis that quotes only the first has picked the number that makes its own argument sound more contrarian.

One month is not a trend, and I have one reading. The honest next step is to take the same two columns weekly for a quarter and see whether the ratio holds, which costs nothing but patience, and is the difference between this being an observation and being evidence.

For a product manager the implication is specific and unglamorous. A consent-based pull is an acquisition feature today and a retention feature on a timeline you do not control, and building as though it were already the second is how you ship a beautiful empty state to most of your users.

The objections, taken seriously

This is the section that decides whether the thesis is worth anything, so it gets the most room.

Consent is a funnel, and a hard one. Linking records is not a permission dialog. It is handing over a medical history on the strength of whatever trust an app has earned, which at signup is close to none. The pull is most valuable exactly when the app has least earned the right to ask. Every product that has tried to front-load this has discovered that the moment you ask, you convert the warm curiosity of a new user into a decision about medical privacy, and a meaningful share of people answer that decision by closing the app. I do not think this objection has a clean answer. I think it means the ask has to come second, after something useful has already happened, which costs you the first-screen benefit that made the mechanism attractive in the first place.

Coverage decides whether the promise survives contact. A pull returns what the producer of a record has published to the network. Participation is uneven across states, provider types and private-versus-public facilities. The honest version of the feature is therefore some of your records, sometimes, and an app that promises a complete history and returns two documents is worse off than one that promised nothing, because it has now demonstrated its own limits at the exact moment it asked for trust.

An identifier is not a user. Many ABHA numbers are created at a hospital registration desk, as a step in someone else’s workflow, for a person who may not know they now hold one. A number generated that way and a person who knows they have an ABHA and chooses to use it are different populations. Any adoption figure has to be read for which of the two it counts, and the headline figure counts the first.

And the counter-thesis, which I cannot dismiss. Maybe typing was never the ceiling. Maybe the ceiling is that most healthy adults simply do not want a relationship with a health app, at any level of friction, and removing the tax just gets you a better-instrumented version of the same churn. I do not have the data to rule this out. What makes me still hold the thesis is a narrower claim: among people who have already decided to engage, friction is the thing that decides how long they last. That is a smaller claim than “this fixes retention,” and it is the one I would actually defend.

What I would build first if I owned it

Not the pull. The empty state.

The first thing to build is what the product does for the roughly-everyone whose consent returns one record or none, because on today’s ratio that is the modal experience, and a feature whose modal experience is an empty screen will be judged on the empty screen. If the product is good for the person with one document, the pull makes it better. If it is only good for the person with a full history, the pull is a demo.

Second, the ask moves after first value, not before it. Third, the consent screen tells the truth about coverage in advance: we will fetch what your providers have published, which may be nothing. Managing that expectation before the pull costs one sentence and after the pull costs the relationship.

What would have to be true

1. Records per account rises materially, and rises for ordinary outpatient care rather than only for the encounters that already generate paperwork.
2. Consent completion clears a rate that makes the funnel worth it, and I would want that measured on people who have used the product for a week, not on people who met the ask at signup.
3. The thing you do with a record is worth more than the record. Getting the data is the easy half. Pulling a verified report says nothing about whether the person holding it can read it, which is a different product problem and the one I went and built Grounded for.

If those three do not hold, this is infrastructure looking for a use case.