Discovery & Anforderungen
Mapping der Käuferreise (Ausgangslage Beschaffung-per-Telefon), Erhebung der Verkäufer-Workflows, mandantenfähiges Datenmodell, Prüfung des US- und EU-Handels- und Datenschutzrechts, Evaluierung der VIN-Katalog-Anbieter.
Fallstudie · Automotive · E-Commerce
Wie wir einen produktiven zweiseitigen Autoteile-Marktplatz ausgeliefert haben — Flutter-Käufer-Apps für iOS und Android, eine Web-Käuferoberfläche und ein mandantenfähiges Verkäufer-CRM — aufgebaut auf Symfony mit Laximo-gestützter VIN-Suche, standortbezogenem Bestand über viele Filialen hinweg, integrierter Lieferübergabe und einer audit-fähigen Aufstellung, die den DSGVO- und CCPA-Anforderungen für Käufer und Verkäufer in den Vereinigten Staaten und der Europäischen Union standhält.
Ein Autovermietungs-Betreiber hatte immer wieder Mühe, Ersatzteile von verstreuten, nicht vernetzten Lieferanten zu beziehen. Jeder Einkauf erforderte das Durchsuchen zahlreicher Anbieter, telefonische Preisvergleiche und das Abgleichen von Lieferungen, die an unterschiedlichen Tagen von unterschiedlichen Adressen eintrafen. Das Team brauchte eine einheitliche Beschaffungsebene — einen käuferseitigen Marktplatz, der die Teilekataloge mehrerer Verkäufer bündelte, mit VIN-basierter Suche, damit ein Mechaniker passende Teile finden konnte, ohne in Papier-Mikrofichen zu blättern, und ein verkäuferseitiges CRM, das Teilehändlern einen überzeugenden Grund bot, ihren Bestand aus Tabellenkalkulationen herauszulösen. Die Plattform musste außerdem den Anforderungen von Käufern und Verkäufern in den Vereinigten Staaten und der Europäischen Union standhalten: DSGVO für europäische Nutzer, CCPA für Nutzer in Kalifornien und audit-fähige Aufzeichnungen für Betreiber, die Flotten über mehrere Rechtsräume hinweg bedienen. Wir bauten die Plattform als Flutter-Käufer-App für iOS und Android, eine React-Web-Käuferoberfläche und ein mandantenfähiges Verkäufer-CRM auf einem gemeinsamen Symfony-Backend, mit Laximo-gestützter VIN-Suche und integrierter Lieferübergabe. Das Ergebnis ist ein produktiver Marktplatz, der den Kreislauf von der VIN-Abfrage bis zur Teilelieferung schließt und für einen konformen Betrieb in den USA und der EU aufgestellt ist.
Eine Momentaufnahme dessen, was das ZipIt-Projekt über Flutter-Käufer-Apps, eine React-Web-Oberfläche und ein mandantenfähiges Symfony-Verkäufer-CRM hinweg geliefert hat.

Die Plattformentscheidung bestimmt maßgeblich die Iterationsgeschwindigkeit eines zweiseitigen Marktplatzes. Wir haben uns auf der Käuferseite für Flutter statt für ein natives iOS-+-Android-Paar und statt für einen Magento-Storefront-Wrapper entschieden, weil die Abwägungen sauber zu dem passen, was ein Autoteile-Marktplatz tatsächlich braucht. Magento ist eine solide E-Commerce-Plattform für Kataloge einzelner Verkäufer, zahlt aber einen hohen Preis, wenn man versucht, sie mandantenfähig zu machen, und ein Stack aus „Magento + Mobile-Wrapper“ fügt eine WebView-Schicht hinzu, die Käufer wie auch der App-Store-Prüfer sofort erkennen. Natives iOS + Android würde für ein Formular- und Katalogprodukt nur einen Bruchteil des Mehrwerts liefern — bei doppelten Entwicklungskosten gegenüber einer Flutter-Codebasis.
Das Projekt stützt sich auf die offiziellen Dokumentationsmuster von Flutter für State-Management und Platform-Channels, auf das Symfony-Framework im Backend und auf PostgreSQL Row-Level Security für die Mandantenisolation im mandantenfähigen Verkäufer-CRM — offene, zitierfähige Primitive, die uns einen wartbaren plattformübergreifenden Marktplatz liefern, ohne den Betreiber an ein Anbieter-SaaS zu binden.
| Dimension | Flutter (ZipIt) | Natives iOS + Android | Magento + Mobile-Wrapper |
|---|---|---|---|
| Eignung für mandantenfähiges CRM | Backend-unabhängig; Symfony nativ mandantenfähig | Gleiches Backend; identische Eignung | Magento-Mandantenfähigkeit ist aufgesetzt, fragil |
| VIN-Such-Latenz | Dart-HTTP + Redis-gecachter Laximo-Adapter | Natives HTTP; gleiche Backend-Latenz | Magento-Plugin oder WebView-Round-Trip — spürbar langsamer |
| Ergonomie der Lieferintegration | Einziger Dart-Client; mit dem Web geteilt | Zwei parallel zu pflegende Clients | Magento-Erweiterungen, fragile Upgrades |
| Verkäuferseitige Analysen | Backend-eigene, von Symfony gerenderte Dashboards | Gleiches Backend; identische Aufstellung | Magento-Business-Intelligence-Add-on — kostspielig |
| Iterationsgeschwindigkeit | Eine Dart-Codebasis, Hot-Reload-UX | Zwei Codebasen, doppelte QA | Risiko der Erweiterungskompatibilität je Release |
| Eignung für App-Store-Prüfung | Erstklassig — Käufer-App ist natives Binary | Erstklassig | Häufig als „Web-Wrapper“ markiert |
| Kontrolle über Datenlokalität | Betreiber-eigene Infrastruktur in US- oder EU-Regionen | Identische Aufstellung | Nur Magento-Commerce-Cloud-Regionskarte |
Quellen: Flutter-Dokumentation, Dokumentation des Symfony-Frameworks, PostgreSQL-Referenz zu Row-Level Security.

