How to build an app like Instacart: Grocery delivery architecture explained

Instacart's model is counterintuitive. They built a $10 billion grocery delivery platform without owning a single grocery store, a single delivery vehicle, or a single grocery item.

What they built is a coordination layer -- connecting customers who want groceries with people willing to shop and deliver, at thousands of retail grocery locations. The technology is the coordination. The stores, the inventory, and the delivery workforce belong to someone else.

That "asset-light" model is elegant in business terms. In engineering terms, it creates a set of hard problems that pure-play delivery apps (which own their inventory in dark stores) don't face.

Chief among them: Instacart has no reliable way to know whether a specific item is actually in stock at a specific store right now. The shopper finds out when they walk the aisle.

Understanding this constraint is the starting point for building in this space.

The four products you're actually building

Most project scopes start with the customer app and call the shopper app a minor add-on. That's wrong.

Customer app -- search, browse, add to cart, checkout, real-time order tracking, substitution preferences, ratings.

Shopper app -- accept job offers, pick items with optimized route, handle substitutions, communicate with customer, confirm delivery.

Retailer portal -- store catalog management, inventory sync configuration, order reporting, promotions.

Dispatch engine -- match orders to available shoppers, handle scheduling (ASAP vs. scheduled), balance shopper workload, manage tip transparency.

Each is a production-quality product. Skip any one and the system breaks. No retailer portal means manual catalog management at scale. Poor shopper app means slow pick times. No dispatch engine means manual assignment.

Customer app: The consumer experience

Grocery catalog and search

Customers browse a catalog representing a specific store's inventory. This catalog needs to be:

• Organized by department: Produce, Dairy, Meat, Bakery, Frozen, etc.
• Searchable by item name or brand: "Chobani yogurt" not "dairy products"
• Filterable by dietary restriction: Organic, gluten-free, kosher, vegan -- these require structured product attribute data
• Sortable by price: Unit price display (price per oz, per count) helps customers compare

Catalog data comes from three sources:

1. Retailer-provided product data (ideal -- direct from the store's system)
2. Third-party grocery data providers (Open Food Facts, Syndigo, or commercial catalog providers)
3. Your own catalog built from past shopper scans and purchase history

At MVP, a third-party catalog is the fastest path. Open Food Facts (open-source) covers 3M+ products with nutrition data, barcodes, and categories. Commercial providers like Syndigo or 1WorldSync have richer data (better images, more attributes) at subscription cost.

Cart and substitution preferences

A grocery cart is more complex than an ecommerce cart because of the substitution layer.

When adding each item to cart, customers can set a substitution preference:

• Accept any brand alternative for this item
• Accept only this specific item (no substitution)
• Let the shopper decide

Pre-configured substitution preferences speed up shopping significantly. If every item has a customer preference, the shopper doesn't need to message for most out-of-stock situations -- they follow the preference and move on.

Building a smart substitution suggestion engine (when an item is unavailable, suggest the most similar alternative in terms of brand, size, nutritional profile, and price) is a phase 2 feature. At MVP, manual shopper substitution choices with customer approval work fine.

Scheduling and delivery windows

Instacart offers two modes:

• Express delivery: Delivered within 1-2 hours (shopper dispatched immediately)
• Scheduled delivery: Customer picks a date and delivery window (8-10am, 10-12pm, etc.)

Scheduled delivery is simpler to manage at low supply density -- you can aggregate demand and assign shoppers to batches. Express delivery requires shopper supply available on demand, which requires higher geographic density.

Launch with scheduled delivery only. Add express delivery when you have enough shopper supply to fill same-day slots consistently.

Real-time order tracking

Once a shopper accepts a job and starts shopping, customers see status updates:

• Shopper accepted and heading to store
• Shopping started
• Items found / substitution proposed (notification for customer approval)
• Checkout complete, heading to you
• Delivered

Live shopper location tracking (when en route to customer) is the highest-trust feature. It's the same WebSocket/Firebase location broadcast pattern as food delivery -- shopper app broadcasts location, customer app renders moving map marker.

Shopper app: Where operational efficiency is built

The shopper app determines how fast orders get picked and delivered. A slow pick process (shopper navigating a 100,000 sq ft supermarket randomly) kills your delivery time metrics.

Job acceptance flow

When an order is ready for dispatch, nearby available shoppers get a ping showing: store location, estimated number of items, estimated earnings, estimated time. They accept or decline within 30 seconds.

Show estimated earnings clearly -- shoppers accept more jobs when they can predict their income. Instacart shows base pay + tip total (or tip estimate if the customer hasn't yet specified) upfront.

Optimized pick list

The pick list is the shopper's working tool. Done poorly, it's a random list of items in the order the customer added them. Done well, it's an optimized route through the store.

Department grouping: Organizes items by store section (Produce > Dairy > Meat > Frozen). The shopper picks produce, moves to dairy, etc. -- no backtracking.

In-store routing: More advanced -- uses the store's floor plan to sequence items by physical aisle location. This requires store layout data (from the retailer or crowd-sourced from shoppers). Not required at MVP, but reduces pick time 20-30% when implemented.

Barcode scanning: Shoppers scan items as they pick them. This confirms they grabbed the right item (prevents wrong size/variant) and auto-advances the pick list. Scanning requires the device camera and a barcode parsing library (ZXing for Android, Vision framework for iOS).

Substitution workflow

This is where most shopper apps fail. Out-of-stock items require three paths:

Path 1: Pre-configured substitution preference Customer said "accept any brand alternative." The app suggests the closest available alternative (based on category, size, and price similarity). Shopper scans the substitute, confirms, and moves on. No customer message needed.

Path 2: Customer approval substitution Customer wants to approve before substitution. App sends customer a push notification showing the original item and a proposed alternative, with Accept/Reject/Suggest Another buttons. Shopper waits for response (typically 2-3 minutes). If no response, app falls back to skip or shopper judgment.

Path 3: Skip Customer wants the exact item or nothing. Shopper skips it, moves on. Item is refunded at checkout.

The substitution workflow needs to be fast -- a shopper handling 60-item orders can't wait 5 minutes per substitution. Design the notification to customer as a "swipe to decide" interaction, not a nested menu.

In-store communication

Shoppers sometimes need to ask customers questions: "Your store doesn't have this size -- want the bigger one at a higher price?" In-app messaging (or automated substitution cards that the customer can swipe) keeps this communication structured.

Unstructured messaging slows shoppers down. Design the shopper side so they can propose a substitute with one tap and wait for the customer's swipe -- no back-and-forth typing.

Checkout and delivery

When all items are collected, the shopper checks out at the register (using a platform-issued card or a cash advance, depending on your payment model) and heads to the customer.

Platform-issued card (Stripe Issuing): The shopper gets a virtual or physical prepaid card loaded with the order amount plus a buffer. They use it at checkout. The card is only valid for the assigned order. This is the cleanest payment model -- no shopper float, no reimbursement delays.

Shopper advance: Shopper pays out of pocket and is reimbursed. Simpler to launch but creates shopper friction (they need cash/their own card). Not recommended at scale.

At delivery, the shopper takes a confirmation photo (or gets a customer signature in some markets) and marks the order as delivered.

Retailer portal: Keeping inventory data fresh

The retailer portal is often an afterthought. It shouldn't be.

Catalog management

Retailers need to manage their product catalog -- adding new items, updating prices, marking discontinued items, managing promotional pricing. A self-serve portal where store managers can make these updates is essential. Without it, your catalog team manages updates manually per store.

Bulk upload: Import CSV with SKU, name, category, price, and barcode. Batch update pricing for promotions. This is a standard admin tool build: $10K-$15K.

API integration: For larger retail chains, a two-way API integration syncs catalog changes automatically. When the retailer updates a price in their POS system, it reflects in your catalog within hours. This requires a development relationship with the retailer's IT team and isn't available at MVP stage.

Inventory signals

True real-time inventory sync (knowing the exact in-stock quantity of every SKU in every aisle right now) isn't feasible without deep POS integration.

Practical approaches for inventory confidence:

1. Historical availability: Items with a 95%+ scan success rate by past shoppers are flagged "usually in stock." Items with frequent substitutions or skips are flagged "sometimes unavailable."
2. Shopper feedback loop: When a shopper substitutes or skips an item, that data feeds the inventory confidence model.
3. Store-specific events: Holidays, local events, and weather cause predictable stockouts. The platform can proactively flag risk categories.

At MVP, use approach 1 and 2. Over time, the shopper feedback loop creates a proprietary inventory signal that becomes more accurate than any point-in-time API.

Order reporting

Retailers want visibility into orders fulfilled through your platform -- GMV, top items, fulfillment rates, substitution rates. Basic reporting dashboard in the retailer portal satisfies this. It also gives you a lever for retailer retention -- retailers who see volume data and growing order trends stay on your platform.

Dispatch engine

The dispatch engine coordinates shoppers to orders. At its simplest: when an order is confirmed, find the nearest available shopper to the target store, send them a job offer, and fall through to the next nearest if they decline.

More sophisticated dispatch factors in:

• Shopper rating: Higher-rated shoppers get priority offers for high-value orders
• Shopper experience with that store: Shoppers who have shopped at a specific store frequently know the layout, which speeds up pick time
• Batch orders: Assigning multiple orders from the same store to one shopper (shop once, deliver to two customers in the same area) increases shopper earnings and reduces per-order delivery cost

Batching is a meaningful efficiency lever but requires more complex app logic (shopper manages two pick lists, two delivery addresses). Build single-order dispatch first and add batching in phase 2.

Scheduled order release: For scheduled deliveries, the dispatch engine releases the job offer to shoppers 60-90 minutes before the delivery window opens. This prevents shoppers from accepting jobs too far in advance and then becoming unavailable.

Tech stack

Customer app: React Native for iOS/Android cross-platform.

Shopper app: React Native with native camera module for barcode scanning. Offline mode for the pick list (shoppers in large refrigerated sections lose signal -- the app must work without connectivity and sync when signal returns).

Retailer portal: React or Next.js web app.

Backend: Node.js or Python FastAPI. PostgreSQL for orders, shoppers, retailers. Redis for availability caching and dispatch state. Elasticsearch for product search.

Real-time tracking: Firebase Realtime Database (easiest) or WebSockets.

Payments: Stripe Issuing for shopper cards. Stripe or Braintree for customer-facing payments.

Catalog data: Open Food Facts (free, 3M+ products) + manual curation for your launch retailer's specific inventory.

Development timeline

Cost breakdown

Where most grocery delivery apps fail

Inventory inaccuracy destroys trust fast. Customers who order 20 items and receive 3 substitutions and 2 skips don't come back. The fix is a combination of accurate catalog data, pre-configured substitution preferences, and fast in-app communication during the shop. Invest in the substitution workflow -- it's not glamorous engineering but it's the highest-leverage UX improvement.

Shopper economics must work from day one. If shoppers can't earn $15-$20/hour after platform fees and vehicle costs, they work one shift and never return. Earnings transparency and reasonable per-delivery rates aren't perks -- they're supply retention.

Launch in one zip code, not one city. Your first 20 shoppers can cover 3-5 zip codes efficiently. Spread them across a whole city and the wait times climb to 2+ hours. Concentrated supply in a small area produces a better customer experience and teaches you more per order.

The technology is real but the supply-side economics and geographic density are what determine whether your grocery platform works in market.

1Raft builds delivery platforms and marketplace apps for founders who want to understand the full scope before they start. If you're scoping a grocery delivery or on-demand marketplace product, talk to us first -- the architecture decisions made in week 1 affect your costs for the entire build.