PROJEKTSoftware & Automatisierung
Nomad X Collective
Multi-Vendor-Marktplatz für kuratierte Mode: Admin, Vendor-Panel und Storefront auf einer gemeinsamen Datenbasis.
3
Systeme auf einer Datenbasis
6
Zustände im Bestellzyklus
5
Bereiche im Vendor-Panel
Eine Software für einen Händler, ein Geschäft mit vielen Marken

Noch Mitte 2025 lief nomadxcollective.com auf einer Standard-Shopsoftware. Sie ist für einen Händler gebaut: ein Lager, ein Versandkonto, eine Person, die Preise pflegt. Das Geschäft dahinter war längst ein anderes. Nomad X Collective kuratiert unabhängige Marken, die ihre Herkunft mitverkaufen, jede mit eigenem Lager, eigenem Versandkonto und eigener Vorstellung davon, was über ein Kleidungsstück gesagt werden muss. Zwingt man diese Marken in ein System, das nur einen Händler kennt, tippt am Ende jemand alles ab, und jede Änderung wird zu einer E-Mail.
Der Auftrag lautete deshalb: drei verbundene Systeme, die sich wie eine Marke anfühlen und drei Nutzergruppen mit sehr unterschiedlichen Aufgaben bedienen.
- Plattformbetrieb: Bestellungen, Umsatz und Neuanmeldungen auf einen Blick, ohne dass jemand dafür eine Tabelle baut.
- Partnermarken: eigener Katalog, eigene Markenseite, eigene Fulfillment-Schritte, ohne Entwickler auf Abruf.
- Kundinnen und Kunden: ein Einkauf, der kuratiert wirkt und nicht wie eine Marktplatzvorlage.
Dazu kam der Zeitpunkt. Die Plattform sollte gemeinsam mit einem vollständigen Rebranding starten, die kundenseitige Oberfläche musste also eine neue visuelle Identität tragen, während darunter zum ersten Mal ein Marktplatz lief.






Eine Datenbasis, drei Oberflächen
Wir haben die Plattform als drei verbundene Systeme über einer gemeinsamen Datenbasis gebaut und den Gestaltungsaufwand ungleich verteilt. Die Storefront trägt das komplette Rebranding, Admin- und Vendor-Panel laufen auf einer schlankeren, funktionalen Basis-UI. Das ist eine Reihenfolge, keine Sparmaßnahme: Zuerst müssen die Abläufe darunter stimmen, denn ein schönes Vendor-Panel mit einem falschen Bestellstatus ist wertlos.
1. Geteilte Daten, getrennte Hoheit
- Produkte, Varianten, Bestände, Bestellungen und Kundendaten liegen in einer Datenbasis, die alle drei Systeme über dieselbe REST-Schnittstelle ansprechen.
- Die Hoheit über die Inhalte bleibt getrennt. Zugangsdaten für Marken entstehen zentral, damit das Onboarding an einer Stelle bleibt; die Marken- und Produktdaten einer Marke gehören danach ihr.
- Alle Bilder liegen in einem S3-Bucket in eu-central-1. Markenlogos und die Bilder der Markenseiten sind je Händler getrennt abgelegt, Produktbilder liegen in einem gemeinsamen Namensraum, weil sie am Produkt hängen und nicht an der Marke.
2. Der Import ist die eigentliche Übersetzungsarbeit
Marken bringen oft einen bestehenden Shop mit, etwa auf Shopify oder WordPress. Im Vendor-Panel steht dafür ein Knopf, der den Fremdshop anbindet. Der Import spart das Abtippen, das schwierigere Problem löst er nicht von allein. Zwei Shops beschreiben dasselbe Kleidungsstück unterschiedlich: Größen sind unterschiedlich benannt, Farbnamen sind Hausbezeichnungen, und was der eine Shop als zwei Produkte führt, ist beim anderen eine Variante desselben Produkts. Auf einem Marktplatz mit gemeinsamen Filtern muss daraus ein Vokabular werden, sonst zerfällt die Farbfilterung in Synonyme und findet nichts. Wie weit ein Abgleich reicht, hängt zusätzlich davon ab, was die jeweilige Fremdplattform über ihre API herausgibt. Das haben wir dem Kunden so gesagt, statt eine Vollsynchronisation zu versprechen.
3. Redaktion als Datensatz
Startseite, Über-uns, Kontakt, Footer, Partnerprogramm und Workshops sind je eine Konfiguration, die die Storefront zur Laufzeit lädt; Markenseiten sind ein eigener strukturierter Datensatz. Bilder, Texte und die Sichtbarkeit ganzer Abschnitte lassen sich damit ändern, ohne dass jemand deployt.

