Lebensmittellieferung — vier Apps, eine Substitutions-Engine

Die Aufgabe — ein Lieferunternehmen ohne Geschäftsprozess

Der regionale Lebensmittelhändler kam mit einer klaren Ambition — einen Lieferservice für Kunden in den Vereinigten Staaten und der Europäischen Union zu starten — und einer unbequemen Lücke: kein operativer Prozess für irgendeinen der beweglichen Teile. Es gab keinen definierten Picker-Workflow im Laden, keine vereinbarte Substitutions-Policy, wenn ein Artikel ausging, keine Kurier-Disponierungsregel, keinen Rhythmus für die Admin-Aufsicht. Eine fertige Lebensmittel-Liefer-SaaS hätte die Meinung eines Dritten zu all diesen Entscheidungen ausgeliefert; der Sprung in ein code-first-MVP hätte die erste Vermutung des Teams zu jeder davon fest verdrahtet. Wir haben zuerst das Lieferunternehmen selbst entworfen — Picker-Schritte, Substitutionsschwellen, Kurier-Übergabefenster, Eskalationspfade — und dann ein koordiniertes Ökosystem aus vier Produkten prototypisiert, die sich ein Laravel-Backend teilen. Die Kunden-iOS-und-Android-App gibt Einkäufern eine Live-Bestellverfolgung mit Phasenanzeigen und einen In-App-Chat zum Kurier. Die mobile Picker-App führt das Personal mit intelligenten Benachrichtigungen durch das Lager und mit einem Substitutionsablauf, der den Kunden in dem Moment anpingt, in dem ein Artikel nicht vorrätig ist. Das Web-Admin-Panel zentralisiert Katalog, Analytics und Auftragsverwaltung über jeden Store im Netzwerk für die Zielgruppe in den USA & der EU.

In Zahlen

Ein Überblick über das, was das Lebensmittel-Liefer-Ökosystem über vier Apps, ein Laravel-Backend und eine Substitutions-Policy-Engine in seinem ersten Produktivzyklus geliefert hat.

Liefermethodik

Ein Build in fünf Phasen, der das Lebensmittel-Liefer-Ökosystem von einem Händler ohne operativen Prozess zu vier ausgelieferten Apps und einer Substitutions-Policy-Engine führte.

Launch in den Vereinigten Staaten und der Europäischen Union

Das Ökosystem startete im Apple App Store und bei Google Play mit aktiven Storefronts in den Vereinigten Staaten und der Europäischen Union, ergänzt um das React-Admin-Panel, das für die Operations-Teams der Händler auf beiden Seiten des Atlantiks bereitgestellt wurde. Der englischsprachige Build bedient Einkäufer in Kalifornien, New York, Texas, Florida und Washington in den USA sowie Einkäufer in den Niederlanden, Deutschland, Frankreich, Irland und Schweden in der EU — ohne eine separate Codebasis je Region. Die Einwilligungsabläufe sind auf der Client-Schicht regionsbewusst: Nutzer in der EU und im EWR erhalten eine granulare Einwilligungsanzeige im DSGVO-Stil mit separaten Schaltern für Marketing und Analytics; Nutzer in Kalifornien erhalten im selben Ablauf einen Hinweis im CCPA-Stil „Do Not Sell or Share My Personal Information". Die Datenverarbeitungspraktiken stehen im Einklang mit der DSGVO für europäische Nutzer und mit dem Flickenteppich der US-Bundesstaaten-Datenschutzgesetze — CCPA / CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA. Multi-Store-Routing macht den regionalen Rollout inkrementell: Ein neues Ballungsgebiet in einem beliebigen US-Bundesstaat oder EU-Land ist ein Ladenplan-Upload plus ein Katalog-Snapshot.

Die Kunden-App, die Picker-App und das Admin-Panel wurden parallel über US- und EU-Pilot-Stores ausgerollt — Niederlande, Deutschland, Frankreich, Schweden und Irland für die EU-Abdeckung; Pilotregionen im US-Osten und US-Westen für Nordamerika — wobei die Stores jeder Region identisch gegen dasselbe Laravel-Backend bereitgestellt wurden. Der Matching-Service, der je Bestellung den richtigen Store und Kurier auswählt, betreibt zustandslose Worker, die für künftige Datenresidenz-Verpflichtungen unabhängig an EU- oder US-Regionen gebunden werden können. Das Engineering-Team hinter dem Build ist über die MEZ verteilt und arbeitet einen MEZ-Arbeitstag mit Überlappung mit der US-Ostküste (9–13 Uhr ET) für händlerseitige Stand-ups, die Koordination der Store-Teams und die Incident-Response — die Zeitzone, in der sich ein US-Operations-Team und ein EU-Engineering-Team jeden Tag vier Stunden Live-Überlappung teilen.

Tech-Stack und Roadmap

Die aktive individuelle Softwareentwicklung-Roadmap für das Lebensmittel-Liefer-Ökosystem umfasst eine Liefer-Abomitgliedschaft mit garantiertem Zeitfenster, ein Dark-Store-Fulfillment-Overlay, das dieselbe Routing-Engine wiederverwendet, einen B2B-Vertragskanal für kleine Unternehmen mit Mengenrabatten und eine Kunden-Loyalty-Stufe, die für das Lernen von Präferenzen an die Substitutions-Policy-Engine anknüpft. Ein Fahrer-Self-Onboarding-Portal ist geplant, und das Entitlement-Teilsystem ist bereits für die Mehrplatz-Zuweisung strukturiert. Zu den Infrastrukturplänen gehören weiteres Performance-Tuning der Routing-Engine, ein internes Regressions-Harness für die Substitutionsqualität und eine künftige unabhängige Bereitschaftsbewertung, die in die Cloud-&-DevOps-Roadmap eingebettet ist.

Ein Liefer-Ökosystem wie dieses bauen — sprechen Sie mit uns

Wenn Sie ein Lebensmittel-Liefer-Ökosystem, eine Multi-App-Last-Mile-Plattform oder ein beliebiges operatives Produkt planen, bei dem der Geschäftsprozess für Zielgruppen in den USA und der EU vor den Screens entworfen werden muss, haben wir diesen Stack end-to-end umgesetzt und können den Build-Zeitplan deutlich verkürzen. Das Engineering-Team hinter dem Build ist Teil der YuSMP Group, und die Live-Produktoberfläche bleibt auf Wunsch des Händlers privat. Wir arbeiten zum Festpreis für gut abgegrenzte MVPs und mit dedizierten Entwicklerteams für die laufende Lieferung, mit einem MEZ-Arbeitstag und einem garantierten Überlappungsfenster mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, Demos und die Incident-Response.

Diese Fallstudie teilen