How to Build a Grocery Delivery App Like Tesco: Features, Cost & Process

Tesco takes millions of online grocery orders a month, and the app its customers tap is the least interesting part of how. The real machine is underneath: delivery slots priced and balanced days in advance, pickers walking optimized store routes with barcode scanners, a substitutions system that decides what happens when your yogurt is out of stock, and loyalty pricing that keeps baskets big enough to make thin grocery margins work. We build delivery platforms for a living, and grocery is the category where founders most often bring us a food-delivery mental model that the economics then dismantle. This guide is the corrective: what a grocery delivery app like Tesco actually consists of, what it costs in 2026, and where the money and the failures really live.

Quick Answer

What it takes: three coordinated apps (customer, picker/driver, admin), a catalog and search layer built for tens of thousands of SKUs, slot-based fulfillment, and a substitutions workflow that customers actually trust.

What it costs: $40K to $80K for a single-store custom MVP, $80K to $150K for a multi-store platform, $150K to $250K+ with slot optimization and loyalty. The white-label route lands at roughly $5K to $25K and ships in weeks.

The part nobody budgets: catalog onboarding, substitution UX, and unit economics. The code is the predictable half.

Key Takeaways

• Grocery is not food delivery with more items; slot booking, picking, and substitutions make it a different product.
• Plan for three apps and an admin panel, not one app.
• Search across a 40,000-SKU catalog needs Elasticsearch-class infrastructure, not SQL LIKE queries.
• Substitutions are the top complaint driver in the entire category; design that flow first.
• Slot pricing is both revenue and operations: peak pricing smooths demand while it earns.
• Retail media (brands paying for placement) is the quiet high-margin layer the big players monetize hard.
• White-label gets you operating in weeks; custom earns its cost once your operating model proves genuinely different.

Quick Facts

Why Grocery Is Its Own Category

Food delivery moves one hot bag from a restaurant to a door inside an hour. Grocery moves forty-plus items per order, picked from a catalog of forty or fifty thousand products, some frozen, some fragile, some out of stock since the morning, to a customer who booked Thursday between 6 and 7pm three days ago. Every difference that matters flows from that contrast.

Slots replace on-demand. Customers plan grocery shopping, so Tesco-style apps sell delivery windows and click-and-collect pickups rather than promising thirty minutes. That changes everything downstream: demand becomes schedulable, vans batch multiple orders per route, and slot pricing becomes a lever for both revenue and load balancing.

Picking replaces handoff. A restaurant hands over a finished bag; a grocery order has to be assembled by someone walking a store or warehouse with a scanner, which means pick-route optimization, barcode verification, and the moment that defines the whole customer relationship: what happens when an item is missing. Substitution preferences, picker prompts, and refund-without-friction flows are where grocery apps are actually won and lost, and they have no equivalent in food delivery.

And margins rule everything. Grocery retail runs on single-digit margins, so a picking route that wastes four minutes per order or a van schedule that averages too few drops per hour does not show up as a bug; it shows up as a business that loses money per order at scale. The delivery-logistics math shares DNA with ride-hailing economics, which we broke down in our guide to what it costs to build an app like Uber, but grocery adds inventory and picking on top.

The Three-App Architecture

Founders picture one app. A Tesco-style platform is at minimum three, plus the panel that runs them.

The customer app

• Catalog and search. Fast search with typo tolerance, filters, and category browsing across tens of thousands of SKUs. This is infrastructure, not a search box.
• Persistent basket and lists. Grocery baskets build over days. Favorites, saved lists, and one-tap reorder from history carry the habitual weekly shop.
• Slot booking. Delivery windows and click-and-collect with live availability and differential pricing by slot.
• Substitution preferences. Per-item and global controls: allow substitutes, pick my rules, or refund instead. Getting this right up front prevents the category's worst complaints.
• Loyalty. Clubcard taught the industry that member pricing changes basket behavior; points, member prices, and personalized offers belong in v1, not v3.
• Payments and wallets. Cards, wallets, and payment on amendment, since grocery orders change between checkout and picking (weight-based items, substitutions, out of stocks).
• Live order tracking. Picking started, on the way, arriving, with substitution approvals in the moment where operators support it.

The picker and driver apps

• Picker app. Orders sequenced into an efficient store or warehouse route, barcode scan verification per item, substitution prompts with photos, weight capture for loose goods, and tote management for chilled and frozen separation.
• Driver app. Batched multi-drop routes, navigation, proof of delivery, age-verification capture for restricted items, and failed-delivery handling.