Versand ohne gemeinsames Carrier-Konto
Jede Partnermarke versendet von ihrem eigenen Standort über ihr eigenes Versandkonto. Es gibt also keinen gemeinsamen Sendungsstrom, den die Plattform auslesen könnte, und keinen Weg, den Zustellstatus serverseitig zu erfragen.
Das betrifft mehr als die Statusanzeige. Wenn der Versand bei der Marke liegt, wird aus einer Bestellung über zwei Marken zwangsläufig zweimal Versand: zwei Pakete, zwei Laufzeiten, zwei Tracking-Links. Der Warenkorb weist Versandkosten deshalb je Händler aus und summiert sie erst danach. Aus demselben Grund haben wir Retoure und Erstattung als eigenen Workflow modelliert. Eine Erstattung berührt gleichzeitig Bestand, Händlerauszahlung und Kundenkommunikation, und sie betrifft in der Regel einen Teil der Bestellung, nicht die ganze.
Der Ablauf ist entsprechend um die tatsächliche Versandbeziehung herum gebaut:
- Die Marke setzt ihren Teil der Bestellung auf „versandt“ und hinterlegt dabei den Tracking-Link, den ihr eigenes Konto erzeugt hat.
- Genau dieser Link geht automatisch als E-Mail hinaus.
- „Zugestellt“ bestätigt die Marke manuell, sobald sie es auf ihrer Seite sieht.
Ein automatischer Zustellstatus wäre an dieser Stelle nur geraten, und eine geratene Zusage ist schlechter als eine ehrliche Auskunft. Die Storefront sagt deshalb genau das, was das System weiß, und zwar dort, wo die Frage entsteht. Im Versandabschnitt der Produktseite steht „Each shipment is managed directly by our brand partners; therefore, costs and delivery times vary based on your location.“, und weiter unten im selben Abschnitt „Once your order has been dispatched, you will receive a tracking link via email.“

Die Storefront trägt das Rebranding
Die Storefront ist die Fläche, auf der aus der Markengeschichte ein Einkauf wird. Die Startseite hat eine feste Struktur aus Video-Hero, „Latest Arrivals“ und „Meet Our Brands“, deren Inhalte redaktionell gesetzt werden. Feste Struktur, freie Inhalte: Layout ohne Wildwuchs, Redaktion ohne Deployment.
1. Katalog
- Filter nach Kategorie, Marke und Farbe, Sortierung nach Neuheit und Preis, seitenweise Navigation mit 16 Artikeln je Seite.
- Größen und Farbvarianten liegen bereits in der Kachel, ebenso Merkzettel und Warenkorb. Wer bereits weiß, welche Größe und Farbe es sein soll, muss die Produktseite gar nicht öffnen.
- Warenkorb und Merkzettel funktionieren ohne Konto über eine serverseitige Gast-ID. Anmelden kann man sich per Passwort, Einmalcode oder Google.
2. Produktseite
Die Produktseite ist geschichtet. Unter Bild, Größe und Preis liegen aufklappbare Abschnitte, und welche das sind, entscheidet die Marke über ihre eigenen Inhalte. Eine mongolische Yak-Hose trägt einen eigenen Transparenzabschnitt mit Produktionsort; ein italienisch gefertigter Strick fasst Zusammensetzung, Herkunft und Pflege in einem Abschnitt zusammen und nennt dort seine Zertifizierung. Darunter steht die Marke mit Namen, Geschichte und einem Link auf ihre eigene Seite.
3. Markenseiten
Jede Partnermarke bekommt eine eigene Seite mit demselben Aufbau: Markengeschichte, die Blöcke Material Traceability, Production Process, Origins & Resources und Maintenance & Repair sowie die eigenen Produkte am Fuß. Herkunft wird damit zu einer Struktur im System, die jede Marke selbst füllt. Die Partnermarken füllen sie mit sehr unterschiedlichen Inhalten, von einem 1991 gegründeten mongolischen Hersteller bis zu einer in Italien gefertigten Strickkollektion.