Das Verkäufer-CRM ist eine React-Single-Page-Application, gestützt auf ein mandantenfähiges Symfony-Backend. Jeder Verkäufer ist ein Mandant der obersten Ebene; jede Filiale — physisches Geschäft, regionales Lager — ist eine untergeordnete Entität innerhalb dieses Mandanten. PostgreSQL Row-Level Security erzwingt die Mandantenisolation, sodass ein Verkäufer eines Mandanten nicht den Bestand eines anderen lesen kann, und der käuferseitige Suchindex ist mandantenfähig, sodass ein Käufer ein einheitliches Ergebnis sieht, ohne die zugrunde liegende Mandantengrenze je zu bemerken. Wareneingang, standortbezogener Bestand, Preise, Geschäftspartner-Verifizierung und Bestellabläufe werden alle pro Filiale geführt und fließen in ein mandantenweites Dashboard zusammen, sodass ein Verkäufer mit Geschäften in mehreren Städten eine einheitliche Sicht erhält.
Die Geschäftspartner-Verifizierung verschafft dem Betreiber eine belastbare Grundlage dafür, wer auf dem Marktplatz verkaufen darf. Das CRM erfasst Geschäftsunterlagen während des Verkäufer-Onboardings, durchläuft sie über eine Verifizierungs-Queue (Dokumentenechtheit, Ablauf-Parsing, OCR-Konfidenz) mit einer Stufe für die menschliche Prüfung und schreibt je Verkäufer einen unveränderlichen Audit-Trail. Aufzeichnungen werden gemäß den lokalen handelsrechtlichen Anforderungen aufbewahrt — unterschiedlich in Kalifornien gegenüber den Niederlanden gegenüber dem Vereinigten Königreich — und im Ruhezustand mit Schlüsselrotation verschlüsselt. Die durchgängige Verkäuferoberfläche liefern wir im Rahmen unserer individuellen Softwareentwicklung.

Der Käufer-Client ist in Flutter mit einer einzigen Dart-Codebasis für iOS und Android umgesetzt. Die passwortlose Authentifizierung hält die Registrierungshürde niedrig — ein Käufer gibt eine Telefonnummer oder E-Mail-Adresse ein, erhält einen Einmalcode und ist innerhalb von Sekunden im Katalog. Die VIN-Suche ist der vorrangige Einstiegspunkt: Der Käufer gibt eine VIN ein oder wählt Marke und Modell, und die App ruft den VIN-Adapter-Dienst auf, der den Katalog im Laximo-Stil aufruft und die Ergebnisse über alle Mandanten hinweg mit dem verkäuferseitigen Bestand abgleicht. Das Ergebnis ist eine einheitliche Teileliste mit standortübergreifender Verfügbarkeit, verkäuferbezogenen Preisen und einem Ein-Tipp-„In den Warenkorb“, das im Hintergrund die Mandantenisolation wahrt.
Der Bestellablauf schließt den Kreislauf. Ein Käufer prüft den Warenkorb, wählt eine Lieferoption aus den integrierten Lieferanbietern und bestätigt — die Bestellung wird in das unveränderliche Audit-Log geschrieben, das Verkäufer-CRM nimmt die Bestellung über die betroffenen Filialen hinweg auf, und der Käufer erhält eine Push-Benachrichtigung, sobald jede Filiale versendet. Transatlantische Betreiber können einen Käufer in Kalifornien an einen US-Verkäufer und einen Käufer in Deutschland an einen niederländischen Verkäufer leiten, ohne dass der Käufer je eine Region wählt; das Datenmodell übernimmt das. Dasselbe Entwicklerteam liefert die Käufer-App und das Verkäufer-CRM Hand in Hand im Rahmen unserer Mobile App-Entwicklung.

