Grocery delivery app development: apps, features, cost, and steps

A complete grocery delivery system has three apps (customer, picker, and courier) and an admin panel on one backend. Picking and delivery can share one app, and a retailer can also start with the customer app alone. Our price for such a system for one retailer starts from $40,000, and the work takes from 8 weeks. Four problems specific to groceries shape the backend: stock that shifts during the day, substitutions, items sold by weight, and delivery slots.

This guide is for retailers and founders who are planning a grocery app and want to know what goes into it before they ask for quotes. For the service side of this work, see our logistics software development page.

What a grocery delivery app includes

The complete system has four parts on one shared backend: a customer app, a picker app, a courier app, and an admin panel. Customers order, staff pick and deliver, and managers run the catalog, the slots, and the exceptions. Not every service needs all four from day one. Some teams merge picking and delivery into one app when the same person does both, and a retailer whose delivery already runs on its own backend can begin with the customer app only. The backend holds the order, the stock, and the payment, and every app reads from it, so the list of roles defines the scope better than a list of screens.

• Customer app: browse the catalog, build a basket, choose a delivery slot, set rules for substitutions, pay, and track the order.
• Picker app: an in-store shopper or a warehouse worker gets the order, scans each item, marks what is missing, and proposes replacements.
• Courier app: the driver gets the route, updates the status at each stop, and confirms the handoff.
• Admin panel: the store team manages products, prices, stock, delivery zones, slot capacity, refunds, and promo codes.

Pick the business model before the features

The business model sets who owns the stock and who picks the order, and those two answers shape a large part of the backend. Choose one model for the launch. A hybrid can come later, once real orders show which parts of the service people use.

A marketplace is a different product from a store app, even when the customer screens look the same. If that is your plan, our marketplace development page covers the partner side.

What makes grocery delivery harder than food delivery

A restaurant order is short, priced up front, and cooked to order. A grocery basket is longer, comes from shelves that change during the day, and is sometimes priced only after the picker weighs it. Four problems follow, and each one needs its own logic in the backend. If you have read our guide to food delivery app development, this is the part that is different.

Stock that changes during the day

The app shows what the store had at the last sync. Shelf stock may have changed since. So the first design question is where stock and prices live: in the store's point-of-sale system, an inventory system, or an ERP. The app then reads from that system through an API or a scheduled export, and the team agrees how often. Two extra rules narrow the gap between the app and the shelf. Hide an item when its stock falls below a set level, and send every out-of-stock mark from a picker back to the catalog at once. Our article on logistics API integration explains how to decide which system owns which record.

Substitutions

Some items in a basket will be missing when the picker gets to the shelf. The customer should decide what happens before that moment. At checkout, each item gets a rule: replace with a similar product, replace with a specific product, or refund. When an item is missing, the picker app sends the proposed replacement to the customer, waits a set time for an answer, and then applies the rule. The final charge reflects the refund or the price difference. A higher price can be charged only within the limits of the payment method, and the next section, on items sold by weight, explains those limits.

“I treat substitutions as a data problem, not a chat feature. Every approved or rejected replacement tells you something about that customer and that product. If the system keeps those answers, the next proposal gets better, and the picker spends less time waiting on a phone.”

Evgeny Leonov, CTO at Ronas IT

Items sold by weight

The price of fruit, vegetables, meat, and cheese sold by weight is known only after the picker weighs them, so the final charge differs from the basket total. The store can hold an amount on the card at checkout and charge the final amount after picking. The payment provider has to support this. Stripe's documentation says you can capture less than the held amount and the rest is released automatically, while capturing more works only for certain online card payments. So set the hold at the highest total the order can reach after weighing, not at the basket total. Stripe also lists a 7-day authorization window for online card payments that the customer starts. For an order booked more than a week ahead, one option is an extended hold, which is available only for eligible payments. The other is a hold placed closer to the delivery slot on a card the customer agreed to save for later charges. That later hold is a merchant-initiated payment, and Visa gives such payments a shorter window.

Delivery slots

A delivery slot is a promise of capacity: enough pickers and couriers in one zone for one time window. The admin panel sets that capacity per zone and per slot, the slot closes when it is full, and a cut-off time leaves the pickers enough time to collect the order. The customer app shows only the slots the team can meet.

A related system we built: Hamperapp

Hamperapp is a Florida laundry and dry cleaning service. It is not a grocery business, but its order flow follows similar steps. A customer places an order, a driver picks up the laundry, the order can change after it is placed, and a driver brings the laundry back. We found four types of users in the workflow and built a separate interface for each: customers, drivers, managers, and administrators.

