Mobile app or PWA for a D2C brand?

Almost every D2C brand gets pitched an app, and almost none of them need one.

That is not a technology opinion. It is arithmetic about how often your customers buy. An app is a retention instrument — it earns its cost through repeat purchases from people who install it — and if your customers buy from you twice a year, there is no plausible number of app installs that pays for two codebases, two review processes and a permanent maintenance obligation.

Here is the threshold, what a modern web experience gets you instead, and the narrow set of cases where an app is genuinely the right call.

What an app actually gives you

Four things, and it is worth being precise because three of them are smaller than they sound.

A permanent place on the home screen. The real one. Being on somebody’s phone, visible daily, is a genuine advantage that a website does not have.

Push notifications. Powerful and easily squandered. Effective when they are useful and personal; a fast route to being uninstalled when they are campaigns.

Deeper device access. Camera, biometrics, background processing, offline behaviour, wallet integration. Genuinely useful for a small number of product types and irrelevant for most stores.

A different quality ceiling. Native apps can feel better than the web, particularly for complex, frequent interactions. For a catalogue and a checkout, the gap is much smaller than it used to be.

Notice what is not on the list: better conversion in general, better performance in general, or being taken more seriously. Those are consequences of building something well, not of the platform you built it on.

What it actually costs

The build is the smallest part, which is the same pattern as everything else in this category.

Two platforms, unless you use a cross-platform framework — which most brands should, and which still means two build pipelines and two sets of platform quirks.

Store review processes. Every release, on somebody else’s timetable. This changes how your team works permanently: you cannot fix a typo in the afternoon.

Operating system updates, twice a year, forever. An app that is not maintained stops working, and the failure is abrupt rather than gradual.

Support for versions people did not update. A share of your users will be on a build from eight months ago. Your back end has to keep talking to it.

Marketing to get it installed at all. The largest hidden cost. An app nobody installs is a very expensive website nobody visits, and the acquisition cost of an install is real money.

Your web experience still exists. You are not replacing anything. Every new customer arrives on the web, and the app serves the ones you already have.

That last point is the one that reframes the decision: an app is an addition to your stack, never a substitute, and it has to earn its keep on top of everything you already maintain.

The threshold that decides it

One number: how often does a customer buy from you in a year?

Once or twice. A website. There is no retention to capture, because there is nothing to retain them for between purchases. Spend the money on the product page and the checkout instead.

Three to six times. A well-built, installable web experience is almost always the right answer. Enough repeat behaviour to be worth nurturing, not enough to justify two codebases.

Monthly or more. Now the conversation is real. Consumables, replenishment, groceries, coffee, supplements, pet food, anything with a subscription rhythm. At this frequency an app can genuinely change customer value.

Weekly or more, plus a service component. Clear case. Loyalty, scanning, ordering ahead, wallet, location — the interaction is a habit and it deserves a home-screen icon.

Two adjustments to that scale. A meaningful subscription base pushes you up a band, because those customers already have an ongoing relationship. And a genuinely complex configuration step — something people do repeatedly and find fiddly on the web — can justify an app at lower frequency.

Everything else is ambition, and ambition is an expensive reason.

What a progressive web app gets you

A modern web experience, built properly, covers most of what brands actually want from an app.

Installable to the home screen, with an icon and a full-screen experience.

Works offline or on a poor connection, at least for browsing and for holding a basket — which on a variable mobile network is worth more than most features.

Fast, app-like navigation between pages, without full reloads.

Push notifications, with real platform caveats that vary and are worth checking for your markets rather than assuming.

No store review, no install friction, one codebase. You ship when you want, and every visitor already has it.

The last point is the one that decides it for most brands: a PWA is available to one hundred percent of your visitors immediately, and an app is available to the small fraction who install it.

Where a PWA genuinely cannot compete

Be honest about the gaps, because they are real for some businesses.

Deep device integration. Background processing, certain hardware access, tight wallet and biometric integration. If your product needs these, the decision is made.

Presence. An icon on a home screen produces a category of visit that does not otherwise happen — the idle open. Nothing on the web reproduces it.

Notification reliability. Web push works and its behaviour differs by platform and version in ways that a native app’s does not. If notifications are the core of your retention plan, that inconsistency matters.

A frequent, complex interaction. If your customers do something intricate several times a week, native still has a quality ceiling advantage.

The install problem, which is the actual problem

Here is what sinks most brand apps, and it has nothing to do with the build.

Getting somebody to install an app is a conversion funnel of its own: they have to want it, go to a store, wait for a download, open it, and probably create an account. Every step loses people, and the whole sequence has to be justified by a benefit they can anticipate before they experience it.

Which is why “we made an app” is not a reason to install one. The successful brand apps offer something the website does not: prices only available there, a loyalty balance, faster reordering, order tracking that is genuinely better, or a service component. If you cannot name that thing in one sentence, the install funnel will not convert and the app will sit unused.

Then there is the second half: retention within the app. A meaningful share of apps are opened once and never again. Your installs are not your users; your monthly actives are, and they are usually a fraction of the install count.

Model both funnels honestly before you commit. Installs times retention times purchase frequency times margin, against the three-year cost. If that number is not comfortably positive, the answer is a better website.

The India-specific angle

If a meaningful share of your customers are in India, three things shift the calculation, and not all in the same direction.

App usage is high, and storage is not. Indian users spend a lot of time in apps and a large share are on devices where storage is genuinely scarce. An app that is large gets uninstalled to make room, and it is usually the one used least — which for a brand app bought twice a year is yours. Size matters more here than almost anywhere.

