Process design & threat model
Picker-step workshops, substitution-policy design, courier handoff rules, escalation paths, GDPR + CCPA posture mapping, store-fleet validation against three real shifts.
Case study · Grocery Delivery · Mobile
Grocery Delivery — four apps, one substitution engine
How we shipped a production grocery-delivery ecosystem — a customer iOS and Android app, a picker mobile app, a web admin panel, and a Laravel backend with a real substitution-policy engine — designed around the business process rather than around the screens, for retailers across the US and EU.
The brief — a delivery business without a business process
The regional grocery retailer arrived with a clear ambition — launch a delivery service to customers across the United States and the European Union — and an uncomfortable gap: no operational process for any of the moving parts. There was no defined picker workflow inside the store, no agreed substitution policy when an item ran out, no courier dispatch rule, no admin oversight cadence. Buying off-the-shelf grocery-delivery SaaS would have shipped someone else's opinion about all of those decisions; jumping into a code-first MVP would have hard-coded the team's first guess at each one. We designed the delivery business itself first — picker steps, substitution thresholds, courier handoff windows, escalation paths — and then prototyped a coordinated ecosystem of four products that share one Laravel backend. The customer iOS and Android app gives shoppers live order tracking with stage indicators and an in-app chat to the courier. The picker mobile app guides staff through the warehouse with smart notifications and a substitution flow that pings the customer the instant an item is out of stock. The web admin panel centralizes catalog, analytics, and order management across every store in the network for the US & EU audience.
Project highlights
Process-led design, not screen-led
Laravel backend with one source of truth
Native Swift + Kotlin customer app
Picker mobile app with warehouse routing
Substitution-policy engine
Real-time tracking with WebSockets
Multi-store catalog and routing
KPI analytics for the US & EU
By the numbers
A snapshot of what the grocery-delivery ecosystem delivered across four apps, one Laravel backend, and a substitution-policy engine in its first production cycle.
4coordinated products — customer iOS + Android, picker app, admin panel sharing one backend
1Laravel backend — one source of truth for catalog, orders, substitutions, and courier state
0per-app workflow divergence — the four apps read one process, not four copies
3substitution signals — customer preference, product taxonomy, multi-store availability
2real-time channels — WebSocket order state plus in-app chat between customer and courier
18–24 wktypical delivery window for a comparable four-app grocery-delivery ecosystem MVP
Why process-led design over a code-first MVP or a SaaS template
The architecture decision dominated every other lever in the build. We chose a process-led design over a code-first MVP and an off-the-shelf grocery-SaaS template because the trade-offs lined up with a retailer who had stores, staff, and customers — but no operational rules to feed them into. A code-first MVP would have hard-coded the team's first guess at the picker workflow, the substitution policy, and the courier handoff into the schemas; correcting that guess after launch would have meant a schema migration, four client releases, and a re-trained store staff. An off-the-shelf grocery SaaS solves the schema problem but trades it for somebody else's opinion about every operational lever the retailer needs to differentiate on.
Process-led design inverted both trade-offs. We mapped the picker's steps, the customer's expectations, and the courier's handoff in workshops with the actual store staff first, validated the flow against three real shifts before any schema was frozen, and only then wrote the Laravel order workflow engine that the four apps consume. The result is a delivery ecosystem where the four apps share one workflow — not four bolted-on opinions — and a substitution-policy change is one configuration update against the engine, not a four-client release.
| Dimension | Process-led (Grocery Delivery) | Code-first MVP | SaaS template |
|---|---|---|---|
| Workflow accuracy on launch | Validated against real shifts before code | First-guess hard-coded into schemas | Vendor's opinion of average workflow |
| Substitution-policy fit | Policy designed with store staff | Substitution flag — minimal logic | Fixed policy or extra-cost module |
| Multi-store ergonomics | Multi-store routing first-class in engine | Single-store first, retrofitted later | Vendor-defined store model |
| Cost of workflow change post-launch | Config update against one engine | Schema migration + four client releases | Vendor ticket — wait for roadmap |
| Picker app fit to store layout | Warehouse routing built from store map | Generic checklist | Vendor-defined routing |
| Real-time state coherence | One WebSocket channel from engine | Polling or per-app sockets | Vendor pub/sub, often metered |
| Vendor / lock-in | Open framework — portable | Open framework — moderate | Hard vendor lock-in |
References: Laravel framework documentation, Apple UserNotifications documentation, Android foreground service documentation.
Picker app build — Kotlin, Swift, and warehouse routing
The picker mobile app is the operational heart of the build. It runs natively on Android with Kotlin and on iOS with Swift, depending on the store's device fleet, and the foreground service keeps it running across battery-optimizer cycles that would otherwise kill a long picker shift mid-order. The screen is built around one large action at a time — scan, confirm, substitute, hand off — because a picker walking a store cannot read a dense dashboard while pushing a cart. Warehouse routing reads the store's aisle map from the backend and orders the picker's path so the longest walk is one trip end-to-end, not the back-and-forth pattern an alphabetical list would produce.
The substitution flow is the most interesting interaction in the app. When the picker scans an out-of-stock item, the policy engine evaluates the order against three signals — customer preference, product taxonomy, multi-store availability — and surfaces a candidate substitution that the picker can offer in one tap. The customer receives a push notification with the candidate, accepts or counter-proposes through in-app chat, and the picker continues the pick. Every transition writes to the order's audit trail, so a customer-service review later can reconstruct exactly what was offered, accepted, and substituted. The end-to-end mobile surface is delivered as part of our mobile app development practice.
Admin panel — React, Laravel, and the multi-store ops console
The admin panel is built in React on top of the same Laravel backend that powers every other surface, so every read in the admin is a live read against the order workflow engine rather than a snapshot from a sync job. Managers see one inbox with every order in flight across every store in the network, filtered by stage, store, courier, and substitution status. The KPI dashboard surfaces shift-level metrics — orders per picker hour, substitution acceptance rate, courier handoff window adherence, customer chat response time — with drift alerts that fire before the next shift starts, not after it has already gone wrong.
Catalog management is unified across stores: a product update propagates to every store that carries it, and per-store overrides handle local promotions, regional inventory, and seasonal assortment without forking the product record. Courier team management runs in the same panel, with shift assignments, document checks, and earnings views that drop the manager out of three separate spreadsheets. The same backend powers cloud & DevOps deploy of the entire ecosystem, so a new store onboarding is a configuration row plus a store-map upload, not a code change.
Real-time state, in-app chat, and privacy posture
Real-time state is the connective tissue across the four apps. A single WebSocket channel publishes order transitions — placed, accepted, picking, substituting, picked, courier-assigned, en route, delivered — and every client subscribes to the slice it cares about. The customer app shows stage indicators that advance the moment the picker scans the last item. The picker app surfaces a substitution chat reply the second the customer responds. The admin panel watches drift across every order in flight without a poll. The order-editing window — the few minutes after checkout where a customer can still add or remove items before the picker assembles the cart — is the same engine pushing back to the customer the instant the picker accepts the order.
Customer privacy is built into the platform from day one. Checkout exposes a granular GDPR consent screen for users in the European Union and a CCPA / CPRA "Do Not Sell or Share My Personal Information" disclosure for users in California in the same flow. Courier location streams are dropped immediately after the delivery completes, chat transcripts have shorter retention than order receipts, and a deletion request is a single backend job that propagates across the customer app, picker app, and admin in the same transaction. The result is an ecosystem that holds up to scrutiny across the US & EU without retrofitting compliance later.
Compliance posture: GDPR-aligned · ISO 27001 ready · SOC 2 Type II in progress · HIPAA-capable · CCPA-acknowledged.
Delivery methodology
A five-phase build that took the grocery-delivery ecosystem from a retailer with no operational process to four shipping apps and a substitution-policy engine.
Engine & real-time spine
Laravel order workflow engine, substitution-policy module, WebSocket real-time channel, multi-store catalog model, product taxonomy and availability index.
App builds
Native Swift / Kotlin customer app, picker mobile app with warehouse routing, React admin panel; in-app chat, push notifications, order editing, courier assignment.
Audit-ready hardening
Role-based access, retention policies, region-aware consent flows, courier-location stream lifecycle, substitution audit trail, third-party readiness scaffolding.
Launch & telemetry
App Store + Google Play submission across US and EU storefronts, picker-team onboarding, KPI telemetry, first-cycle correction loop across the multi-store network.
KPI telemetry, courier team management, and a foundation for dark-store rollout
The KPI telemetry layer was designed so the retailer can see shift-level drift before the next shift starts. Orders per picker hour, substitution acceptance rate, courier handoff window adherence, in-app chat response time, and customer satisfaction at delivery all roll up into one dashboard with alerts that fire when a metric drifts past a configurable threshold. Courier team management runs in the same admin panel with shift assignments, document-verification checks, and earnings views that drop the operations manager out of three separate spreadsheets. Multi-store routing is first-class in the engine, so a dark-store rollout — a fulfillment-only location that exists to serve delivery but not walk-in customers — is a configuration row against the catalog and routing tables, not a separate code release. The whole subsystem is designed so a future loyalty tier, a subscription delivery membership for the United States and the European Union, or a B2B contract delivery channel for small businesses is a configuration change against the order workflow engine and the entitlement service, not a code release.
Launching across the United States and the European Union
The ecosystem launched on Apple App Store and Google Play with storefronts active across the United States and the European Union, plus the React admin panel deployed for retailer operations teams on both sides of the Atlantic. The English-language build serves shoppers in California, New York, Texas, Florida, and Washington in the US, and shoppers in the Netherlands, Germany, France, Ireland, and Sweden in the EU, without a separate codebase per region. Consent flows are region-aware at the client layer: users in the EU and EEA receive a GDPR-style granular consent screen with separate toggles for marketing and analytics; users in California receive a CCPA-style "Do Not Sell or Share My Personal Information" disclosure in the same flow. Data-handling practices are aligned with GDPR for European users and with the US state-privacy patchwork — CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas), and Oregon CPA. Multi-store routing makes regional rollout incremental: a new metro area in any US state or EU country is a store-map upload plus a catalog snapshot.
The customer app, picker app, and admin panel were rolled out across US and EU pilot stores in parallel — Netherlands, Germany, France, Sweden, and Ireland for EU coverage; US East and US West pilot regions for North America — with each region's stores provisioned identically against the same Laravel backend. The matching service that picks the right store and courier per order runs stateless workers that can be pinned to EU or US regions independently for future data-residency commitments. The engineering team behind the build sits across CET and runs a CET workday with East-Coast US overlap (9 AM–1 PM ET) for retailer-side standups, store-team coordination, and incident response — the timezone that lets a US operations team and an EU engineering team share four hours of live overlap every day.
Tech stack and roadmap
PHP
Laravel
React
Kotlin
Swift
PostgreSQL
Redis
WebSockets
REST API
Push notifications
In-app chat
Order workflow engine
Substitution policy engine
Catalog ingestion
Multi-store routing
Analytics dashboard
BI export
Docker
Nginx
The active custom software development roadmap for the grocery-delivery ecosystem includes a subscription delivery membership with a guaranteed window, a dark-store fulfillment overlay reusing the same routing engine, a B2B contract channel for small businesses with bulk discounts, and a customer-loyalty tier that ties into the substitution-policy engine for preference learning. A driver self-onboarding portal is planned, and the entitlement subsystem is already structured for multi-seat assignment. Infrastructure plans include further routing-engine performance tuning, an internal substitution-quality regression harness, and a future independent readiness assessment scaffolded into the cloud & DevOps roadmap.
Build a delivery ecosystem like this — talk to us
If you are planning a grocery-delivery ecosystem, a multi-app last-mile platform, or any operational product where the business process has to be designed before the screens for audiences in the US and EU, we have shipped this stack end-to-end and can compress the build timeline meaningfully. The engineering team behind the build sits inside YuSMP Group, and the live product surface remains private at the retailer's request. We work fixed-price for well-scoped MVPs and on dedicated development teams for ongoing delivery, with a CET workday and a guaranteed East-Coast US overlap (9 AM–1 PM ET) window for stand-ups, demos, and incident response.
Frequently asked questions
How much does it cost to build a grocery delivery ecosystem with a picker app and admin?
A focused grocery-delivery MVP with a customer iOS and Android app, a picker mobile app, a web admin panel, a Laravel backend, real-time order tracking, in-app chat, and a single-store catalog typically costs $180k–$340k. Adding a substitution-policy engine, multi-store routing, a KPI analytics dashboard, courier team management, and integration with the retailer's accounting and inventory stack brings a full-featured ecosystem to $360k–$720k. The dominant cost drivers are the substitution flow design, the picker warehouse-routing logic, and the cross-app real-time state machine.
Why design the business process first instead of jumping into a code-first MVP?
A grocery delivery business has more operational complexity than software complexity. The picker has to know which aisle to walk first, the customer has to be told the moment a substitution is offered, the courier has to be dispatched to the right pickup window, and the admin has to see KPI drift before it hurts the next shift. Designing the business process — picker workflow, substitution policy, courier handoff, escalation paths — before writing client code means the four apps share one workflow rather than four bolted-on opinions about what should happen next.
How does the substitution-policy engine work?
When a picker scans an out-of-stock item, the policy engine evaluates the order against three signals: the customer's stated substitution preference at checkout, the product taxonomy (whole milk maps to whole milk first, then to 2 percent), and the in-store availability across the assigned store and neighboring stores in the same multi-store routing radius. A candidate substitution is offered to the customer through in-app chat, the customer accepts, declines, or counter-proposes, and the picker continues the pick — every transition writes to the order's audit trail.
What does GDPR and CCPA compliance look like for a grocery delivery app?
A grocery delivery app holds names, addresses, payment metadata, and a granular shopping history — the obligations are first-class. The checkout exposes a granular GDPR consent screen for users in the European Union and a CCPA / CPRA disclosure for users in California in the same flow. Order records are retention-bounded; chat transcripts have shorter retention than the order receipt; courier location streams are dropped immediately after delivery; and a request to delete is a single backend job across the customer app, picker app, and admin panel.
How long does it take to ship a grocery delivery ecosystem across iOS, Android, picker, and admin?
A focused MVP with a Laravel backend, a customer iOS and Android app, a picker mobile app, a web admin panel, real-time order tracking, in-app chat with the courier, and a single-store catalog typically takes 18–24 weeks. Adding a substitution-policy engine, multi-store routing, a KPI analytics dashboard, courier team management, and BI export adds 6–10 weeks. The audit-ready hardening pass — multi-app real-time state machine, retention policies, role-based access — is frequently underestimated and should be budgeted at 4–6 weeks.
Related cases
More multi-app retail builds
Retail · E-commerce
Malish
Local marketplace mobile app for an offline children's-goods chain — flexible catalog, online stock sync.
View case → Retail · FloristryFlowDelivery
Discovery for a flower delivery app pair — stock-aware catalog, three-step checkout, florist inventory.
View case → Mobility · RidesharingConvenient Taxi Aggregator
Three-app taxi platform — driver, passenger, dispatcher — with realtime GPS and document verification.
View case →Related services
Mobile App Development
Native iOS, Android, and cross-platform apps with store-ready release pipelines.
Learn more →
Custom Software Development
Custom platforms engineered to your business model, scaling cleanly from MVP to millions of users.
Learn more →
IT Staff Augmentation
Senior engineers embedded into your Jira and standups in two weeks. CET workday with US East Coast overlap.
Learn more →