Vendor-Panel: Selbstverwaltung statt Support-Ticket
Das Vendor-Panel gibt jeder Partnermarke einen eigenen Arbeitsbereich mit fünf Bereichen: Dashboard, Markenseite, Produktverwaltung, Bestellverwaltung und Einstellungen. Eine Marke soll eine Beschreibung ändern oder eine Bestellung als versandt markieren können, ohne dafür jemanden im Plattformteam zu beschäftigen.
1. Das Produkt ist eine Hülle, die Variante ist die Ware
Ein Produkt trägt Titel, Beschreibung und eine Basisvariante; verkauft wird immer eine Variante mit eigener SKU, eigenen Attributen für Größe und Farbe und eigenem Preis. Deshalb kann eine Marke eine Farbe teurer stellen als die andere und einzelne Varianten auf „nicht vorrätig“ laufen lassen, während das Produkt aktiv bleibt.
Der Bestand steht dabei nicht als eine Zahl, sondern als drei: Menge, davon reserviert, und daraus abgeleitet verfügbar. Diese Trennung ist der Unterschied zwischen einem Marktplatz, der zweimal dasselbe letzte Stück verkauft, und einem, der es nicht tut.
2. Zwei Entscheidungen prägen den Entwurf
- Onboarding ist ein Zustand, kein Formular. Der Fortschritt wird je Schritt gespeichert, also kann eine Marke die Einrichtung unterbrechen und später fortsetzen. Der Preis dafür ist, dass halbfertige Marken existieren dürfen: Sie müssen im System vorkommen, ohne im Katalog aufzutauchen.
- Der Versandschritt verlangt eine Eingabe. Der Tracking-Link ist die einzige Information im Bestellzyklus, die die Plattform nicht selbst hat, und deshalb der einzige Punkt darin, an dem das Panel etwas verlangt, bevor es weitergeht.
Für kleine, sehr bewusst arbeitende Hersteller entscheidet das darüber, ob Wachstum möglich ist, ohne nebenbei ein Logistikunternehmen zu führen.

Selbst schreiben, gegenlesen lassen
Kuratiert bleibt ein Marktplatz nur, wenn jemand gegenliest. Gleichzeitig darf dieses Gegenlesen nicht bedeuten, dass eine Marke für jede Bildunterschrift eine E-Mail schreibt. Wir haben das getrennt: Die Marke schreibt selbst, veröffentlicht aber nicht selbst.
Die Markenseite entsteht dafür im Panel als Konfiguration aus sechs Abschnitten, jeder einzeln bearbeitbar: Hero, Beschreibung, Info-Grid, Galerie, Pflege und Markenidentität. Der Hero nimmt wahlweise ein Bild oder ein Video, und der Alternativtext steht als eigenes Feld daneben statt als Nachgedanke, weil er sonst niemals entsteht.
Am Ende steht kein „Speichern“, sondern Submit For Approval. Damit existieren zwei Fassungen nebeneinander: die, an der die Marke gerade arbeitet, und die zuletzt freigegebene, die der Storefront ausliefert. Das Panel sagt beides an derselben Stelle, nämlich dass die Seite live ist und welche Fassung das ist. Produkte laufen durch denselben Mechanismus, deshalb steht in der Produktliste neben Titel und Varianten immer auch ein Freigabestatus.
Der Effekt ist, dass ein Tippfehler auf einer Markenseite nichts kostet und ein unabgestimmter Auftritt trotzdem nicht live geht. Der Preis ist eine Warteschlange, die jemand abarbeiten muss, und genau deshalb ist die Freigabe auf die Markenseite und den Produktkatalog beschränkt und nicht auf jede Bestandsänderung ausgeweitet.

Der Bestellzyklus, sichtbar für beide Seiten
Beide Panels sind um dieselben Kennzahlen herum gebaut: Bestellungen, Umsatz, aktuelle und offene Bestellungen. Wir haben mit dem Dashboard angefangen, weil die Frage nach Bestellungen und Umsatz vorher einen Export und eine Pivot-Tabelle gekostet hat.
Darunter liegt der eigentliche Gegenstand, der Bestellzyklus. Er kennt sechs Zustände, und die Verteilung darüber ist die erste Grafik, die eine Marke nach dem Anmelden sieht:
- Pending, Packed, Shipped, Delivered als der normale Weg. „Packed“ steht bewusst zwischen Eingang und Versand, weil zwischen beiden bei handgefertigter Ware Tage liegen können und eine Kundin sonst nicht erfährt, dass überhaupt etwas passiert.
- Cancelled und Refunded als die beiden Ausgänge. Sie sind keine Fehlerfälle, sondern Endzustände mit eigenen Folgen für Bestand und Auszahlung.
Daneben stehen die Aufgaben, die nur der Plattform gehören: Nutzer- und Händlerverwaltung mit Sperren und Entsperren, Bestellhistorie und CSV-Export für die Buchhaltung, der vollständige Zyklus einschließlich Retouren und Erstattungen sowie die Ausgabe der Zugangsdaten für neue Partnermarken.
Transaktionale E-Mails laufen über Brevo, damit Versandbestätigung, Rückgabe und Kontoanlage denselben Zustellweg nehmen und im Zweifel nachvollziehbar bleiben. Bei einem Marktplatz, dessen Sendungen aus mehreren Richtungen kommen, ist die E-Mail der einzige Kanal, den die Plattform vollständig kontrolliert.













Mehr entdecken


SIE HABEN EINE KOMPLEXE IDEE, DIE WIR UMSETZEN SOLLEN?
STARTEN SIE MIT EINEM DESIGN-THINKING-PILOT ODER EINEM BERATUNGSGESPRÄCH.