Build density one commercial locality at a time.
FromNational-first→ToLocality-first
Every commerce model needs density. Dark stores manufacture it by concentrating inventory; a distributed network has to find it in the demand of one catchment. That makes the locality, not the country, the unit of expansion: build one commercially complete neighbourhood, then replicate.
Coverage is not completeness
Most platforms scale by coverage. They sign up sellers everywhere and count them. But a network can have sellers everywhere and still be commercially incomplete everywhere. For a person with a mission, what matters is whether the right capability exists within reach, is verified and is available when needed. The evidence review makes the same point: success should be measured by commercial completeness, not seller count.
Density moves; it doesn’t disappear
Dark stores make density by concentrating inventory, and even they find it hard outside the largest cities. Redseer found that daily orders per store fell below 1,000 beyond the top 10–15 cities and below 700 in the next 20, with breakeven throughput 1.5–2 times metro levels[1]. A Redseer digest published in April 2026 put non-metro stores at about 850 orders a day[2]. A distributed model doesn’t escape that problem. It relocates it.
- Aggregate inventory
- Concentrate it
- Build demand density
- Fulfil fast
- Aggregate demand
- Discover distributed capability
- Activate existing capacity
- Fulfil as the mission requires
The claim is not that local merchants are cheaper, that distributed delivery costs less, or that dark stores will disappear. It is supply aggregation rather than inventory aggregation. Even so, someone still has to acquire the customer, process the request, contact the merchant, prepare a quote, coordinate fulfilment, handle support and resolve disputes. Instead of high transaction density at one inventory node, the network needs enough qualified mission demand across a set of nodes in the same catchment.
Density is local, and that is the whole argument for locality-first. The original concept sequenced it this way: start with one neighbourhood, onboard its commercial capability, make it discoverable, create transactions, strengthen the node, and only then replicate to the next[CN]. A national rollout would spread demand too thinly to reach density anywhere.
The locality is a dynamic geography
“Local” doesn’t mean a fixed circle illustrative. A bakery might need to be within 5 km and a plumber within 3 km, while an interior designer might serve a whole city, a rare instrument repairer 50 km and a custom furniture workshop an entire district. The mission and the capability set the catchment. That makes the neighbourhood a dynamic commercial geography rather than a delivery radius.
It is also what could make hyper-specialisation viable[CN]. A specialist too narrow to survive on one neighbourhood’s demand may be viable across ten, if discovery aggregates demand across the right catchment. That is a hypothesis for the demand-density tests, not a finding.
Go deeper
Mission economics, not order economics
Density has to be density of the right missions. A ₹300 commodity order and a ₹30,000 specialised service shouldn’t run on the same architecture. Every number below is an assumption to be replaced with pilot data.
illustrative Constructed to explain the idea, not data.
| Per completed mission | A: Appliance repair visit | B: AC supply and installation |
|---|---|---|
| Ticket value | ₹1,500 | ₹40,000 |
| Platform income (assumed rate) | 10% = ₹150 | 3% = ₹1,200 |
| Agent and concierge handling | ₹70 (about 20 min) | ₹150 (about 45 min) |
| Verification, support and disputes | ₹40 | ₹120 |
| Customer acquisition, amortised | ₹100 | ₹300 |
| AI and infrastructure | ₹10 | ₹20 |
| Contribution | about –₹70 | about +₹610 |
The numbers don’t matter; the shape does. Coordination cost is roughly fixed per mission. Low-ticket, one-off missions therefore need very low handling costs or high repeat rates, while high-ticket or product-plus-service missions can carry the coordination.
What to build first
Build for one locality, one capability-heavy category and one agent, backed by a human concierge, with perhaps 20–50 commercial nodes. The consumer says what they’re trying to accomplish, by voice, text or photo. The agent asks a few clarifying questions and returns three to five relevant nodes, each with its capability, proof, a short narrative, approximate economics, availability and service area, plus options to request a quote, book or buy. Integration with ONDC’s transaction rails should come once the workflow is understood, because the pilot’s job is to reveal which data objects and handoffs need standardising.
The draft proposes appliance repair and installation as the category. It bundles product, expertise, diagnosis, service, spare parts, geography, availability and trust, so it tests the architecture far better than packaged goods would. It also carries three cautions. Urgent repair is where a video-led “digital street” matters least (Shift 4). The incumbents are strong, notably Urban Company and brands’ own service networks. And pure repair tickets may be too small to carry coordination costs, as the table above suggests.
One resolution is to run the capability, trust, fulfilment and economics tests on repair, installation and replacement together, and to run the narrative test in a design-led category such as custom furniture. That is a decision for the team, as is the choice of locality.
The metrics that matter
Commercial completeness answers the question the original concept asked: how commercially complete is this neighbourhood?[CN] It is the share of pilot requests for which at least three qualified, verified providers were available within the mission’s catchment. Capability density counts verified, relevant capabilities per mission category in the catchment.
Mission completion cost is the all-in cost of taking a consumer from intent to a successful outcome, which makes it the real unit economics of this architecture. The node scorecard from the evidence review adds supply coverage, capability coverage, verified-provider rate, request-to-match time, successful fulfilment, repeat rate, merchant contribution margin, dispute rate and local satisfaction.
A locality with 10,000 listed merchants may be worth less than one with 500 highly discoverable, verified capabilities.
What could go wrong
- Demand density.Discoverable specialists may still receive too few qualified requests. In that case, locality-first would prove the opposite of what it hopes to.
- Catchment mismatch.Some capabilities only become viable across a catchment larger than any practical pilot. Dynamic geography helps with this but also complicates it.
- Replication.Replicating to the next neighbourhood is itself a hypothesis. A playbook proven in one locality may not transfer to another with a different supply mix, language or trust network.
- Low-ticket economics.If most missions in the category look like mission A, contribution stays negative until handling costs fall or repeat rates rise.
How we’d test it
Kill thresholds should be written down before launch. With roughly 100 requests and 20–50 nodes, results will be directional rather than statistically conclusive.
Completeness doesn’t rise with onboarding, or contribution stays negative across the category.
| The test | What we would measure | What would end the idea |
|---|---|---|
| Baseline audit (Experiment 0) | Nodes by type, capability layers, share digitally represented anywhere, completeness before intervention | None; this is the baseline |
| Demand density | Qualified requests per catchment, quote acceptance, repeat demand, completeness over time | Completeness doesn’t rise with onboarding, or qualified requests per provider stay below the agreed floor |
| Mission economics | Mission completion cost against contribution, by mission type | Contribution stays negative across the category by the end of the pilot |
How strong is the evidence?
- Established
- Density governs quick-commerce economics and is harder to reach outside metros (Redseer).
- Evidence-supported
- Completeness, not seller count, is the right measure for a local network.
- Hypothesis
- A distributed network can reach mission density one locality at a time, and the playbook replicates.
- Unknown
- Demand density per catchment, category economics, and how well a locality playbook transfers.
Sources
- [1]Redseer, Scaling Quick Commerce Beyond Metros: A Strategic Reassessment (2025)Checked
- [2]Redseer, Quick Commerce in India: Is Scale Expanding with Efficacy? (April 2026)Checked
- [CN]Voice-session working notes (internal)Provided
Spotted a source we missed or a rule we misread? Tell us what we got wrong.
A locality is only worth building if its businesses can be understood. That starts with what they can do, not only what they stock.