What to Build for Grocery and Food Delivery Businesses

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: Founder or COO of a regional grocery or meal-delivery business doing $2M–$20M in annual GMV who has outgrown DoorDash Drive or a Shopify-plus-plugin stack and is deciding which custom systems are worth building versus which SaaS tools to keep

If you run a regional grocery or meal-delivery business between $2M and $20M GMV, the three systems worth building in-house are, in order: a rules-based substitution engine that learns from customer history, a picker routing and batching system tied to your actual store or dark-store layout, and a driver-pay and settlement ledger that reconciles automatically against orders, tips, and adjustments. Everything else — storefront, payments, SMS, maps — keep buying. The margin is hiding in the operational middle, not the consumer app.

Most founders at this stage are stuck because every vendor demo opens with a shiny customer app. That is the cheapest piece to replace and the least differentiated. The expensive problems sit in the warehouse, in the car, and in your finance team's spreadsheet on Friday afternoon.

The three problems that are actually bleeding you

1. Out-of-stock substitutions eat 8–14% of basket value

This is the biggest and least-discussed line item. Upshop's analysis of 21 million orders found average lost revenue per order from out-of-stocks at $8.44, with four exception items per order on average. Grocery stockout rates run 7–10% globally, higher in fresh and dairy. And when the stockout hits an anchor item, 43% of retailers lose the entire basket, not just the line.

The fix is not better inventory counts (you will never get them perfect on fresh). The fix is substitution policy as code. A Journal of Retailing study found acceptance of substitutions rose from 66% to 75% when retailers moved from random to personalized substitutions based on purchase history — and to 84% when the substitute matched something the customer had bought before.

Every off-the-shelf platform treats substitution as a customer-service event: picker texts customer, customer replies in 11 minutes, picker has moved on, order is delayed, half the time it ends in a refund. That workflow is the single most expensive thing in your operation and no SaaS vendor will fix it, because fixing it requires access to your customer purchase history, your supplier catalog, your margin data, and your picker app — four systems no single vendor owns.

2. Picker travel time is 55% of fulfillment cost

In published warehouse research, travel accounts for roughly 55% of total picking time, and route and slotting optimization can cut travel distance by up to 30%. In a grocery context — store-pick or dark-store — this shows up as pickers walking the aisle in SKU-ID order instead of aisle order, or picking one order at a time instead of batching three compatible orders on one trip.

If your average pick currently takes 22 minutes and you can get it to 15, you have just increased picker throughput by 46% without hiring anyone. For a 400-order day that is roughly 47 picker-hours recovered. That math is why Instacart and Amazon Fresh invested so heavily in picker software and why nobody will sell you theirs.

3. Driver-pay reconciliation is a two-day finance task

Ask your head of finance how long payroll takes for drivers. The honest answer, at this scale, is usually one to two days a week — reconciling trip logs against tips, against adjustments, against fuel reimbursement, against the 11 refunds issued on Tuesday that nobody told payroll about. This is not a software problem anyone has sold your industry well, because the pay rules are different in every market and every business.

It is also the easiest of the three to automate, because the inputs are already digital. You just do not have one place where orders, GPS logs, tips, refunds, and pay rules meet.

What to build, in what order

Build #1: The substitution engine (first, always)

This is where the money is. The system you are building has four parts:

• A customer preference layer: for every SKU a customer has ever ordered, what have they accepted as a substitute, and what have they rejected or refunded? This is a simple append-only log. You already have the data; you are just not using it.
• A catalog similarity graph: for every SKU, an ordered list of acceptable substitutes based on category, pack size, brand tier, and margin. Built once, maintained by category managers in a spreadsheet that syncs nightly.
• A decision engine: at pick time, if the SKU is out, the picker app shows the top-ranked substitute the customer is most likely to accept, pre-approved under policy. No SMS, no wait. Customer gets a notification: “We swapped X for Y, tap here if that's wrong.”
• A feedback loop: refund rate per substitution feeds back into the preference layer so the system gets better each week.

