Allish
The shops had the products and the customers already trusted them. What was missing was the coordination between four people who each needed a different view of the same order. Five apps, one basket, and a design problem that lived almost entirely in the handoffs.
The problem wasn't groceries. It was coordination.
Local grocery stores already had the products. Customers already knew which shops they trusted. Nothing about supply, demand, or trust needed inventing. The gap was digital infrastructure: there was no layer that connected discovery, catalogue management, order fulfilment, and last-mile delivery without turning shop owners into ecommerce operators.
Look closely at a single order and the reason becomes obvious. One basket of groceries passes through four people who need four incompatible things from it. The customer wants one shop and one delivery. The merchant wants to know what to reserve and at what price. The shopper wants a picking route and a substitution rule for the item that is out of stock. The rider wants an address, a time, and the shortest path between two pickups. The same order, four irreconcilable views, and the product is whatever holds them together.
Allish's answer was a multi-sided marketplace. Five separate apps, each built around one participant's actual job: customers browse and order; merchants manage stock; shoppers prepare orders; delivery partners handle pickup and drop-off; platform operations run through a central admin layer. One customer experience. Five operational systems running underneath it.
Building it that way makes the seams the real design surface. Any individual screen can be made good in isolation. What decides whether the product works is what happens between them: the moment an item is unavailable and the shopper needs a decision, the moment an order leaves the shop and becomes a delivery, the moment a merchant changes a price while a basket containing it is open. None of those moments belong to a single app, which is exactly why they are the ones most likely to be left undesigned.
The cold start problem: customers need merchants; merchants need customers.
Every multi-sided marketplace has a sequencing problem. Customers won't use the platform if there aren't enough stores. Stores won't bother cataloguing their inventory if there aren't enough customers. You have to pick a side to solve first.
The right call was supply-first. The Catalog App was the entry point for merchants, getting stores online before activating demand. A customer who opens the app and finds ten well-stocked local stores has a reason to order. A customer who finds three stores with 30% of their inventory listed doesn't come back.
This also shapes the catalogue completeness metric. A store with an incomplete inventory isn't just less useful, it is actively harmful to how the whole marketplace is perceived. The product needs to either make complete cataloguing low enough effort that stores do it naturally, or surface incomplete stores lower in discovery until they hit a completeness threshold.
Five product decisions that removed coordination instead of adding features.
01. Hide the seams. A customer ordering from three stores should feel like shopping in one. The moment they have to think about which store a product comes from, the product has failed its most basic job. Every bit of coordination that surfaces to the customer is a cost the platform failed to absorb.
02. Let the barcode do the work. A merchant adding products shouldn't have to type information that already exists on the physical packaging. Scanning pulls what's already there: faster, more accurate, and a far lower barrier to getting inventory online at all, which is the only thing standing between a pilot and a marketplace.
03. Separate listing from fulfilling. Adjusting prices and availability is a different mode of work from packing a live order under time pressure. Conflating them means context-switching at exactly the wrong moment, and the moment a shopper is most likely to make an expensive mistake is the moment a customer is watching.
04. Make delivery a first-class product. A rider navigating between pickups has fundamentally different information needs from a shopper preparing a bag. Treating delivery as a feature inside another app means building something adequate for both and excellent for neither.
05. Absorb platform complexity in the admin layer. The participant apps should be as simple as possible. The tools for managing the marketplace belong in a dedicated operator layer, not distributed across experiences that weren't designed to carry them. Read together, none of these five decisions adds a feature. Each one removes a coordination cost from somebody who should never have been asked to carry it.
Hiding the seams spends the thing that made it work.
The first decision is the one worth arguing with. A customer ordering from three shops should feel like shopping in one, which means the product deliberately obscures which shop each item came from. That is correct for the basket and expensive for everything underneath it.
What made local grocery viable in the first place was that customers already trusted particular shops. That trust was the asset the platform did not have to build. Hiding the seams spends it. The moment provenance disappears, the shop stops being a business the customer has a relationship with and becomes inventory, and the loyalty transfers to the platform, which is convenient for the platform and not obviously good for the merchant who spent years earning it.
It also moves every promise onto the platform. If one shop is slow, the delivery is late. If one shop substitutes badly, the order is wrong. The customer has no way to attribute any of it, so all of it lands on Allish. The merchant is insulated from feedback that would otherwise reach them directly, which weakens the loop that keeps a good shop good.
The decision still holds, because a customer forced to think about fulfilment logistics has been handed the platform's job. But the honest version is that it buys a clean basket by taking on operational risk and quietly converting merchant relationships into supply. A version worth testing would surface provenance after the fact rather than during, at the point where it builds confidence instead of friction.
What would tell you it is working.
The marketplace hypothesis lives or dies on one metric: cross-store basket rate. Are customers actually combining products from multiple local stores in a single order? If they are, Allish is genuinely functioning as a marketplace and not just a digital storefront for one shop at a time. If they aren't, the discovery layer isn't surfacing complementary supply, or the merchant density in the pilot area isn't high enough to make it possible.
On the merchant side: catalogue completeness per store and order acceptance rate. A store that accepts 60% of incoming orders is breaking the customer experience downstream. Understanding why, whether inventory mismatch, staffing, or catalogue staleness, is the operational question the admin layer needs to make visible.
On fulfilment: time from order placed to rider pickup, and delivery completion rate. These are the metrics that determine whether the promise to the customer is real. Everything else is a leading indicator.