• Orders that change after checkout: managers can edit an order, for example add items the customer forgot or change the delivery schedule, and charge the payment.
• Live updates for drivers: we used Ably so drivers see new orders in real time, and Stripe for online payments.
• Routes: drivers who did not know the area got lost and wasted fuel, so we built route optimization with Mapbox tools.
• Stack: Laravel for the backend and Angular for the web app and the admin panel. The Hamperapp team chose native mobile apps, so we built them in Swift and Kotlin.

When the case was written, Hamperapp worked with almost 80 laundries in its area and served households and businesses. A grocery version of this system needs four parts the case does not show: a large catalog with live stock, substitutions, pricing by weight, and a capacity limit for each delivery slot.

“They have a high bar for development and our platform is very stable.”

Jorge Rodriguez, Co-founder of Hamperapp, in a review on Clutch, where the company is listed as Laundry App

The tech stack we would use for a grocery delivery app

Our default for a grocery build is one codebase for the mobile apps and one backend that every app reads from. We would write the customer, picker, and courier apps in React Native with Expo, so iOS and Android ship from the same code.

• Mobile apps: React Native with Expo, and react-native-maps for the courier map.
• Admin panel: Laravel Backpack by default, or Laravel Nova; a custom React panel only if the store needs screens they cannot give.
• Backend: Laravel with PostgreSQL, and Redis for caching.
• Payments: a provider with separate authorization and capture, because the card hold for items sold by weight depends on it.
• Catalog search: Elasticsearch, so shoppers find products by partial names and typos.
• Live order status: Laravel Reverb, the WebSocket server from the Laravel team, with Laravel Echo, so the customer sees each step without refreshing.
• Error tracking: Sentry in production, so crashes in the picker app surface before the store team reports them.

How much does grocery app development cost?

The cost depends on how many apps you launch with and whether you sell from your own stores or from many. The table shows our starting prices for each scope. Each one includes design, project management, testing, and the integrations the scope needs.

If you need only a web store, without picker and courier apps, we can build an online store from $6,000, with a timeline from 3 weeks. We build it on Shopify or another e-commerce platform or on our own backend, and choose between them inside the project: a ready platform suits you only if it handles the grocery problems described earlier.

Four things change the price of a project. The first is the number of apps and roles, because each role has its own set of flows. The inventory integration is another: an old point-of-sale system with no API costs more to connect than a modern one. The substitution and weighted-item logic adds cost because it touches the catalog, the picker app, and the payment step at once. For a marketplace, the partner systems from the model table add to the cost.

“The first version I recommend is one store, one delivery zone, and substitutions done well. Customers forgive a short catalog. They do not forgive a basket that arrives with the wrong items and a charge they did not expect. Add stores and zones once the first one runs without the team watching every order.”

Roman Surikov, CEO at Ronas IT

How to build a grocery delivery app, step by step

Follow the order below: the business model, the user flows, and the stock source come before the design, and a test in one real store comes before the public release. The stock source comes early because the design depends on it.

1. Choose the model and the first zone. The business owner decides between an app for their own stores, a marketplace, or a dark store, and names the area for the launch.
2. Map the roles and their user flows. The product team writes one flow per role before any design starts. On Hamperapp, user flows and wireframes for each user type came before the visual design.
3. Connect the stock source. The developers agree with the inventory vendor which system owns stock and prices, how the app reads them, and how often.
4. Design around substitutions and slots. The designers build the checkout, the picker queue, and the slot picker around the substitution and capacity rules described earlier.
5. Build in short sprints. Each sprint usually lasts one to three weeks and closes with something you can open yourself, such as a new build on the dev server, a screen to test, or fresh mockups.
6. Test in one store. Real pickers use the picker app on real orders before the public release, because work in a real store shows problems that a test script misses.
7. Release and expand. The apps go to the App Store and Google Play, and the store team adds zones and stores after the first zone works as planned.

What to do next

Before you ask for quotes, write down your answers to the first three steps: the model and the first zone, the roles and their flows, and the system that holds your stock and prices. Then take the three actions below.

1. Ask your inventory vendor two questions. Can the system send data by API or by scheduled export, and can you get test access now?
2. Set your substitution rule and your payment rule for weighted items. Before the design starts, choose the default replacement and set the card hold to cover the most the order can cost after weighing.
3. Decide which scope you need. The choice is a customer app for a service you already run, a full system, a marketplace, or a web store alone.

With those answers, a quote describes your service instead of a generic grocery app.

Tell us your model, your stores, and the system that holds your stock, and we will come back with a scope and an estimate.

Get an estimate