In 2015 Flipkart built Flipkart Lite as a progressive web app after a period of pushing users to its native app. The published case study on web.dev reports time on site rising from about 70 seconds to about 3.5 minutes with 3x lower data usage and 63% of those users arriving over 2G. What problem forced the decision what did it actually buy and where would copying it be a mistake?

The situation they were in

A commerce business in India in 2015 faced a population it could not serve: entry-level Android devices on 2G, users with little storage headroom, and an install step that costs tens of megabytes before a visitor has seen a single product. The native app was the better experience for the people who already had it and it was a wall in front of everybody else, which is a distribution problem wearing the costume of a performance problem.

What they chose

A web experience designed for that population rather than a trimmed version of a desktop site: a cached application shell, a service worker so repeat visits work on a bad connection, and an install prompt that adds a home-screen entry without an app-store download.

Why it fit their constraints

The currency of the budget was the user's data plan and their device's patience, not a lab second. When 63% of a cohort arrives over 2G, bytes are money the user personally pays, and the reported 3x reduction in data usage is the number that explains the rest. The engagement figures follow from removing the install step, not from a framework choice.

What it cost them

Two client codebases with one product behind them, which is permanent organisational cost: every feature now has a reach question attached. Service workers also introduce a cache that outlives a deploy, so a bad release can be sticky in a way a server-rendered page never is, and the rollback path has to be built before it is needed.

Where copying it would be a mistake

• The famous conversion number is a self-selected segment. The frequently quoted 70% uplift is reported for users arriving through the home-screen entry — people who had already chosen to add the site. Quoting it as the effect of building a progressive web app is a sampling error, and it is the single most common misreading of this case study.
• The numbers are 2015 numbers for a 2G-dominated audience. A product whose users are on mid-range 4G Android with the app already installed is solving a different problem, and the same work will return a far smaller result.
• The lesson that transfers is the method, not the artifact: pick the slow end of your real user distribution, measure in the currency those users pay, and let that choose the architecture. A team whose audience is desktop office workers on fibre should read this case study and build something else.

When this is the wrong answer

If a native capability is the product — background location, a camera pipeline, a hardware integration — the web channel cannot substitute and the install step is not the obstacle. And a team of four should not run two clients: pick the channel where the users are, make it fast, and revisit when the second audience is measurable rather than hypothetical.