PROJECTSoftware & automatisering

Nomad X Collective

Multi-vendor-marktplaats voor gecureerde mode: admin, vendorpaneel en storefront op één gedeelde databasis.

3

Systemen op één databasis

6

Toestanden in de bestelcyclus

5

Onderdelen in het vendorpaneel

JAAR
2026
TEAM
Yashi, Kunal (Technical Lead), Tushar, Shakti
TECH-STACK
React + Vite, Node.js/Express, AWS S3 (eu-central-1), Brevo, Figma
LOCATIE
Berlin, Duitsland
GEPUBLICEERD
10 aug 2026

Eén software voor één handelaar, een zaak met veel merken

Merkenoverzicht met de lijst van partnermerken

Nog midden 2025 draaide nomadxcollective.com op standaard shopsoftware. Die is gebouwd voor één handelaar: één magazijn, één verzendaccount, één persoon die de prijzen bijhoudt. De zaak erachter was allang een andere. Nomad X Collective cureert onafhankelijke merken die hun herkomst mee verkopen, elk met een eigen magazijn, een eigen verzendaccount en een eigen idee van wat er over een kledingstuk gezegd moet worden. Worden deze merken in een systeem gedwongen dat maar één handelaar kent, dan tikt uiteindelijk iemand alles over en wordt elke wijziging een e-mail.

De opdracht luidde daarom: drie verbonden systemen die aanvoelen als één merk en drie gebruikersgroepen met zeer uiteenlopende taken bedienen.

  • Platformbeheer: bestellingen, omzet en nieuwe aanmeldingen in één oogopslag, zonder dat iemand daarvoor een spreadsheet bouwt.
  • Partnermerken: een eigen catalogus, een eigen merkpagina, eigen fulfilmentstappen, zonder ontwikkelaar op afroep.
  • Klanten: een aankoop die gecureerd aanvoelt en niet als een marktplaatssjabloon.

Daar kwam het tijdstip bij. Het platform moest samen met een volledige rebranding lanceren, de klantzijde moest dus een nieuwe visuele identiteit dragen, terwijl eronder voor het eerst een marktplaats draaide.

Catalogus met de filters op categorie, merk en kleur en de sorteringCatalogus gefilterd op de kleur zwart, met het actieve filter en herstellenProductpagina met maatkeuze, prijs en vier uitklapbare sectiesProductbeheer in het vendorpaneel met goedkeuringsstatus, varianten en een actiefschakelaar per productHomepage met de secties Latest Arrivals en Meet Our BrandsMerkpagina met Production Process, een productrij en Maintenance and Repair

Één databasis, drie interfaces

Wij hebben het platform gebouwd als drie verbonden systemen boven één gemeenschappelijke databasis en de ontwerpinspanning ongelijk verdeeld. De storefront draagt de volledige rebranding, het admin- en het vendorpaneel draaien op een soberdere, functionele basis-UI. Dat is een volgorde, geen bezuiniging: eerst moeten de processen eronder kloppen, want een mooi vendorpaneel met een verkeerde bestelstatus is waardeloos.

1. Gedeelde data, gescheiden zeggenschap

  • Producten, varianten, voorraden, bestellingen en klantgegevens liggen in één databasis, die alle drie de systemen via dezelfde REST-interface aanspreken.
  • De zeggenschap over de inhoud blijft gescheiden. Inloggegevens voor merken worden centraal aangemaakt, zodat het onboarden op één plek blijft; de merk- en productgegevens van een merk zijn daarna van dat merk.
  • Alle afbeeldingen liggen in één S3-bucket in eu-central-1. Merklogo's en de afbeeldingen van de merkpagina's worden per handelaar apart opgeslagen, productafbeeldingen liggen in een gedeelde naamruimte, omdat ze aan het product hangen en niet aan het merk.

2. De import is het eigenlijke vertaalwerk

Merken brengen vaak een bestaande shop mee, bijvoorbeeld op Shopify of WordPress. In het vendorpaneel zit daarvoor een knop die de externe shop koppelt. De import bespaart het overtypen, het lastigere probleem lost hij niet vanzelf op. Twee shops beschrijven hetzelfde kledingstuk verschillend: maten zijn anders benoemd, kleurnamen zijn eigen huisbenamingen, en wat de ene shop als twee producten voert, is bij de andere een variant van hetzelfde product. Op een marktplaats met gedeelde filters moet daar één vocabulaire van worden, anders valt de kleurfiltering uiteen in synoniemen en vindt niets. Hoe ver een afstemming reikt, hangt bovendien af van wat het betreffende externe platform via zijn API vrijgeeft. Dat hebben wij de klant zo gezegd, in plaats van een volledige synchronisatie te beloven.

3. Redactie als dataset

