Best tech stack for a quick commerce app in India

What a stack is, and why a buyer should care

A technology stack is the set of tools and services a product is built on: the framework for the apps, the language and framework for the server, the database, the services for payments, maps and messages, and the place it all runs. Choosing a stack is mostly a developer's job, so you might reasonably ask why a buyer should read about it. The answer is that the stack decides three things you care about: how quickly it can be built, how much it costs to run and change, and how hard it will be to find people to maintain it.

The diagram above lists the layers of a quick commerce system and gives a pick for two situations: a small team starting out and a funded team with more people and more load. The reasoning is shown next to each layer so that you can judge it, not only accept it.

A recurring theme is restraint. The best stack for a first version is rarely the most impressive one. It is the one that a small team can build with quickly, run cheaply and change without fear.

The apps: one codebase or several

A quick commerce product has at least two mobile apps, the customer's and the rider's, and often a tool for store staff. Building each natively for Android and iOS means up to six codebases. A cross-platform framework such as Flutter reduces that to a handful, with one team able to build and maintain them together.

For the customer app, a cross-platform build is a sound choice for most teams. It is fast to develop, looks consistent and is good enough in performance for a shopping interface. For the rider app, the same holds unless it needs unusually deep use of device features such as continuous background location, where native code may be needed for parts.

The practical consequence for a buyer is cost and speed. Choosing one framework for the apps typically saves a large amount of effort compared with native development, with trade-offs that few customers will ever notice.

The server: start with one, split when it hurts

The server holds the rules of the business: who can order what, how stock is reserved, how orders move between states. A common mistake is to begin with many small services because that is how large companies are organised. Large companies have large teams, and the separation is a way of letting teams work independently. A small team gets the costs of distribution, such as more deployment, more monitoring and more failure modes, without the benefit.

A single well-structured backend, with clear modules for orders, catalogue, inventory and delivery, is easier to build, test and reason about. When load or team size make a module a bottleneck, it can be pulled out into its own service. Starting that way keeps the option open.

The language and framework matter less than people argue. Mature choices such as Node.js, Python or Go all work well. Choose the one your developers know best and for which you can hire.

The data: a relational database and a cache

Orders, payments and stock need correctness above all. A relational database such as PostgreSQL provides transactions, which means that a set of changes either all happen or none do. When two customers try to buy the last item at the same moment, transactions are what stop both from succeeding.

A cache, typically an in-memory store such as Redis, sits in front for data that is read very often and changes rarely, such as the product catalogue. It makes the app feel fast and takes load off the database.

For search across a large catalogue, a dedicated search engine becomes worthwhile once the simple database search starts to feel slow or misses items because of spelling. It is a good example of something to add when there is evidence, not before.

Real-time: use only what you need

Real-time is attractive and expensive. A lot of what feels real-time in a delivery app is really a few updates at known moments: order accepted, packed, picked up, delivered. Push notifications and a refresh cover these well, and need little infrastructure.

Live tracking on a map is the case that needs continuous updates. It brings location streams from riders, a channel to push them to customers, and a map service billing by use. It is worth it when it moves a business measure, such as fewer 'where is my order' calls. Decide on that basis, and add it after the basics are stable.

A managed real-time service is the sensible start, because running your own connection servers is a skill and an ongoing burden.

Payments and maps: buy, do not build

Neither payments nor maps are worth building. A payment gateway has the licences, the bank connections and the security certification that you would need years to acquire. A mapping service has data you could not collect. Choose providers on reliability, support and what the bill looks like at your expected volume.

It is worth designing the code so that the provider sits behind a small interface of your own. If a provider's pricing changes or an outage forces you to change, the rest of your system should not have to.

Costs scale with use, so model them. A maps charge that looks trivial in testing can become a large monthly figure when thousands of riders and customers are using it every day.

Hosting and operations

For a small team, managed services win: a managed database, a managed container or application platform, a managed queue. You pay more per unit than running your own, and you pay far less in the time and the nights spent on problems.

Put the servers in a region close to your users to keep latency low. Set up basic monitoring and alerts from the first release, so that you find out about a failure before your customers tell you. And have automated backups with a tested restore, because a backup nobody has restored is only a hope.

How the right stack changes with the team

The toggle above shows two profiles. A small team should aim for the fewest moving parts. It is easier to keep a small system healthy, and each added component is something someone must understand, update and fix at night.

A funded team with more engineers can afford more specialisation: a separate service for dispatch, a queue to smooth out spikes, a search engine, read replicas of the database. These are answers to problems that arrive with scale, and a team that adds them before the problem exists is spending its runway on infrastructure.

Changing the stack later

Buyers often fear that an early technology choice is permanent. In practice, most of a stack can be changed, at a cost, and the parts that are hardest to change are the data model and the places where business rules live. A cross-platform framework can be replaced screen by screen. A server written in one language can be rewritten module by module while the old one keeps running. A database is the heaviest piece to move.

This is another reason for restraint early on. Each choice should be one you can live with for the first two years. Do not pay for flexibility you will not use, and do not accept a design that would make a change impossible. A clean separation between the interface, the rules and the data keeps most doors open.

Questions to ask a vendor about their stack

• Why this stack for this product, and what did you consider and reject?
• How many people in your team can maintain it, and what happens if one leaves?
• What will it cost to run each month at my expected volume?
• Which parts are bought services and which are built, and what happens if a provider changes?
• How will we find a developer to take it over if we part ways?