The admin panel

• Catalog and pricing. SKU management, promotions, multibuy offers, and price synchronization with store systems.
• Slot and capacity management. How many orders each window can absorb per store, per van, per picker shift.
• Order operations. Amendments, refunds, complaint handling, substitution-rate monitoring.
• Analytics. Basket size, slot utilization, pick rate per hour, substitution acceptance, delivery cost per order: the numbers that decide whether the operation makes money.

The Tech Stack We Build On

React Native or Flutter carries the customer, picker, and driver apps from shared codebases, which keeps three apps affordable. Node.js runs the backend, PostgreSQL holds orders, inventory, and customers, and Redis handles baskets and sessions. The one piece newcomers underestimate is search: at grocery SKU counts, catalog search needs Elasticsearch or OpenSearch with synonyms and typo tolerance, because a customer who searches "bog roll" and gets nothing does not try again, they open the other app. Maps and routing services handle van batching. None of this is exotic, and that is the point; grocery is won on workflow design and operations, not on novel technology. Where AI does enter, and increasingly through agent standards, our guide to MCP for ecommerce covers how conversational shopping agents are starting to plug into catalogs like this one.

What It Costs in 2026

Two budget lines that surprise people. Catalog onboarding, meaning product data, images, categories, and price feeds for tens of thousands of SKUs, can consume as much calendar time as the software if the source data is messy, and it usually is. And post-launch, plan for 15 to 20 percent of build cost annually in maintenance, plus the operational tooling requests that only surface once real pickers and drivers use the apps daily. For how these numbers sit inside wider product budgeting, our breakdown of real SaaS MVP costs is the companion piece.

How the Build Actually Proceeds

The sequence we run: scope the operating model first, because in-store picking versus dark store, one town versus one region, and owned vans versus gig drivers change the software more than any feature request. Then design the substitution and slot flows before anything else, since they carry the customer experience. Catalog infrastructure comes next (import pipeline, search, categorization), because everything else renders on top of it. Then the customer app, the picker and driver apps against real workflows walked in a real store, payments including amendment charging, and the admin panel. Test with a friendly store doing real orders for two weeks before public launch; every team that skips the pilot ships a picker app that fights how picking actually works. Launch narrow, one store or one postcode area, prove the drop density, and expand along the map, not ahead of it.

How the Money Works

Grocery delivery monetizes through a stack, and the operators who thrive pull every lever. Delivery fees priced by slot come first, with peak windows costing more and quiet windows discounted, which earns revenue and flattens the demand curve in the same motion. A delivery-pass subscription (the Tesco Delivery Saver pattern) converts weekly shoppers into locked-in customers whose basket frequency rises once delivery feels free. Loyalty pricing grows baskets, and basket size is the single strongest lever over per-order economics. Substitution and weight adjustments, charged accurately at amendment, protect margin quietly. And retail media, meaning brands paying for search placement, category banners, and sponsored products, is the high-margin layer that has become a serious profit center for every large grocery platform; the infrastructure for it belongs in the advanced tier of any build plan.

Where Grocery Apps Actually Fail

Having watched launches succeed and stall, the failure points are consistent. Inventory accuracy kills trust fastest: showing in-stock items that are not on the shelf produces substitution rates that no UX can apologize for, so the stock-feed integration deserves senior engineering attention. Substitution experience is the top complaint driver in the category, and it is a design problem more than a technical one. Unit economics fail silently, where an inefficient pick route or low drop density loses a little money on every order until the totals arrive. Cold chain is a compliance and quality obligation (chilled and frozen separation through totes, timing, and van zones) that cannot be retrofitted. And expanding ahead of density, launching city-wide when the van math only works in three postcodes, is the classic self-inflicted wound. Start narrow, measure drops per hour, and let the map earn its expansion.

Build Custom or Deploy White-Label?

The honest framing we give founders: the grocery platform itself is a solved problem, and the same architecture described above runs behind every serious operator. Custom development earns its price when your operating model genuinely differs, and you learn whether it does by operating. That is why the sequence that works for most founders is white-label first: deploy the proven platform under your brand in weeks, run real orders, find out where your model actually diverges, then invest custom engineering there and only there. It is the same logic behind our Uber clone in ride-hailing, applied to a category with better repeat-purchase behavior.

Why Founders Build With Make An App Like

Make An App Like has shipped 500+ apps for founders and operators in 40+ countries since 2016, including delivery and on-demand platforms, and has been featured by TechCrunch as a leading partner for non-technical founders. The guidance above comes from building and operating these systems, including the picker workflows and substitution flows that only look simple until a real store runs them.