Die Lieferintegration verwandelt eine Bestellung bei einem einzelnen Verkäufer in eine mehrteilige Auslieferung, ohne dass der Käufer darüber nachdenken muss. Jede Filiale übergibt über eine dünne Adapterschicht an ihren bevorzugten Lieferanbieter; das Backend verfolgt jeden Abschnitt über die Order-Workflow-Engine und schreibt Statusaktualisierungen in das unveränderliche Audit-Log. Käufer sehen eine einzige Tracking-Zeitleiste, die den Status der einzelnen Abschnitte zusammenfasst, und Verkäufer sehen im CRM eine Auslieferungsansicht je Filiale. Die Verkäufer-Analysen liegen im selben Symfony-Backend und erscheinen im CRM als nahezu echtzeitfähige Dashboards — verkaufte Einheiten je Filiale, durchschnittliche Auslieferungszeit, häufigste Suchbegriffe nach Region und Status der Geschäftspartner-Verifizierung über die Filialen des Mandanten hinweg.
Die Aufstellung zur Datenverarbeitung entspricht den DSGVO-Pflichten für Käufer und Verkäufer in der Europäischen Union und den CCPA-/CPRA-Pflichten für Nutzer in Kalifornien und den weiteren Vereinigten Staaten. Käuferdaten, Verkäuferdaten und das Bestell-Audit-Log lassen sich für künftige Zusagen zur Datenlokalität jeweils an US- oder EU-Regionen binden, und das mandantenfähige Modell setzt die Mandantenisolation auf der Datenbankebene statt auf der Anwendungsebene durch.
Compliance-Aufstellung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.
Ein fünfphasiges Projekt, das ZipIt von einer fragmentierten Beschaffung zu einem produktiven zweiseitigen Marktplatz über iOS, Android, Web und ein mandantenfähiges Verkäufer-CRM geführt hat.
Mapping der Käuferreise (Ausgangslage Beschaffung-per-Telefon), Erhebung der Verkäufer-Workflows, mandantenfähiges Datenmodell, Prüfung des US- und EU-Handels- und Datenschutzrechts, Evaluierung der VIN-Katalog-Anbieter.
Mandantenfähiges Symfony-Backend, PostgreSQL Row-Level Security, mandantenfähiger Suchindex, VIN-Adapter-Dienst, Spezifikation des Lieferanbieter-Adapters, unveränderliches Bestell-Audit-Log.
Flutter-Käufer-App für iOS und Android, React-Web-Käuferoberfläche, React-Verkäufer-CRM, VIN-Suche durchgängig, Warenkorb- und Bestellablauf, Verkäufer-Dashboards.
Pipeline zur Geschäftspartner-Verifizierung, im Ruhezustand verschlüsselte Daten, Tests der Mandantenisolation, QA der Lieferintegration, mandantenfähiger Lasttest bei prognostizierter Kataloggröße, Choreografie der Store-Prüfung.
Einreichung im App Store + Google Play in US- und EU-Storefronts, mandantenweiser Rollout, Choreografie des Verkäufer-Onboardings, On-Call-Runbooks für die VIN- und Lieferadapter.
Die verkäuferseitigen Analysen von ZipIt machen das CRM zu etwas, das ein Verkäufer den ganzen Tag geöffnet lässt — und nicht nur zu einem Ort, an dem einmal pro Woche Bestand hochgeladen wird. Symfony-gestützte Dashboards aggregieren verkaufte Einheiten je Filiale, durchschnittliche Auslieferungszeit je Lieferanbieter, häufigste Suchbegriffe je Region und den Status der Geschäftspartner-Verifizierung über die Filialen des Mandanten hinweg. Dieselben Daten speisen einen mandantenbezogenen Export, sodass ein Verkäufer mit Geschäften in den Niederlanden und in Deutschland den Abgleich mit seinem bestehenden Buchhaltungs-Workflow vornehmen kann, ohne für ein Magento-Business-Intelligence-Add-on zu zahlen. Die Mandantenmigration war von Tag eins an eingebaut — ein neuer Verkäufer kann sich onboarden, Bestand aus einem strukturierten Upload importieren, sich verifizieren lassen und innerhalb von Stunden statt Wochen auf dem Marktplatz live gehen, und ein bestehender Verkäufer kann Filialen zwischen Mandanten verschieben, wenn sich seine Unternehmensstruktur ändert, ohne den filialbezogenen Audit-Trail zu verlieren. Mandantenübergreifende Betreiber können ihre Sicht nach Region eingrenzen — so deckt ein einzelnes Back-Office-Team in ruhigen Schichten den Betrieb in den USA und der EU ab, ohne die mandantenbezogene Compliance-Grenze zu verlieren.
Die ZipIt-Plattform wurde für Automotive-Marktplatz-Betreiber konzipiert, die Käufer und Verkäufer in den Vereinigten Staaten und der Europäischen Union bedienen. Die englischsprachige Umsetzung bedient Nutzer in Kalifornien, New York, Texas, Florida und Washington in den USA sowie Nutzer in den Niederlanden, Deutschland, Frankreich, Irland und Schweden in der EU — ohne separate Codebasis je Region. Einwilligungsabläufe sind auf der Client-Ebene regionsbewusst: Nutzer in der EU und im EWR erhalten einen granularen Einwilligungsbildschirm im DSGVO-Stil mit getrennten Schaltern für Marketingkanäle und optionale Produktanalysen; Nutzer in Kalifornien erhalten im selben Ablauf einen Hinweis im CCPA-Stil („Do Not Sell or Share My Personal Information“). Die Datenverarbeitungspraktiken sind auf die DSGVO für europäische Nutzer und auf den Flickenteppich der US-Bundesstaaten-Datenschutzgesetze abgestimmt — CCPA / CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA. Aufzeichnungen zur Verkäufer-Geschäftspartner-Verifizierung werden gemäß den lokalen handelsrechtlichen Anforderungen aufbewahrt, und audit-fähige Bestelldatensätze machen die regionale Compliance zu einer Frage ehrlicher Offenlegung statt zu einem Problem der Datentrennung je Rechtsraum.
Das Backend wird parallel über EU- und US-Regionen betrieben — Niederlande, Deutschland, Frankreich, Schweden und Irland für die EU-Abdeckung; US East und US West für Nordamerika — wobei Symfony-Dienste und PostgreSQL-Instanzen identisch über Terraform bereitgestellt werden. Der Mandanten-Store und das Bestell-Audit-Log lassen sich für künftige Zusagen zur Datenlokalität jeweils an US- oder EU-Regionen binden, und die VIN- und Lieferadapter sind zustandslos, sodass sie je Region unabhängig skaliert werden können. Sowohl die Altersfreigabe im App Store als auch die Inhaltsbewertung in Google Play wurden für eine Marktplatz-App kalibriert, und die In-App-Datenschutzerklärung wurde so verfasst, dass sie genau die obige Architektur dokumentiert und direkt auf DSGVO-Pflichten und kalifornische CCPA-Pflichten verweist. Das Entwicklerteam hinter dem Projekt arbeitet einen MEZ-Arbeitstag mit Überlappung mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, die Choreografie der Store-Prüfung und die On-Call-Reaktion über transatlantische Verkäufer-Onboarding-Abläufe hinweg.
Die aktive Roadmap der individuellen Softwareentwicklung für ZipIt umfasst eine B2B-Stufe mit Bring-your-own-Domain und SSO für firmeneigene Flottenkäufer, eine tiefere Integration mit Buchhaltungs- und ERP-Systemen in den USA und der EU, ein internes Continuous-Verification-Harness für Mandantenisolations-Invarianten und einen zweiten VIN-Katalog-Adapter als Zweitquelle für Redundanz über die Regionen hinweg. Die Infrastrukturplanung umfasst ein weiteres mandantenbezogenes Sharding für den prognostizierten mandantenfähigen Durchsatz sowie eine künftige unabhängige Reifegradbewertung, die in die Roadmap für Cloud & DevOps eingebettet ist.
Wenn Sie einen Autoteile-Marktplatz, eine mandantenfähige B2B-Commerce-Plattform oder ein beliebiges zweiseitiges Produkt planen, bei dem das verkäuferseitige CRM einer Aufsichtsprüfung für Zielgruppen in den USA und der EU standhalten muss, haben wir diesen Stack durchgängig ausgeliefert und können den Entwicklungszeitraum spürbar verkürzen. Das Entwicklerteam dahinter sitzt innerhalb der YuSMP Group. Wir arbeiten zum Festpreis bei gut abgegrenzten MVPs und über dedizierte Entwicklerteams bei laufender 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 Reaktion auf Vorfälle.
Ein fokussiertes MVP mit einer Flutter-Käufer-App für iOS und Android, einer Web-Käuferoberfläche und einem mandantenfähigen Verkäufer-CRM mit Wareneingang und standortbezogenem Bestand kostet typischerweise 180k–340k $. Ergänzt man die VIN-basierte Teilesuche über eine Katalogintegration im Laximo-Stil, die integrierte Lieferübergabe, verkäuferseitige Analysen, die Geschäftspartner-Verifizierung und eine audit-fähige Aufstellung für Betreiber in den USA und der EU, kommt eine vollständige Plattform auf 360k–700k $. Die wichtigsten Kostentreiber sind die VIN-Katalog-Integration, das mandantenfähige Datenmodell und die verkäuferseitigen Analysen, die das CRM nahezu in Echtzeit pflegen muss.
Käufer-Apps für Autoteile sind Formular- und Katalogprodukte mit relativ geringer Plattformintegration — genau dort spielt Flutter seine Stärken aus. Eine einzige Dart-Codebasis liefert die Käufer-Apps für iOS und Android in einem Entwicklungsdurchlauf, geteilte Design-Tokens mit der Web-Käuferoberfläche und schnellere Iterationen an der Katalog-UI als zwei native Teams. Natives iOS und Android würden Kosten verursachen, ohne für VIN-Suche, Warenkorb und Bestellablauf einen entsprechenden Mehrwert zu liefern. Native Builds reservieren wir für Fälle, in denen kontinuierliche Standortermittlung, Push-Zuverlässigkeit oder Integration auf Kernel-Ebene die Spezifikation dominieren.
Ein mandantenfähiges CRM behandelt jeden Verkäufer als Mandanten der obersten Ebene und jede Filiale als untergeordnete Entität innerhalb dieses Mandanten. Bestand, Wareneingänge, Preise und Bestellabläufe werden pro Filiale geführt, fließen aber in ein mandantenweites Dashboard zusammen, sodass ein Verkäufer mit Geschäften in mehreren Städten eine einheitliche Sicht erhält. Symfony bildet den Mandanten-Store ab; die Row-Level-Filterung von PostgreSQL erzwingt die Mandantenisolation, und die Käufer-App liest die standortübergreifende Verfügbarkeit über einen mandantenfähigen Suchindex, sodass ein Käufer niemals ein Teil eines Verkäufers sieht, mit dem er nicht handeln kann.
Die VIN-Suche ist als dedizierter Adapter-Dienst umgesetzt, der einen Automotive-Katalog im Laximo-Stil aufruft und die Ergebnisse mit dem verkäuferseitigen Bestand abgleicht. Der Adapter übersetzt eine VIN in eine strukturierte Liste von Teilereferenzen, verteilt diese Referenzen auf den Verkäufer-Bestandsindex und liefert ein einheitliches Ergebnis mit standortübergreifender Verfügbarkeit und verkäuferbezogenen Preisen. Der Adapter cacht häufige VIN-Abfragen in Redis mit TTLs, die auf die Aktualisierungsfrequenz des Katalogs abgestimmt sind, und schreibt jede Abfrage in ein Audit-Log, sodass der Betreiber den Suchverkehr je Käufer für Analysen in den USA und der EU zuordnen kann.
Eine Flutter-Käufer-App für iOS und Android, eine Web-Käuferoberfläche und ein mandantenfähiges Symfony-Verkäufer-CRM mit Wareneingang und standortbezogenem Bestand benötigen für das MVP typischerweise 14–22 Wochen. Ergänzt man die VIN-basierte Teilesuche über einen Katalog im Laximo-Stil, die integrierte Lieferübergabe, Verkäufer-Analysen, die Geschäftspartner-Verifizierung und eine audit-fähige Aufstellung für Betreiber in den USA und der EU, kommen 8–14 Wochen hinzu. Die VIN-Katalog-Integration ist häufig der kritische Pfad, weil reale Katalog-APIs inkonsistente Teilereferenzen zurückgeben, die serverseitig abgeglichen werden müssen.
Verwandte Fälle
Drei-App-Taxi-Plattform — Fahrer, Fahrgast, Disponent — mit Echtzeit-GPS-Streaming und Dokumentenprüfung.
Fall ansehen → Retail · FashionRetail-Berater-App für Boutique-Bestände über Filialen hinweg — ElasticSearch-Suche, 1C-Integration, Reichweite über mehrere Geschäfte.
Fall ansehen → Retail · E-CommerceMobile App für einen lokalen Marktplatz einer Offline-Kette für Kinderwaren — flexibler Katalog, Online-Bestandsabgleich.
Fall ansehen →