Fallstudie · FoodTech · Mobile Marktplatz
Wie wir für ein FoodTech-Startup einen Multi-Vendor-Essenslieferungs-Aggregator entwickelt haben — native Kunden-Apps für iOS und Android, ein Admin-Panel für Kurier und Manager sowie eine multimodale Routing-Engine, die Lieferungen über Fußgänger-, Fahrrad-, Roller- und Auto-Kuriere hinweg pünktlich hält. Konzipiert für Zielgruppen in den USA und der Europäischen Union, mit einer DSGVO- und CCPA-konformen, auditbereiten Aufstellung von Tag eins an.
Der FoodTech-Kunde kam mit einem konkreten operativen Problem zu YuSMP Group: Kuriere wählten suboptimale Routen, machten unnötige Umwege, gerieten bei Adressen durcheinander und verloren Zeit — was zu verspäteten Lieferungen und schwindendem Kundenvertrauen führte. Die Produktvision war ein einziger Aggregator, der Restaurants, Supermärkte und Apotheken zu einem Kundenmarktplatz vereint und Managern wie Kurieren zugleich ein operatives Backoffice gibt, das die Lieferzeit tatsächlich verkürzt, statt sie nur zu protokollieren. Der moderne On-Demand-Käufer in den USA und der Europäischen Union erwartet einen aufgeräumten Katalog, einen Echtzeit-Bestellstatus und ein Ankunftsfenster, das hält — und die Plattform musste alle drei über Fußgänger-, Fahrrad-, Roller- und Auto-Kuriere hinweg in dicht besiedelten Stadtgittern liefern. Wir haben sie von Grund auf als dreiseitige Plattform gebaut: native Kunden-Apps für iOS und Android über einer Laravel-API, eine React-basierte Admin- und Dispatch-Oberfläche für Manager und Kuriere sowie eine multimodale Routing-Engine im Kern, die den optimalen Weg an den Transportmodus jedes Kuriers anpasst. Der Build erreichte das finale Pre-Release-Testing in den App Stores der USA und EU, mit Support bis zur Veröffentlichung und über künftige Updates hinaus.
Ein Überblick darüber, was der Build des Essenslieferungs-Aggregators über iOS, Android, eine Laravel-Steuerungsebene und eine multimodale Routing-Engine hinweg geliefert hat.
Die Routing-Entscheidung dominiert jede andere architektonische Wahl in einem Lieferaggregator, denn verspätete Lieferungen waren genau das Versagen, das der Kunde von uns beheben ließ. Wir haben uns für eine eigene multimodale Routing-Schicht statt einer einzelnen fertigen Directions-API entschieden, weil dieselbe Karte für einen Fußgänger-Kurier, ein Fahrrad, einen E-Roller und ein Auto grundlegend unterschiedliche optimale Routen erzeugt. Jeder Modus erhält ein eigenes Geschwindigkeitsprofil und Abbiegekostenmodell, und der Dispatcher bewertet Kandidaten anhand der voraussichtlichen Ankunftszeit, der aktuellen Auslastung und der Eignung des Modus für die Lieferdistanz — und reoptimiert dann kontinuierlich, sobald neue Bestellungen in die Queue gelangen. Eine reine Endkunden-Directions-API hingegen geht von einem einzigen Fortbewegungsmodus pro Anfrage aus und kennt weder Dispatch-Fairness noch Flottenauslastung, sodass jede ehrliche Pünktlichkeitsaussage in unserer eigenen Schicht durchdacht werden muss. Wir nutzen Kartenanbieter für den zugrunde liegenden Straßen- und Fußgängergraphen und legen unsere Bewertungs- und Dispatch-Logik darüber, was die Routing-Engine über US- und EU-Städte hinweg portierbar hält, ohne den Dispatcher neu zu schreiben.
Fertige White-Label-Liefer-SDKs wurden früh ausgeschlossen: Ihre Dispatch-Heuristiken sind undurchsichtig, ihre Fahrzeitmodelle gehen von reinen Auto-Flotten aus, und ihre Lizenzbedingungen machten das dreiseitige Account-Modell umständlich. Die Routing-Engine selbst auf Basis offener Standards zu bauen, bedeutete, dass der gesamte Pfad — Katalog, Warenkorb, Dispatch, Kurier-App — ein kohärentes, eigenes System ist, geliefert im Rahmen unserer Praxis für individuelle Softwareentwicklung.
| Dimension | Eigene Routing-Engine | Single-Modus-Directions-API | White-Label-Liefer-SDK |
|---|---|---|---|
| Transportmodi | Fußgänger, Fahrrad, Roller, Auto — separate Profile | Ein Modus pro Anfrage | Meist reines Auto-Flottenmodell |
| Dispatch-Fairness & Auslastung | In den Scorer eingebaut — ETA, Auslastung, Modus-Eignung | Keine — nur Wegbeschreibung | Undurchsichtige Anbieter-Heuristik |
| Reoptimierung bei neuen Bestellungen | Kontinuierlich über Queue-Jobs | Manuelle Neuabfrage | Anbietergesteuert |
| Dreiseitiges Account-Modell | Nativ — Kunde, Manager, Kurier | Nicht zutreffend | Umständlich erweiterbar |
| Portierbarkeit über US- & EU-Städte | Hoch — Kartengraphen tauschen, Dispatcher behalten | Hoch, aber logikfrei | Regional gebundene Lizenzierung |
| Datenhoheit | Vollständig — Bestell- und Dispatch-Daten in unserer Ebene | Abfragen verlassen das System zum Anbieter | Beim Anbieter |
| Kosten bei Skalierung | Planbar — nur pro Graphen-Abfrage | Pro Anfrage, wächst mit Neuabfragen | Anbietergebühr pro Bestellung |
Routing-Quellen: OpenStreetMap-Routing-Konzepte, Apple-MapKit-Dokumentation, Android-Referenz für Standort und Karten.
Die iOS-Kunden-App ist in Swift gebaut, mit einer Marktplatz-Startseite, die Restaurants, Geschäfte und Apotheken in einer durchsuchbaren Oberfläche zusammenführt, Kategorie-Chips und einer Aktions-Leiste (das Banner „erste Lieferung gratis" ist ein Merchandising-Slot, gesteuert aus dem Admin). In den Produktdetail- und Warenkorb-Flow haben wir überproportional viel Aufwand gesteckt, denn an abgebrochenen Warenkörben verlieren die meisten Liefer-Apps still und leise Umsatz: das In-den-Warenkorb-Element, der Mengen-Stepper und die Live-Bestellsumme aktualisieren sich sofort ohne Netzwerk-Roundtrip, und der Warenkorb gleicht sich erst beim Checkout mit der Serverpreisgestaltung ab. Der Katalog wird lokal zwischengespeichert, sodass das Browsen auch in instabilen Mobilfunknetzen flüssig bleibt, und die App degradiert elegant, wenn ein Anbieter mitten in der Sitzung offline geht.
Die Bestellaufgabe wird in dem Moment an die Routing-Engine übergeben, in dem ein Kunde bestätigt: Das Backend löst die Lieferadresse auf, wählt den geeigneten Kurier mit der niedrigsten ETA und liefert einen Live-Status, den der Kunde von „angenommen" bis „unterwegs" verfolgen kann. Derselbe Swift-Client führt die Standortberechtigungs- und Benachrichtigungsabläufe im Kontext — angefragt, wenn der Kunde erstmals eine Bestellung verfolgt, niemals beim Kaltstart —, um App-Store-Prüfer zufriedenzustellen und die Einwilligungserfahrung für Nutzer in den USA und der EU ehrlich zu halten. Die durchgängige iOS-Oberfläche wird im Rahmen unserer Praxis für Mobile App-Entwicklung geliefert.
Die Android-Kunden-App ist in Kotlin geschrieben, teilt sich dieselbe Laravel-API wie iOS, ist aber auf die Fragmentierungsrealität der Android-Flotte abgestimmt. Der Anbieterkatalog rendert als schnelles, bildlastiges Raster mit Bewertungen, Zubereitungszeit-Schätzungen und Preisen, gestützt auf paginierte API-Aufrufe und aggressives Bild-Caching, sodass die Liste auf Mittelklassegeräten der Samsung-, Xiaomi- und Pixel-Familien flüssig bleibt. Warenkorb-Status, Favoriten und die aktive Bestellung überleben Process Death und Konfigurationsänderungen — ein reales Thema unter Android, wo aggressive Akku-Optimierer und Low-Memory-Kills den Hintergrund-App-Zustand regelmäßig abräumen.
Der Echtzeit-Bestellstatus ist der Vertrag, den der Kunde implizit eingeht, daher hält der Android-Client einen Live-Kanal zum Backend für Statusübergänge — angenommen, in Zubereitung, abgeholt, unterwegs, geliefert — und greift auf Push-Benachrichtigungen zurück, wenn die App im Hintergrund läuft. Standort- und Benachrichtigungsberechtigungen werden im Kontext angefragt, und der Bestellverfolgungs-Screen liest aus derselben Status-Pipeline, in die die Kurier-App schreibt, sodass Kunde und Kurier nie einen abweichenden Zustand sehen. Dasselbe Engineering-Team trägt iOS und Android im Gleichschritt im Rahmen unserer Praxis für iOS- und Android-Engineering.
Die Steuerungsebene ist ein Laravel-Backend mit einer React-Admin- und Dispatch-Oberfläche für Restaurant- und Filialmanager sowie für Kuriere. Manager arbeiten an einer Live-Bestelltafel — eingehende Bestellungen, Anbieterannahme, Zubereitungs-Timer —, während Kuriere eine Dispatch-Ansicht mit ihrer zugewiesenen Route, der nächsten Abholung und der Kundenübergabe erhalten. Bestellereignisse fließen durch eine einzige Status-Pipeline, sodass Kunde, Manager und Kurier stets denselben Status lesen, und Routing- sowie Benachrichtigungsarbeit läuft als Hintergrund-Job in einer Queue, um die kundenseitigen Apps unter Last reaktionsschnell zu halten. Die Adressverarbeitung — genau der Schmerzpunkt, den der Kunde nannte — wird serverseitig normalisiert und gegen den Kartengraphen validiert, bevor überhaupt ein Kurier disponiert wird.
Beim Datenschutz wurde die Plattform so konzipiert, dass sie sich an den DSGVO-Pflichten für Nutzer in der Europäischen Union und den CCPA-/CPRA-Pflichten für Nutzer in Kalifornien und den übrigen USA ausrichtet. Der Kundenstandort wird nur für die Dauer einer aktiven Bestellung erhoben, die Zahlungsidentität wird vom Zahlungsanbieter verwaltet statt in der Bestellebene gespeichert, und der Zugriff auf die Admin-Oberfläche ist rollenbasiert begrenzt, sodass ein Kurier niemals die Kundendaten eines anderen Kuriers sieht. Das Design macht eine künftige unabhängige Datenschutz-Bereitschaftsprüfung zu einer Dokumentationsaufgabe statt zu einer architektonischen Nachrüstung.
Compliance-Aufstellung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.
Ein fünfphasiger Build, der den Aggregator von der Produktspezifikation bis zum finalen Pre-Release-Testing über iOS, Android, eine Laravel-Steuerungsebene und die Routing-Engine geführt hat.
Das dreiseitige Modell (Kunde, Manager, Kurier) abgebildet, die Fehlermodi „verspätete Lieferung" und „Adressverwirrung" festgenagelt sowie die DSGVO- + CCPA-Aufstellung und die Review-Anforderungen für App Store / Google Play von vornherein festgelegt.
Laravel-API-Gerüst, Multi-Vendor-Katalogschema, die multimodale Routing-Engine mit Geschwindigkeitsprofilen je Modus und der Dispatch-Scorer für ETA, Auslastung und Modus-Eignung.
Swift-iOS- und Kotlin-Android-Kunden-Apps über der gemeinsamen API, dazu die React-Admin- und Dispatch-Oberflächen für Manager und Kuriere, mit Warenkorb, Checkout und Echtzeit-Status.
Rollenbasierte Zugriffskontrolle, Adressnormalisierung gegen den Kartengraphen, QA der Berechtigungsabläufe, Lasttests der Dispatch-Queue und Verifizierung der auditbereiten Datenschutz-Aufstellung.
Finales Pre-Release-Testing vor der Einreichung bei App Store und Google Play über US- und EU-Storefronts, mit Support bis zur Veröffentlichung und über künftige Updates hinaus.
Die kurierseitige App und die Dispatch-Konsole der Manager sind der Ort, an dem die Plattform ihr Pünktlichkeitsversprechen tatsächlich einlöst. Ein Kurier meldet sich an, sieht eine von der Routing-Engine für seinen Transportmodus zusammengestellte Route und arbeitet eine Folge von Abholungen und Übergaben mit Turn-by-Turn-Führung und Ein-Tipp-Statusübergängen ab — angekommen, abgeholt, geliefert —, die direkt in die gemeinsame Bestell-Pipeline schreiben. Der Dispatcher weist nicht einfach den nächstgelegenen Kurier zu; er bewertet Kandidaten nach voraussichtlicher Ankunftszeit, aktueller Auslastung und danach, ob ein Fußgänger-, Fahrrad-, Roller- oder Auto-Kurier das richtige Mittel für die Lieferdistanz ist, und reoptimiert dann, sobald frische Bestellungen eintreffen, sodass eine einzelne neue Bestellung eine bereits effiziente Route nicht zunichtemacht. Manager wiederum betreiben eine React-Bestelltafel, die Anbieterannahme, Zubereitungs-Timer und jede hinter ihrem Fenster zurückliegende Lieferung sichtbar macht, mit der Adressnormalisierung, die die ursprüngliche Verwirrung behebt und bereits eingebaut ist, bevor überhaupt ein Kurier disponiert wird. Die gesamte operative Oberfläche wurde auf Erweiterbarkeit ausgelegt: einen neuen Anbietertyp, einen neuen Transportmodus oder eine neue Stadt hinzuzufügen, ist eine Konfigurations- und Datenaufgabe gegen die Katalog- und Routing-Services, kein Code-Release — dieselbe Skalierungsdisziplin, die wir in unsere Cloud-&-DevOps-Roadmaps einbringen.
Der Aggregator wurde aus einer einzigen Codebasis pro Plattform für die App-Store- und Google-Play-Storefronts in den USA und der Europäischen Union konzipiert. Der englischsprachige Build ist für Nutzer in Kalifornien, New York, Texas, Florida und Washington in den USA sowie für Nutzer in den Niederlanden, Deutschland, Frankreich, Irland und Schweden in der EU positioniert, ohne eine separate Codebasis pro Region. Die Einwilligungsabläufe sind auf der Client-Ebene regionsbewusst: Nutzer in der EU und im EWR erhalten einen granularen Einwilligungsbildschirm im DSGVO-Stil mit separaten Schaltern für optionale Produktanalysen, während Nutzer in Kalifornien im selben Ablauf einen Hinweis im CCPA-Stil zu „Do Not Sell or Share My Personal Information" erhalten. Die Datenverarbeitungspraktiken sind an der DSGVO für Nutzer in der Europäischen Union und am Flickenteppich der US-Bundesstaaten-Datenschutzgesetze ausgerichtet — CCPA / CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA. Da Kundenstandort- und Bestelldaten per Design minimiert und kurzlebig sind, reduziert sich die regionale Compliance weitgehend auf ehrliche Offenlegung statt auf eine Datentrennung je Rechtsraum.
Die Routing-Engine ist per Design über US- und EU-Städte hinweg portierbar — der Dispatcher und die Geschwindigkeitsprofile je Modus bleiben konstant, während der zugrunde liegende Kartengraph je Region getauscht wird —, wobei die DSGVO-Pflichten und die CCPA-Pflichten Kaliforniens direkt in der In-App-Datenschutzerklärung zitiert werden. Sowohl die App-Store-Altersfreigabe als auch die Google-Play-Inhaltsbewertung wurden für einen Funktionsumfang zur Speisen- und Getränkelieferung kalibriert, und Standort- sowie Benachrichtigungsberechtigungen werden im Kontext angefragt, um Prüfer sowohl in den USA als auch in der EU zufriedenzustellen. Das Engineering-Team hinter dem Build arbeitet in der MEZ und folgt einem MEZ-Arbeitstag mit Überlappung zur US-Ostküste (9–13 Uhr ET) für Stand-ups, die Choreografie der Store-Reviews und das Incident-Response — das Zeitzonenfenster, das einem US-Produktteam und einem EU-Engineering-Team täglich vier Stunden Live-Überlappung verschafft.
Die aktive Roadmap für individuelle Softwareentwicklung des Aggregators umfasst geplante und Gruppenbestellungen, eine Loyalty- und Aktions-Engine auf Basis der bestehenden Merchandising-Slots, Kurier-Verdienst- und Schichtverwaltung in der Dispatch-Konsole sowie Live-Kartenverfolgung des Kuriers auf dem Bestell-Screen des Kunden. Die Infrastrukturpläne umfassen weitere Automatisierung der Dispatch-Queue, Tooling für den Multi-City-Rollout, sodass eine neue Region eine Datenaufgabe ist, sowie eine Datenresidenz-Option, die EU- und US-Bestelldaten an regionale Speicher bindet — alles eingebettet in die Cloud-&-DevOps-Roadmap, damit die Plattform sauber von einer Stadt zu einer landesweiten Präsenz über die USA und EU skaliert.
Wenn Sie einen Essenslieferungs-Aggregator, eine Q-Commerce-App oder ein beliebiges On-Demand-Logistikprodukt planen, bei dem das Pünktlichkeitsversprechen ein reales städtisches Dispatching für Zielgruppen in den USA und der EU überstehen muss, haben wir diesen Stack durchgängig ausgeliefert und können den Build-Zeitplan deutlich verkürzen. Die Plattform erreichte das finale Pre-Release-Testing über iOS und Android, und das Engineering-Team dahinter sitzt innerhalb von YuSMP Group. Einen Überblick über den Build finden Sie in unserer Fallstudie zum Essenslieferungs-Aggregator. Wir arbeiten zum Festpreis für gut umrissene MVPs und mit dedizierten Entwicklerteams für die laufende Lieferung, mit einem MEZ-Arbeitstag und einem garantierten Überlappungsfenster zur US-Ostküste (9–13 Uhr ET) für Stand-ups, Demos und Incident-Response.
Ein Essenslieferungs-Aggregator-MVP mit Kunden-Apps für iOS und Android, einem Multi-Vendor-Katalog, Warenkorb und Checkout sowie einem einfachen Admin-Panel für Kurier und Manager kostet üblicherweise 90k–220k €. Ergänzt man eine multimodale Kurier-Routing-Engine, Echtzeit-Tracking, Zahlungsintegrationen, Aktionen und eine separate Kurier-App, kommt ein vollständiger Marktplatz auf 250k–550k €. Die dominierenden Kostentreiber sind die Routing- und Dispatch-Logik, das dreiseitige Account-Modell und die Echtzeit-Synchronisation des Bestellstatus über die Kunden-, Anbieter- und Kuriersicht hinweg.
Laravel gibt einem Liefermarktplatz ein ausgereiftes, vollständig ausgestattetes PHP-Backend — Queues für Dispatch-Jobs, ein ausdrucksstarkes ORM für den Multi-Vendor-Katalog und einen großen Talentpool, der eine dreiseitige Plattform wartbar hält. React betreibt die Admin-Oberflächen für Manager und Kuriere mit einem Komponentenmodell, das sich sauber auf Live-Bestelltafeln und Dispatch-Konsolen abbilden lässt. Die Kombination hält die API und das operative Web-Tooling in einem gut verstandenen Ökosystem, was den Build verkürzt und die langfristigen Betriebskosten für die US- und EU-Teams senkt, die die Plattform betreiben.
Eine multimodale Routing-Engine trennt das Fahrzeitmodell von der Dispatch-Logik. Jeder Transportmodus — zu Fuß, Fahrrad, Roller und Auto — erhält ein eigenes Geschwindigkeitsprofil und Abbiegekostenmodell, sodass dieselbe Karte je Kurier unterschiedliche optimale Routen erzeugt. Der Dispatcher bewertet Kandidaten anhand der voraussichtlichen Ankunftszeit, der aktuellen Auslastung und der Eignung des Modus für die Lieferdistanz, weist dann zu und reoptimiert kontinuierlich, sobald neue Bestellungen eingehen. Routing-Aufrufe laufen als Hintergrund-Jobs in einer Queue, damit die kundenseitige App reaktionsschnell bleibt.
Apple und Google verlangen beide, dass Essenslieferungs-Apps die Datenerhebung klar offenlegen, die Standortberechtigung mit einer Begründung zur Vordergrundnutzung handhaben und digitale In-App-Käufe angemessen abwickeln, während die reale Lieferung außerhalb des In-App-Kaufs bezahlt werden darf. Beide Stores erwarten eine funktionierende Datenschutzerklärung, altersgerechte Inhaltsbewertungen und — für Apps, die Nutzer in der EU und Kalifornien bedienen — einen granularen Einwilligungsablauf, der DSGVO und CCPA / CPRA auf demselben Bildschirm erfüllt. Standort- und Benachrichtigungsberechtigungen müssen im Kontext angefragt werden, nicht beim ersten Start.
Ein fokussiertes MVP mit Kunden-Apps für iOS und Android, einem Multi-Vendor-Katalog, Warenkorb und Checkout sowie einem einfachen Admin-Panel dauert üblicherweise 16–28 Wochen. Eine multimodale Kurier-Routing-Engine, eine eigene Kurier-App, Echtzeit-Tracking sowie Zahlungs- und Aktionssubsysteme kommen mit 8–14 Wochen hinzu. Das deckte sich mit dem rund neunmonatigen Zeitplan dieses Builds, der das finale Pre-Release-Testing in beiden Stores erreichte, mit laufendem Support bis zur Veröffentlichung und über künftige Updates hinaus.
Verwandte Fallstudien
On-Demand-Lebensmittelmarktplatz mit Kurier-App, Ops-Konsole und Live-Bestellverfolgung über die USA & EU.
Fallstudie ansehen →
Ernährungs- und Mahlzeitplan-Plattform, die Rezepte mit Lieferung für gesundheitsbewusste Nutzer in den USA & EU verbindet.
Fallstudie ansehen →
Native Consumer-App für iOS + Android mit gehärteter Steuerungsebene und auditbereiter Aufstellung über die USA & EU.
Fallstudie ansehen →
Native iOS-, Android- und Cross-Plattform-Apps mit store-fertigen Release-Pipelines.
Mobile App-Entwicklung entdecken →
Maßgeschneiderte Plattformen, auf Ihr Geschäftsmodell zugeschnitten, die sauber vom MVP zu Millionen Nutzern skalieren.
Individuelle Softwareentwicklung entdecken →
Skalierbare Infrastruktur, CI/CD-Pipelines und Observability, damit Ihre Plattform von einer Stadt zu einer landesweiten Präsenz wächst.
Cloud & DevOps entdecken →Teilen Sie uns einige Details mit, und ein Senior-Consultant antwortet innerhalb eines Werktages.