Estimate Your Grocery App Build

Want a line-item budget for your grocery delivery platform, custom or white-label? Use our free calculator: https://makeanapplike.com/tools/app-cost-calculator

Launch Faster With a Ready-Made Foundation

Skip months of build time with a white-label grocery delivery platform, live in weeks under your brand: https://makeanapplike.com/buy-white-label-apps

Conclusion

A grocery delivery app like Tesco is three apps, a serious catalog, and an operating discipline wearing a shopping interface. The software is well understood: slot-based fulfillment, picking with substitutions, loyalty, and an admin layer that watches the economics in real time. The judgment calls are where founders earn their outcome: design the substitution flow like it is the product (it is), keep inventory honest, price slots to shape demand, launch narrow enough for the van math to work, and choose white-label speed or custom control based on how your operating model actually differs rather than how it feels. Groceries are the most repeatable purchase in commerce; build the machine right and the habit does your marketing.

Frequently Asked Questions

1. How much does it cost to build a grocery delivery app like Tesco?

A custom build runs $40,000 to $80,000 for a solid single-store MVP, $80,000 to $150,000 for a multi-store platform with picker and driver apps, and $150,000 to $250,000 or more for an advanced platform with slot optimization, substitutions intelligence, and loyalty. The white-label route compresses upfront cost to roughly $5,000 to $25,000 and ships in weeks instead of months.

2. What makes a grocery delivery app different from a food delivery app?

Almost everything below the surface. Food delivery moves one hot bag from a restaurant within the hour. Grocery moves 40-plus items per order, picked from tens of thousands of SKUs, with out-of-stock substitutions, chilled and frozen handling, and customers who book delivery slots days ahead. The picking workflow and the substitution experience are the product in grocery.

3. What features does a Tesco-style grocery app need?

Customer side: catalog search across tens of thousands of products, a persistent basket, delivery-slot booking with click-and-collect, substitution preferences, loyalty integration, and reorder from history. Operations side: a picker app with barcode scanning and substitution prompts, a driver app with route batching, and an admin panel covering catalog, pricing, promotions, slots, and refunds.

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

A custom single-store MVP takes four to six months, and a multi-store platform with picker and driver apps runs six to nine. White-label deployment lands in two to six weeks because the platform exists and the work is branding, catalog import, and configuration. Catalog onboarding is the timeline item most founders underestimate.

5. What tech stack should a grocery delivery app use?

React Native or Flutter for the customer, picker, and driver apps from shared codebases, Node.js for the backend, PostgreSQL for orders and inventory, Elasticsearch or OpenSearch for catalog search, Redis for baskets, and a maps and routing service for delivery batching. Grocery is won on workflow design and operations rather than novel technology.

6. How do grocery delivery apps make money when margins are so thin?

Through stacked levers: delivery fees priced by slot (which also smooths demand), a delivery-pass subscription that locks in weekly shoppers, loyalty pricing that grows baskets, accurate amendment charging on substitutions and weighed items, and retail media, where brands pay for placement in search and category pages at margins the groceries themselves never see.

7. What is the hardest part of building a grocery delivery app?

Not the code. Substitutions (the category's biggest complaint driver, deserving disproportionate design time), inventory accuracy (showing stock that is not on the shelf destroys trust), and unit economics (inefficient pick routes and low drop density lose money silently on every order). Design those three before writing anything else.

8. Should I use dark stores or in-store picking?

Start with in-store picking if you are an existing retailer; it uses assets you have and validates demand cheaply. Dark stores pick two to three times faster and earn their cost once an area sustains high daily volumes. Tesco runs both, dedicated fulfillment in dense areas and store picking elsewhere, and that mixed pattern is the one worth copying.

9. Do I need AI features in a grocery app?

Two pay off immediately: substitution recommendations, which raise acceptance rates and cut support tickets, and personalized reorder prompts, since grocery is the most habitual purchase category there is. Demand forecasting comes next at scale, and making your catalog API agent-ready for conversational shopping via standards like MCP is cheap insurance on where commerce is heading.

10. Can I launch a grocery delivery app without building from scratch?

Yes, and for most founders it is the right first move. A white-label grocery platform ships the customer app, picker and driver apps, and admin panel under your brand in two to six weeks for a fraction of custom cost. Custom development earns its price once your operating model proves genuinely different, which you discover by operating rather than speculating.