Startpagina, Over ons, Contact, footer, partnerprogramma en workshops zijn elk een configuratie die de storefront tijdens runtime laadt; merkpagina's vormen een eigen gestructureerde dataset. Afbeeldingen, teksten en de zichtbaarheid van hele secties zijn daarmee te wijzigen zonder dat iemand deployt.

Ontwerpcanvas met de paginasjablonen voor storefront, merkpagina, partnerprogramma en accountinstellingen

Verzending zonder gedeeld vervoerdersaccount

Elk partnermerk verzendt vanaf zijn eigen locatie via zijn eigen verzendaccount. Er is dus geen gedeelde zendingenstroom die het platform zou kunnen uitlezen, en geen manier om de bezorgstatus serverzijdig op te vragen.

Dat raakt meer dan de statusweergave. Ligt de verzending bij het merk, dan wordt een bestelling bij twee merken onvermijdelijk tweemaal verzending: twee pakketten, twee doorlooptijden, twee trackinglinks. De winkelwagen vermeldt verzendkosten daarom per handelaar en telt ze pas daarna op. Om dezelfde reden hebben wij retour en terugbetaling als een eigen workflow gemodelleerd. Een terugbetaling raakt tegelijk de voorraad, de uitbetaling aan de handelaar en de klantcommunicatie, en zij betreft in de regel een deel van de bestelling, niet de hele.

De procesgang is dienovereenkomstig rond de feitelijke verzendrelatie gebouwd:

  1. Het merk zet zijn deel van de bestelling op "verzonden" en legt daarbij de trackinglink vast die zijn eigen account heeft aangemaakt.
  2. Precies die link gaat automatisch als e-mail de deur uit.
  3. "Bezorgd" bevestigt het merk handmatig, zodra het dat aan zijn kant ziet.

Een automatische bezorgstatus zou hier alleen maar gegokt zijn, en een gegokte toezegging is slechter dan een eerlijke mededeling. De storefront zegt daarom precies wat het systeem weet, en wel daar waar de vraag ontstaat. In de verzendsectie van de productpagina staat "Each shipment is managed directly by our brand partners; therefore, costs and delivery times vary based on your location.", en verderop in dezelfde sectie "Once your order has been dispatched, you will receive a tracking link via email."

Productpagina met kleurvarianten, maatkeuze en de secties samenstelling en verzending

De storefront draagt de rebranding

De storefront is het vlak waarop het merkverhaal een aankoop wordt. De startpagina heeft een vaste structuur van videohero, "Latest Arrivals" en "Meet Our Brands", waarvan de inhoud redactioneel wordt gezet. Vaste structuur, vrije inhoud: lay-out zonder wildgroei, redactie zonder deployment.

1. Catalogus

  • Filters op categorie, merk en kleur, sortering op nieuwheid en prijs, paginagewijze navigatie met 16 artikelen per pagina.
  • Maten en kleurvarianten zitten al in de tegel, net als verlanglijst en winkelwagen. Wie al weet welke maat en kleur het moet worden, hoeft de productpagina helemaal niet te openen.
  • Winkelwagen en verlanglijst werken zonder account via een serverzijdige gast-ID. Aanmelden kan met een wachtwoord, een eenmalige code of Google.

2. Productpagina

De productpagina is gelaagd. Onder afbeelding, maat en prijs liggen uitklapbare secties, en welke dat zijn, bepaalt het merk via zijn eigen inhoud. Een Mongoolse yakbroek draagt een eigen transparantiesectie met productielocatie; een in Italië gemaakt breisel vat samenstelling, herkomst en onderhoud samen in één sectie en noemt daar zijn certificering. Daaronder staat het merk met naam, geschiedenis en een link naar zijn eigen pagina.

3. Merkpagina's

Elk partnermerk krijgt een eigen pagina met dezelfde opbouw: merkgeschiedenis, de blokken Material Traceability, Production Process, Origins & Resources en Maintenance & Repair alsook de eigen producten onderaan. Herkomst wordt daarmee een structuur in het systeem die elk merk zelf vult. De partnermerken vullen die met zeer uiteenlopende inhoud, van een in 1991 opgerichte Mongoolse fabrikant tot een in Italië gemaakte breicollectie.

Storefront op een smalle viewport met eigen navigatie

Vendorpaneel: zelfbeheer in plaats van supportticket

Het vendorpaneel geeft elk partnermerk een eigen werkomgeving met vijf onderdelen: dashboard, merkpagina, productbeheer, bestelbeheer en instellingen. Een merk moet een beschrijving kunnen wijzigen of een bestelling als verzonden kunnen markeren, zonder daarvoor iemand in het platformteam bezig te houden.

1. Het product is een omhulsel, de variant is de waar

Een product draagt titel, beschrijving en een basisvariant; verkocht wordt altijd een variant met een eigen SKU, eigen attributen voor maat en kleur en een eigen prijs. Daarom kan een merk de ene kleur duurder zetten dan de andere en afzonderlijke varianten op "niet op voorraad" laten lopen, terwijl het product actief blijft.

