Grocery Delivery App Development: Catalogue, Slots, Riders and Cost

A grocery delivery web app or PWA with weighed items, substitutions, delivery slots, per-store stock, rider assignment, and cash on delivery plus online payments takes roughly 580–890 engineering hours for a first release, by the illustrative breakdown below. Aalpha's June 2026 guide puts market MVP prices at $40,000–$70,000 in Asia and $120,000–$180,000 in the US.

If you would rather have it built for you, see how RAITHub would build this below. One scope note first: RAITHub builds web apps and progressive web apps (PWAs), not native iOS or Android apps.

What does a grocery delivery app actually need to do?

It has to sell things that change weight, run out mid-order, and must reach the door inside a promised window. That is what separates grocery from ordinary ecommerce, and it is where the budget goes.

A first release usually has five audiences, each with its own screens and permissions:

• Shoppers: browse, search, build a basket, pick a delivery slot, pay or choose cash on delivery, and approve or reject substitutions.
• Pickers in the store or dark store (a small warehouse that serves online orders only): a pick list sorted by aisle, actual weights entered, substitutions proposed.
• Riders: assigned orders, the route, proof of delivery and cash collected.
• Store managers: stock, slot capacity, prices and promotions for their location.
• Head office: catalogue, stores, zones, refunds, reports and staff roles.

On "app": a PWA is, in MDN's definition, an app built with web technologies that can be installed on a device and work offline. For shoppers, pickers and riders that covers most of what a grocery operation needs, and it means one codebase instead of three. If you need App Store listings or deep native hardware features, you need a native mobile team, which RAITHub does not offer.

How do you handle items sold by weight?

Price by the unit you actually sell, store quantities as integers, and settle the final amount after picking. A shopper orders "about 1 kg of tomatoes"; the picker weighs 1.08 kg; the bill must follow the scale, within a limit the shopper agreed to.

• Store grams, not kilograms. Integer grams and integer minor currency units (cents, paisa, fils) avoid floating-point rounding errors on every weighed line.
• Show an estimate, charge the actual. Display the estimated line price at checkout and a tolerance (for example, plus or minus 10%) the shopper accepts.
• Authorise, then capture. For card payments, authorise a little above the estimate and capture the real total after picking. Stripe documents this as placing a hold: you can capture less than the authorised amount, the rest is released, and an online card authorisation usually lasts about 7 days, which is plenty for next-day slots.
• Cash on delivery is simpler and messier. The rider collects the final amount, so the rider screen must show the post-pick total, not the checkout estimate.

How should substitutions work?

Ask the shopper's preference per line at checkout, let the picker propose a replacement, and never charge more without consent. Substitutions are the main reason grocery customers complain, so they deserve a small, explicit workflow rather than a free-text note.

Shopper preference	What the picker can do	Billing rule
No substitutes	Mark out of stock	Line removed; refund or reduce capture
Picker's choice	Pick a similar item from a suggested list	Charge the lower of the two prices, or the original price
Approve each one	Propose; shopper approves in the app within a time limit	Charge the approved item; no reply means remove

Suggested replacements can start as a simple rule (same category, same size band, same or lower price) and get smarter later. Every substitution should be logged, because it is also your data on which products run out.

How do delivery slots and capacity work without overbooking?

Each slot is a row with a capacity, and a booking is an atomic database update that only succeeds while there is room. If you check capacity in one step and book in another, two shoppers at 7 p.m. will both get the last slot.

Capacity is really two limits: how many orders the pickers can pack before the slot, and how many drops the riders can make inside it. Start with one number per slot per store and split it later if you need to. Rent-a-feature options exist: on Shopify, the Zapiet Pickup + Delivery app lets higher plans set how many orders each date or time slot takes, from $79.99 a month on the Advanced plan.

In a custom build, PostgreSQL does the hard part. A single conditional UPDATE locks the row, and per the PostgreSQL locking docs other transactions that try to update it wait until the first one ends. The same pattern reserves stock in the right dark store:

-- Book one place in a slot; no row returned means the slot is full.
UPDATE delivery_slot
SET booked = booked + 1
WHERE id = $1
  AND booked < capacity
RETURNING id;

