E-commerce die
verder durft

Waarom dit ertoe doet

In de praktijk zie je vaak dat een webshop niet stukgaat op “de shop”, maar op de randen eromheen: pricing uit het ERP, productdata uit het PIM, voorraad die via meerdere magazijnen vliegt, marketplaces die eigen eisen stellen. Wat mij opvalt is dat teams dan gaan plakken — nog een plug-in, nog een Zap — totdat kleine frictie grote risico’s wordt.

Wat headless en composable betekenen

Headless scheidt je frontend van je commerce-core. Composable gaat een stap verder: je stelt je landschap samen uit best-of-breed bouwstenen (MACH: microservices, API-first, cloud, headless). Dus: zoek kies je eigen search, promotions, CMS, en verwissel componenten zonder je hele winkel te verhuizen. Klinkt technisch — valt in stappen te doen.

Wanneer Shopify of WooCommerce wél en niet passen

We zeggen het vaker: Shopify en WooCommerce zijn krachtige keuzes. Zeker voor snelle validatie, D2C, of lean teams. Maar:

• Checkout-maatwerk, B2B-prijzen en multi-store worden al snel complexer dan “even een appje”.

• API-rate-limits, datamodellen en extensiepunten bepalen de rek in je roadmap.

• Beheersbaarheid (updates, plugin-conflicten) vraagt volwassen ontwikkelafspraken.

Hoe Spartner hierin werkt

Wij duwen niet richting “alles custom”, en ook niet richting “één suite lost alles op”. We ontwerpen een architectuur die bij je proces past, bouwen de ontbrekende schakel of integratielaag, en kiezen bewust welke capability je koopt, en welke je bouwt. Nou ja, zeg maar: slim investeren waar het rendeert.

• Signaal: veel handwerk tussen systemen, oplossing: event-gedreven integratielaag

• Signaal: backlog vol “kan niet in het platform”, oplossing: uitbreiding of headless stap

• Signaal: pieken breken de keten, oplossing: queueing, backpressure, fallbacks

• Signaal: B2B-use-cases, oplossing: autorisatie, contractprijzen, offerte-flows

Bouw bloksgewijs, niet als blok

E-commerce groeit grillig. Soms in stappen, soms met sprongen. Daarom werkt een composable benadering zo goed: je verdeelt verantwoordelijkheden over kleine, duidelijke services. Elk onderdeel doet één ding geweldig — en mag stuk gaan zonder het geheel mee te trekken. Klinkt wat stoïcijns, maar het brengt rust in je roadmap.

Je eigen domeingrenzen bewaken

• Commerce-core beheert cart, checkout, promotions en orders.

• ERP beheert prijzen, debiteuren en beschikbaarheid.

• PIM beheert productdata, varianten en media.

Zodra grenzen vervagen, krijg je spreadsheet-integraties en “even via support”. Dus niet doen, liever expliciet maken — met API-contracten die je versies.

Headless is geen doel op zich

Wat veel teams merken: headless lost niet alles op. Het geeft vrijheid aan je frontend-team en dwingt betere API’s af, maar vraagt ook extra discipline (versiebeheer, caching, SSR/ISR-keuzes). Dus begin pas wanneer je twee tot drie pijnpunten oplost: multi-brand, zware content, of UI-snelheid die je conversie kost.

Vendor lock-in, maar dan bewust

Geen lock-in bestaat niet. Je ruilt de ene afhankelijkheid voor de andere. De kunst is kiezen waar je wil vastzitten. Data-eigenaarschap en API-toegang zijn cruciaal; UI-details minder. Wil je morgen van search wisselen? Dan moet je vandaag al je query-contracten in eigen beheer hebben.

Klein beginnen, groot effect, weinig ruis

Een paar concrete ingrepen — getest in het veld — die stabiliteit en snelheid brengen zonder je platform om te gooien.

Maak je integraties idempotent

• Elke order, voorraadupdate en prijsregel krijgt een unieke key. Herhaalbare calls veroorzaken dan geen dubbele mutaties.

• Voeg een replay-mechanisme toe. Falen mag, verliezen niet.

Zet een event-bus neer

• Publiceer domain events (OrderPlaced, StockReserved) met schema-validatie.

• Laat systemen zich abonneren. Losjes koppelen voorkomt spaghetti-webhooks.

Scheid sync van async

• Prijzen en voorraad in cart? Real-time.

• Externe fulfilment of boeking? Async met statusupdates en deadlines.

Rate-limits? Ontschakel slim

• Respecteer platform-quota met token buckets en exponential backoff.

• Cache read-intensieve endpoints (bijv. productdetails) per scope en TTL.

Checkout-maatwerk zonder chaos

• Werk met extensies en guardrails (bijv. Shopify Functions / Scripts of Woo-hooks met tests).

• Houd businessregels centraal en platform-specifieke code dun.

Observability is geen luxe

• Zet trace-ID’s door de hele keten.

• Maak dashboards voor fouten per integratie, en alerts op backlog-groottes in je queues. Overigens, één goed dashboard scheelt tien stand-ups.

De verleiding van shortcuts en de prijs van perfectie

De ene organisatie blijft te lang plakken in apps en plug-ins. De andere wil álles zelf bouwen — en bouwt jaren aan basisfuncties die je ook had kunnen kopen. Tussen die twee ligt, eerlijk gezegd, de volwassen route.

Wanneer standaard winnen mag

• Commodity capabilities (auth, search basics, payments) koop je vaak beter in.

• Waar de markt sneller innoveert dan jij, kies je een partner met bewezen snelheid.

Wanneer maatwerk echt rendeert

• Unieke B2B-processen, contractprijzen, offerte-flows.

• Order-orchestratie over meerdere warehouses en carriers.

• Productconfiguratie met complexe logica.

Shopify en WooCommerce met beleid

Shopify Plus biedt krachtige enterprise-hooks, maar nog steeds met grenzen aan checkout en API-volumes. WooCommerce geeft je diepe vrijheid, maar vraagt discipline om “plugin-spaghetti” te vermijden. Dus ja, beide zijn top — mits je de échte beperkingen herkent en eromheen ontwerpt. Dat gezegd hebbende, soms is “een soort van” hybride de sweet spot: standaard platform, eigen integratielaag.