What changes once it exists: substitution acceptance climbs from the industry baseline of around two-thirds to the mid-80s. Refund rate on substituted items drops roughly in half. Picker time per exception drops from 11 minutes (waiting for customer reply) to under 30 seconds. On a $5M GMV business losing 10% to substitution issues, recovering half of that is $250k of margin a year.

What it is bad at: cold start. For the first 90 days on a new customer you have no history, so you fall back to catalog similarity and margin rules. Also useless if your catalog data is garbage — garbage in, confidently wrong substitutions out.

Build #2: Picker routing and batching

Second priority because it compounds the first. Once substitution is handled automatically, picker time becomes the next bottleneck.

What you are building:

• Store or dark-store map as data: aisles, bays, zones with x/y coordinates. One-time setup per location, roughly a week per store.
• SKU-to-location mapping, kept current. Not perfect — current.
• A batching algorithm that groups 2–4 compatible orders (overlapping SKUs, same delivery window, same zone) and generates a single pick path.
• A picker app that shows the next item, the shortest path to it, and the substitute flow from Build #1.

What changes: picks per hour go up 30–50% in most operations. Order accuracy goes up because pickers aren't backtracking and losing their place. Driver wait time at the store drops, which cascades into delivery SLA.

What it is bad at: it assumes your store layout is reasonably stable and your SKU locations are maintained. In a chaotic store where aisles are reshuffled weekly, the model breaks. You end up needing a lightweight “flag this item as moved” workflow in the picker app, which is annoying but essential.

Build #3: Driver settlement ledger

Third because the business doesn't break if you do this in a spreadsheet. But recovering two finance-person days per week, plus eliminating driver disputes (which are a retention killer), is worth real money.

What you are building:

• A single ledger that ingests: completed trips, GPS-verified distance, tips (from the storefront), refunds and adjustments (from CS), fuel or vehicle reimbursement rules, and bonus/incentive rules.
• A pay-rule engine configurable per market — because Mumbai, Dubai, and Chicago don't pay drivers the same way.
• A driver-facing earnings view that shows expected pay in real time. This single feature cuts support tickets more than anything else you will build.
• Export to whatever payroll system you already use. Do not build payroll.

What changes: finance closes driver pay in 2 hours instead of 2 days. Driver disputes drop sharply because they can see their own math. You also get, almost for free, a cost-per-delivery number by zone, by daypart, by driver — which is the data you need to make the next round of operational decisions.

What NOT to build (keep buying this)