-- Reserve stock at one dark store, in grams or units.
UPDATE store_stock
SET reserved = reserved + $3
WHERE store_id = $1
  AND sku_id = $2
  AND on_hand - reserved >= $3
RETURNING sku_id;

Run both inside the transaction that creates the order, and roll back if either returns no row. The wider pattern is in preventing stock overselling.

How do you manage inventory across dark stores?

Stock belongs to a store, not to a product. The shopper's address picks a zone, the zone picks a store, and the catalogue they see is that store's available stock.

• Per-store stock rows: on hand, reserved, and a safety buffer so the app stops selling the last two units it may not be able to find.
• Batches and expiry for dairy, meat and bakery: allocate earliest expiry first (FEFO) so short-dated stock leaves first.
• Receiving, counts and write-offs as recorded movements, so stock can be explained, not just overwritten.
• Price per store if your locations price differently.

RAITHub has built this kind of stock logic before: Sundor Skin, a B2B wholesale platform built for a client, allocates batch stock earliest expiry first and enforces tier pricing on the server. Stock-system choices for smaller operators are in retail inventory management software for small businesses.

How are riders assigned to orders?

Start with rules a dispatcher can understand, and automate once you have data. For a first release, "nearest free rider at this store, batched by slot" works for most single-city operations.

1. Batch by slot and zone. Orders in the same slot and area go together.
2. Assign to a rider who is checked in at that store, with manual override for the dispatcher.
3. Track status, not continuous GPS, at first: picked up, arrived, delivered, failed. Live location in a PWA is possible while the app is open; background tracking is where native apps or a dedicated dispatch product earn their keep.
4. Proof of delivery: a photo, a one-time code, or a signature.
5. Cash reconciliation for cash on delivery: what each rider collected against what their delivered orders say they should have.

If you already use third-party couriers instead of your own riders, this becomes a courier integration per provider, each with its own failure handling.

Which payments should a grocery app take?

Whatever your shoppers already use, and in many markets that still includes cash on delivery. Build each provider as its own integration, with the weighed-item rule above decided before you start.

• Bangladesh: bKash, Nagad, SSLCommerz and cash on delivery, the same rails TheSkinProof runs. The integration detail is in the bKash and SSLCommerz integration guide.
• UAE and the Gulf: card acquirers and buy-now-pay-later options are covered in GCC checkout with Tabby, Tamara and Checkout.com.
• India and elsewhere: choose a local gateway that supports separate authorisation and capture, or plan to refund the difference after picking.

Payment rules can carry legal and tax obligations, including how you show weighed prices and handle refunds. This is general information; confirm with your adviser.

How much does grocery delivery app development cost, line by line?

The table below is an illustrative estimate of engineering hours for a single-city, web and PWA first release. It is not a RAITHub quote, and your scope will move it.

Line item	Illustrative hours	What moves it
Catalogue, categories, weighed and unit items	60–90	Number of SKUs, variants, import from your POS or ERP
Search and filters	30–50	Typo tolerance, synonyms, more than one language
Basket, checkout, one online gateway plus cash on delivery	80–120	Each extra gateway; authorise-and-capture for weighed items
Delivery zones, slots and capacity	40–60	Split picker and rider capacity; express versus scheduled
Per-store stock, reservations, batches	60–90	Number of dark stores; expiry tracking; stock counts
Substitutions workflow	40–60	Live shopper approval versus rules only
Picker PWA	50–80	Barcode scanning, scales, aisle ordering
Rider assignment, status and cash reconciliation	60–100	Own riders versus third-party couriers; live tracking
Store and head-office admin, roles, refunds	60–90	Number of roles and approval steps
Notifications (SMS, email, web push)	20–30	Providers and languages
Automated tests, CI, deployment	80–120	Spread through the build, not added at the end
Total	580–890	Illustrative only

Multiply by your shortlisted team's rate to sanity-check quotes. For market comparison, Aalpha's guide puts a multi-store marketplace at $80,000–$150,000 in Asia and $200,000–$350,000 in the US, and suggests budgeting 15–20% of the build cost each year for maintenance. Those guide figures include native apps, which a web and PWA scope does not need. To test your own feature list, try the MVP cost estimator.

Buy, build or hire?