De voorraad staat daarbij niet als één getal, maar als drie: aantal, daarvan gereserveerd, en daaruit afgeleid beschikbaar. Dat onderscheid is het verschil tussen een marktplaats die hetzelfde laatste stuk twee keer verkoopt, en een die dat niet doet.

2. Twee beslissingen bepalen het ontwerp

  • Onboarden is een toestand, geen formulier. De voortgang wordt per stap opgeslagen, dus een merk kan de inrichting onderbreken en later voortzetten. De prijs daarvoor is dat half afgeronde merken mogen bestaan: zij moeten in het systeem voorkomen zonder in de catalogus te verschijnen.
  • De verzendstap vereist een invoer. De trackinglink is de enige informatie in de bestelcyclus die het platform niet zelf heeft, en daarom het enige punt daarin waar het paneel iets verlangt voordat het verdergaat.

Voor kleine, zeer bewust werkende fabrikanten bepaalt dat of groei mogelijk is zonder er een logistiek bedrijf naast te runnen.

Productdetail in het vendorpaneel met de variantenlijst, attributen en voorraad verdeeld in aantal, gereserveerd en beschikbaar

Zelf schrijven, laten nalezen

Een marktplaats blijft alleen gecureerd als iemand naleest. Tegelijk mag dat nalezen niet betekenen dat een merk voor elk bijschrift een e-mail schrijft. Wij hebben dat gescheiden: het merk schrijft zelf, maar publiceert niet zelf.

De merkpagina ontstaat daarvoor in het paneel als een configuratie van zes secties, elk afzonderlijk te bewerken: hero, beschrijving, infogrid, galerij, onderhoud en merkidentiteit. De hero neemt naar keuze een afbeelding of een video, en de alternatieve tekst staat als een eigen veld ernaast in plaats van als nagedachte, omdat hij anders nooit ontstaat.

Aan het einde staat geen "Opslaan", maar Submit For Approval. Daarmee bestaan er twee versies naast elkaar: die waaraan het merk op dat moment werkt, en de laatst vrijgegeven versie, die de storefront uitlevert. Het paneel zegt beide op dezelfde plek, namelijk dat de pagina live is en welke versie dat is. Producten lopen door hetzelfde mechanisme, daarom staat in de productlijst naast titel en varianten altijd ook een vrijgavestatus.

Het effect is dat een typefout op een merkpagina niets kost en een niet-afgestemd optreden toch niet live gaat. De prijs is een wachtrij die iemand moet afwerken, en juist daarom is de vrijgave beperkt tot de merkpagina en de productcatalogus en niet uitgebreid tot elke voorraadwijziging.

Configuratie van de merkpagina in het vendorpaneel met sectietabs, alt-tekst en indienen ter goedkeuring

De bestelcyclus, zichtbaar voor beide kanten

Beide panelen zijn rond dezelfde kerncijfers gebouwd: bestellingen, omzet, actuele en openstaande bestellingen. Wij zijn met het dashboard begonnen, omdat de vraag naar bestellingen en omzet eerder een export en een draaitabel kostte.

Daaronder ligt het eigenlijke onderwerp, de bestelcyclus. Hij kent zes toestanden, en de verdeling daarover is de eerste grafiek die een merk na het aanmelden ziet:

  • Pending, Packed, Shipped, Delivered als de normale weg. "Packed" staat bewust tussen binnenkomst en verzending, omdat daar bij handgemaakte waar dagen tussen kunnen liggen en een klant anders niet verneemt dat er überhaupt iets gebeurt.
  • Cancelled en Refunded als de twee uitgangen. Het zijn geen foutgevallen, maar eindtoestanden met eigen gevolgen voor voorraad en uitbetaling.

Daarnaast staan de taken die alleen aan het platform toebehoren: gebruikers- en handelaarsbeheer met blokkeren en deblokkeren, bestelhistorie en CSV-export voor de boekhouding, de volledige cyclus inclusief retouren en terugbetalingen alsook de uitgifte van de inloggegevens voor nieuwe partnermerken.

Transactionele e-mails lopen via Brevo, zodat verzendbevestiging, retour en accountaanmaak dezelfde bezorgweg nemen en in geval van twijfel navolgbaar blijven. Bij een marktplaats waarvan de zendingen uit meerdere richtingen komen, is de e-mail het enige kanaal dat het platform volledig beheert.

Vendordashboard met de kerncijfers en de verdeling over de zes bestelstatussen

Meer ontdekken

HEEFT U EEN COMPLEX IDEE DAT U DOOR ONS WILT LATEN UITVOEREN?
START MET EEN DESIGN-THINKING PILOT OF EEN ADVIESGESPREK.

Neem contact met ons op

Alan Kay

“De beste manier om de toekomst te voorspellen, is haar uit te vinden.”