How to build a quick commerce app

Start by framing it as three products and a business

People describe a quick commerce app as if it were one thing. For the purpose of building, it is helpful to see it as three products that share a back end: the customer app, the rider app and the dark store tool. Add an admin panel that the business uses to run all of it. Each has different users, different devices and different failure modes, and each needs its own design attention.

The plan in the chart above reflects this. The back end and data model are built first and continue throughout, because everything else depends on them. The customer app, rider app and store tool are built in overlapping windows, with the customer app first because it is what you can show and test earliest.

The chart is one working plan for a small team and a single store. It is meant to be compared with a vendor's plan, and to expose where theirs differs from yours and why.

Phase one: backend and data, the part that decides everything

The first four weeks of the plan go to the core of the system: the catalogue, the orders and the rules that connect them. This looks dull and is the most important work in the project. A poorly designed data model makes every later feature harder, and changes to it become more expensive with every week.

The decisions to make are concrete. How are products and variants represented? How is stock tracked per store? What states can an order be in, and what moves it from one to the next? How is a customer's address linked to the store that serves it? Answer these on paper, with examples, before any code is written.

A single backend that serves all the apps is almost always the right choice at the start. It keeps one source of truth. Splitting into many services is a response to scale and team size, not a place to begin.

Phase two: the customer app

With a working back end, the customer app can be built quickly. The essential journey is sign in, browse and search, add to cart, choose a slot, pay and track. Resist the temptation to start with the home page and its rich banners. Start with the journey from search to paid order, working end to end, and add decoration later.

Test on real, modest phones from the start. Quick commerce customers are not all on the latest devices, and an app that is smooth on a new phone and sluggish on an older one will lose the customers you most want.

Payments deserve a milestone of their own, with test mode first and a staged move to live, including the unglamorous cases: failed payments, duplicate attempts, refunds and what the customer sees at each step.

Phase three: the rider app and the store tool

These are built in parallel and they depend on each other. The store tool produces a picked and packed order. The rider app picks it up and delivers it. The hand-off between them is one of the places where delays hide, so design it as one flow and not as two apps.

For riders, simplicity beats features. A clear task, a button to accept, directions, a way to confirm pick-up and delivery, and a way to report a problem. Many riders are using low-end phones with limited data, so the app should be light and forgiving of poor connectivity.

For store staff, speed is the thing. A picker walking an aisle with a phone needs a list ordered by where items are, a one-tap way to mark each one found or missing, and a clear signal when the order is complete.

Operations: the work that is not software

While the apps are built, the business has its own work: choosing and stocking the catalogue, setting prices, finding and onboarding riders, and fitting out the store. These tasks decide whether the apps have anything to do.

It is worth running the manual version of the service before the software exists. Take orders by phone for a few days, pick and deliver them by hand, and learn what goes wrong. The problems you find become the requirements for the software, and they are far more reliable than guesses.

Phase four: testing and the pilot

The last third of the plan is testing and a pilot launch with one store. Testing for a commerce app is not only about bugs. It is about load, about the evening rush when many people order at once, about poor connections, about two riders accepting the same order, and about what happens when a store runs out of an item in the middle of an order.

The pilot is a controlled launch to a small area. Its purpose is to learn. Measure how long orders take from tap to door, how many are partially fulfilled, and where customers abandon the cart. Fix what you learn, and only then widen.

Where plans like this slip

• Late decisions about how stock enters the system.
• Rider supply that does not materialise on time.
• Payment provider onboarding and approval taking longer than expected.
• App store review times, especially for the first release.
• Scope growth from 'one more thing' during the build.
• Testing squeezed because the date is fixed.

Several of these are outside the developer's control, so build slack into the calendar and start the slow external processes, such as payment gateway approval, in week one.

Five decisions to make before any code is written

Several choices shape the plan more than any technology decision, and they should be made first. The first is whether you will run your own riders or use an existing delivery network. It changes the size of the rider app and the dispatch logic, and it changes your unit economics. The second is how stock reaches the system: by scanner, by integration with a billing system, or by hand. It decides how much the customer can trust what is shown.

The third is the geography of the first launch, in terms of the area a store can serve in the time you promise. It is a business question with a technical consequence, because delivery radius and slot logic are built into the back end. The fourth is the payment methods you will support at launch, and who will open the gateway account and complete its verification.

The fifth is who owns the catalogue. Producing clean product data with names, categories, images and prices is a project of its own, and an app with a thin catalogue looks broken however good the engineering is. Decide whether you will buy a ready dataset, build one by hand or import it from a supplier, and start early.

What to have written down at each stage

A project like this produces a lot of decisions, and the ones that are not written down get remade, often differently. At the end of the first phase you should hold a data model diagram, a list of order states and what moves an order between them, and the rules for stock and slots. After the apps are built, you should hold the list of notifications and when each is sent, and the access rules for each role.

These need not be long. A page each, kept in the repository next to the code, is enough. Their value shows up six months later when someone new joins, or when you want to change a rule and need to know what else depends on it.

Questions to check a vendor's plan against this one

1. Which tracks are in your plan, and which are missing?
2. Which weeks are the back end and data model, and what is decided in them?
3. Where is the pilot in your plan, and with how many stores?
4. How and when do we test the evening peak?
5. Which external approvals could delay us, and when do we start them?