Data is metered often enough to matter. A heavy app that downloads a lot on first open is a real cost to the customer, and it shows up in install-to-open drop-off.

The web experience is doing more work than you think. A large share of commerce discovery happens in a browser inside another app, and those sessions never reach your app regardless of how many people installed it. That is another argument for putting the effort into the mobile web experience first.

The counterweight: for genuinely high-frequency categories — groceries, quick commerce, consumables — Indian consumers are extremely comfortable with apps and the retention behaviour is strong. The threshold logic is unchanged; it is just that more categories clear it here than in some other markets.

The business case, written honestly

If you are going to argue for or against an app internally, build the model rather than the deck. Six lines, and most brands have never filled them in.

Multiply the first five, compare to the sixth, and the answer is usually obvious.

The line people get wrong is the fourth. It is not “purchases made in the app” — those largely would have happened on the web. It is the incremental purchases, which is a much smaller and much harder number, and it is the entire justification for the project.

If you cannot estimate it credibly, that is itself the finding: you do not yet know what the app would change, which means you are not ready to build one.

Two things that make brand apps fail after launch

Both are avoidable and both are decided before a line of code is written.

Nobody owns it after the launch push. The app ships, there is a campaign, installs spike, and then the team moves on. Six months later it is two OS versions behind, three flows are broken, and the reviews reflect it. An app needs a permanent owner and a budget line in exactly the way a website does, and considerably less forgivingly — a neglected website gets stale, a neglected app stops working.

Notifications get handed to marketing without rules. The fastest possible way to lose your installed base. Agree, before launch, what a notification is for: order status, back-in-stock, a genuinely personal prompt, a subscription action. Not campaigns, not discounts, not “we miss you”. One person owns the send list and can say no.

There is a third, quieter one worth naming: the app becomes a second product that has to be kept in step with the website, and every feature now costs twice. That is the real ongoing tax, and it is why the frequency threshold has to clear comfortably rather than narrowly.

What we would do first, instead

Almost always, and in this order.

Make the web experience genuinely good on a phone. Most brands considering an app have a mobile site with the problems we go through in why your store is slow on a phone and where mobile checkout leaks. Fixing those costs a fraction of an app and benefits every visitor rather than the few who install.

Make it installable. Icon, splash, offline basket, fast navigation. A week or two of work, and it gets you the home-screen presence for the customers who want it.

Build the retention mechanics that do not need an app. Email and messaging flows, a reorder path that takes three taps, subscription where the product suits it, and a reason to come back that is not a discount. This is where the value people expect from an app actually lives — see why order value beats conversion rate for the arithmetic.

Then measure the repeat rate for a year. If it climbs into the monthly band and you have something an app would do better, build one, with a real business case rather than an ambition.

Making a web experience installable, practically

Since this is the recommendation for most brands, it deserves more than a mention. It is a fortnight of work and these are the parts that matter.

A proper manifest and icons. Name, short name, theme colour, icons at the sizes each platform wants, and a splash configuration. This is what turns a site into something that sits on a home screen without a browser chrome around it.

A service worker with a conservative caching strategy. Cache the shell, the fonts and the static assets. Be careful with anything price-related or stock-related — showing a stale price is worse than showing a slow one. Get this wrong and you have built a store that lies.

An offline state that is useful. Not a dinosaur. The last collection they browsed, their basket, and a clear message that they are offline and it will sync. On a variable mobile network this alone changes how the store feels.

Fast navigation between pages. Prefetch the likely next page, keep the shell, avoid full reloads. This is where the app-like feeling actually comes from.

A considered install prompt. Not on the first visit, not modally, and not before you have given them a reason. After a purchase, or on a second visit, with one sentence about what they get.

And check the notification story for your markets. Web push behaviour varies by platform and version, and it changes. Verify what is available where your customers are rather than relying on a blog post from two years ago — including this one.

Done properly, this is indistinguishable from an app for a catalogue-and-checkout business, and every visitor gets the benefit rather than the minority who would have installed something.

When an app is right

Four situations, and they are recognisable.

High purchase frequency with a habitual rhythm. Consumables, groceries, coffee, supplements, pet food.

A subscription business with real management needs. Skip, swap, pause, reschedule. People do these often and they are fiddly.

A service component alongside the product. Booking, tracking, scanning, redeeming, checking in.

Genuine device requirements. Camera-led features, offline-first use, tight wallet or biometric integration.

If two of those are true, build it. If one is true, look hard at whether the web can cover it. If none is true, you are being sold something.

What it comes down to

An app is a retention instrument with a permanent cost, and it is justified by purchase frequency rather than by ambition, revenue or category.

Most D2C brands buy twice a year from their customers’ point of view, which means an app has almost nothing to retain. For them, a fast, installable, genuinely good mobile web experience gets ninety percent of the benefit, reaches every visitor rather than the ones who install, and costs a fraction as much to keep alive.

Build the web experience properly first. Measure the repeat rate for a year. And if the numbers move into the band where an app pays for itself, you will know exactly what it needs to do — which is a far better starting point than a pitch deck.

Been quoted for an app? Send us your repeat purchase rate and what you want the app to do, through the contact form. We will model the install funnel and the three-year cost against your actual numbers and tell you honestly whether it clears — and if it does not, what we would build instead for a fraction of it.

You can also read MVP scope discipline, or SaaS MVP: build, buy or no-code.