Option	Example	Choose this when	Watch out for
Off-the-shelf store	Shopify, from $19 a month (Basic, billed yearly) to $299 (Advanced), Plus from $2,300	One store, mostly unit-priced goods, you want to test demand this month	Weighed items, substitutions and per-store stock rely on apps and workarounds
Store plus apps	Shopify plus Zapiet for slots, from $44.99 to $152.99 a month billed annually	You need delivery dates and slot limits but not your own rider fleet	Several apps that each own part of the order; harder to change the rules later
Custom build	A web app and PWAs on your own stack	Dark stores, own riders, weighed items, cash on delivery or local gateways are the business	Needs a written spec, a test suite and someone to run it after launch

The broader trade-off is in Shopify vs custom ecommerce, and the full ecommerce picture is in the pillar guide, building a marketplace or B2B store.

Can I build a grocery delivery app myself?

A capable full-stack developer can build a single-store version in about 3–5 months of focused work, using the hours above as a guide. The main risk is not the screens; it is money and stock under load: double-booked slots, oversold items and weighed totals that do not match what the card was charged. Write tests for those three before anything else.

Why RAITHub for this

• The commerce rules are things we have shipped. TheSkinProof, the founder's own marketplace venture that RAITHub builds and runs, takes bKash, Nagad, SSLCommerz and cash on delivery across 5 portals and 217 API endpoints, with 750+ automated tests. It is the founder's venture, not a client, so weigh it as engineering evidence.
• Stock and pricing on the server. Sundor Skin, built for a client, has FEFO batch allocation, tier pricing and 530+ automated tests.
• Hours that suit Gulf and South Asian operators. Dubai shares 7 working hours with Dhaka; India is 30 minutes behind Dhaka.
• QA-first. Slot, stock and payment rules are covered by tests gated in CI, so a change that breaks them does not merge.

When you don't need us

• You run one shop, sell mostly packaged goods and want to test demand: a hosted store plus a delivery-slot app is faster and cheaper to start.
• You need native iOS and Android apps in the stores: RAITHub does not build those.
• You want developers placed inside your team under your management: RAITHub does fixed-scope builds and dedicated teams, not staff augmentation.
• You need the operation run for you: riders, merchandising and customer service are yours.

How RAITHub would build this

• Scope: one city, one or two dark stores; catalogue with weighed and unit items; slots with capacity; per-store stock with reservations; one online gateway plus cash on delivery.
• Operations: picker and rider PWAs with substitutions, proof of delivery and cash reconciliation.
• Admin: store and head-office roles, refunds and basic reports.
• Later phases: more stores and zones, smarter rider batching, extra gateways.

Timeline: a fixed-scope first release in 4–6 weeks through MVP development; adding stores, gateways and dispatch logic behind it is backend work at 6–12 weeks. You receive: automated tests and CI, handover docs and runbooks, and full IP under NDA. See the ecommerce service page and past work.

Next step: a free 15-minute technical audit, then a written fixed quote. Book the audit with your city, number of stores and how shoppers pay.

Frequently asked questions

How much does it cost to build a grocery delivery app?

Aalpha's June 2026 guide puts an MVP at $40,000–$70,000 with an Asian team and $120,000–$180,000 in the US. Our illustrative web and PWA breakdown is 580–890 engineering hours for a single-city first release. RAITHub quotes in writing after a free audit.

Does RAITHub build native grocery apps for iOS and Android?

No. RAITHub builds web apps and installable PWAs for shoppers, pickers and riders. If you need App Store listings or background GPS tracking, you need a native mobile team.

How do grocery apps charge for items sold by weight?

They show an estimate at checkout, weigh at picking, and charge the actual amount within an agreed tolerance. With cards, a common pattern is to authorise slightly above the estimate and capture the real total later.

How do you stop delivery slots being overbooked?

Store a capacity per slot and book with one conditional database update that only succeeds while booked is below capacity. Doing the check and the booking as separate steps lets two shoppers take the last place.

Can a grocery app support cash on delivery and online payment together?

Yes. Each method is its own integration. Cash on delivery adds rider cash collection and a daily reconciliation of what each rider collected against their delivered orders.

How long does it take to build a grocery delivery web app?

A tightly scoped first release for one city takes about 4–6 weeks at fixed scope. Multi-store stock, more gateways and rider batching usually follow as a 6–12 week backend phase.