• Consumer storefront and app: Shopify, Swiggy-style white-label, or a thin custom front-end on top of your own APIs. The storefront is not where you win. Build custom only when you have genuinely differentiated UX (meal planning, subscription-first, B2B catalog) that off-the-shelf cannot do.
• Payments: Stripe, Razorpay, Checkout.com. Never build.
• Maps and ETA: Google, Mapbox, or HERE. The last-mile ETA accuracy problem is real but is solved by better driver dispatch logic, not by building your own map.
• SMS and notifications: Twilio, MessageBird. Never build.
• Warehouse management (if you're under 5 dark stores): a lightweight SaaS WMS is fine until you hit scale. The picker app from Build #2 does most of what you need.
• Last-mile dispatch (early on): DoorDash Drive, Shipday, Onfleet. Switch to custom dispatch only when driver-pay-plus-platform-fee exceeds roughly 18% of order value consistently, which usually happens around $8–10M GMV.

What this costs and how long it takes

Honest answer: the range is wide, and anyone quoting you a number before scoping is guessing. What drives the number, in order of impact:

• How clean your catalog and purchase-history data is. A business with 18 months of structured order history in Postgres will get Build #1 live in a fraction of the time of a business whose orders live in a mix of Shopify, WhatsApp, and a POS export.
• How many stores or dark stores you need to onboard. One location is a pilot. Fifteen locations is a rollout program.
• Whether you have an in-house tech team to own it after launch. If not, you are also buying a support model, not just a build.
• How much of the picker and driver workflow is already digital. If your pickers currently use paper, Build #2 includes a change-management project, not just software.

As an illustrative shape (not a quote): a focused substitution-engine build for a single-brand grocery operator with clean order history and one storefront integration is a smaller engagement — a few months to a working v1, measured in weeks of a small cross-functional team. The picker system is typically a longer build because it touches physical operations and requires on-site time. The settlement ledger is the fastest of the three to ship but the slowest to tune, because every edge case in driver pay surfaces only in production.

To turn any of that into a real number you'd need to pin down: how many locations and in which markets, what your current data stack looks like, and whether you want this built as owned software (you keep the IP and run it) or as a managed build. Those three answers move the number by 3–5x. A scoping conversation — which is what CodeNicely and most serious digital transformation partners start with — is where that happens.

How to sequence it over 12 months

If you are starting from a Shopify-plus-plugin or DoorDash-Drive stack today:

1. Months 1–2: Audit. Pull 90 days of order data. Measure your actual substitution refund rate, your pick time per order, and your finance hours per week on driver pay. You cannot prioritize without these three numbers.
2. Months 2–5: Build the substitution engine. Launch in one store or one zone. Measure acceptance rate weekly.
3. Months 5–9: Build picker routing on top. Reuse the picker app shell. Roll out store by store, not all at once.
4. Months 8–12: Build the settlement ledger in parallel — it has no dependency on the first two. Get finance back their week.
5. Month 12+: Only now consider replacing dispatch, storefront, or WMS. By this point you have real operational data to decide whether custom is justified.

The sequencing matters because each build makes the next one easier. The substitution engine forces you to clean catalog data, which the picker system needs. The picker system generates the trip-level data that makes settlement accurate. Reverse the order and you spend twice as long for half the result.

The U.S. eGrocery market hit $12.7 billion in December 2025, up 32% year-over-year, and delivery was 36% up year-over-year in July 2025. The volume is there. The operators who win the next three years are the ones whose unit economics work at that volume — and unit economics are decided by the three systems above, not by the color of the app icon.

Frequently Asked Questions

Should I build my own delivery driver app or use Onfleet / Shipday?

Use Onfleet or Shipday until the combined fee plus the operational limitations cost you more than running your own dispatch stack — which for most operators happens somewhere between $8M and $15M in annual GMV. Before that threshold, custom dispatch is a distraction. After it, the control over driver assignment logic, pay rules, and SLA tuning starts to pay back.

What is the ROI of a custom substitution engine vs. just hiring better pickers?

Better pickers help with accuracy but can't solve the structural problem: the customer isn't available to answer the SMS in time. The research is clear that personalized substitution policies lift acceptance from ~66% to the mid-80s, and lost revenue per order from stockouts averages $8.44. On a 300-order-per-day operation, recovering even half of that is roughly $460k a year — a number that justifies the build for almost anyone over $3M GMV.

How much does custom grocery delivery software cost to build?

The honest answer is that it depends almost entirely on scope: one engine for one brand with clean data is a different project from a multi-store, multi-market platform. The three variables that move the number most are number of locations, data readiness, and whether you want owned software or a managed service. A proper scoping call — where someone looks at your current stack, order volume, and operational pain — is the only way to turn a range into a number worth planning around.

Can I buy a white-label grocery platform instead of building?

Yes, for the storefront and basic order management. No, for the three systems that actually move margin — substitution logic, picker routing, and driver settlement — because those depend on your customer data, your store layout, and your pay rules, which no white-label vendor can model well. A hybrid approach (white-label storefront, custom operational backend) is usually the right answer at this stage.

How long before I see ROI on a custom build?

The substitution engine typically shows measurable refund-rate improvement within the first 60 days of being live in a store, because the feedback loop is fast and the baseline is bad. Picker routing shows up in throughput numbers within one to two months of rollout per store. Driver settlement ROI is immediate — the finance hours saved start the week you cut over. Full payback on a focused build is usually inside 12 months for operators above $3M GMV, longer below that.