Het platform is niet het probleem, tot het dat wel is: signalen dat je je eCommerce-stack ontgroeid bent

De signalen dat je je eCommerce-platform ontgroeid bent, zijn echt. Toch worden weinig signalen in eCommerce zo vaak verkeerd gelezen, omdat twee heel verschillende problemen dezelfde symptomen geven. Een platform bezwijkt zelden met veel kabaal. Het remt je af: releases duren langer, workarounds stapelen zich op en de kosten om de stack draaiende te houden kruipen omhoog, tot ze ongemerkt hoger liggen dan wat vervangen zou kosten. Een platform ontgroeien is een trend, geen gebeurtenis. Maar een stijgende trend bewijst nog niet dat het platform je plafond is. Een groot deel van wat als ontgroeien voelt, is een probleem in je processen, in wie de eigenaar is of in je maatwerk, en dat volgt je naar elk nieuw platform. De vraag die ertoe doet is dus niet “wat zijn de signalen?”, want die somt elke gids al op. De vraag is: “zit dit in het platform, of verhuist het mee?”

Dit artikel vertrekt vanuit die vraag. Het gemiddelde stuk over dit onderwerp geeft je vijf of tien signalen en stuurt je richting een migratie. Dat klopt als het platform echt de beperking is, en het wordt duur als dat niet zo is. Hieronder lees je hoe ontgroeien er in de praktijk uitziet: als trend, niet als moment. Waarom het platform zo vaak de schuld krijgt van die trend, terwijl de echte oorzaak met je mee zou verhuizen. En hoe je die twee uit elkaar houdt voordat je een jaar en een budget steekt in het verplaatsen van een probleem in plaats van het op te lossen.

Hoe ontgroeien eruitziet, en de conclusie die voor de hand ligt

Bij elke webshop die zijn stack echt ontgroeid is, zie je dezelfde symptomen. Ze zijn echt, dus het loont om ze te benoemen. Een aanpassing die vroeger een dag kostte, kost nu een week. De webshop draait op een groeiende berg apps en maatwerkcode, op elkaar gestapeld om te repareren wat het platform zelf niet kan. Functies die het bedrijf nu nodig heeft, zijn onmogelijk of worden geoffreerd als groot project. Piekverkeer zet het systeem onder druk. Wat je elke maand kwijt bent aan licenties, apps en developeruren om alles stabiel te houden, stijgt jaar na jaar. Elk van deze punten is een terecht signaal dat er iets mis is.

De conclusie die voor de hand ligt, en waar de meeste artikelen over dit onderwerp naartoe werken, is dat het platform het plafond is geworden en dat je moet replatformen. Soms klopt dat precies. Maar die conclusie loopt voor het bewijs uit. Elk van die symptomen heeft meer dan één mogelijke oorzaak, en maar een deel van die oorzaken ligt bij het platform. Een webshop kan ze allemaal vertonen terwijl hij draait op een platform dat prima aankan wat het bedrijf nodig heeft. Wat hem dan tegenhoudt, is hoe hij is ingericht, wie de eigenaar is of wat er bovenop is gebouwd. Wie het symptoom als bewijs voor de oorzaak ziet, steekt een jaar en een flink budget in een migratie naar een nieuw platform. En merkt daar dat dezelfde traagheid al op hem wacht, omdat wat het team echt afremde gewoon mee is verhuisd.

Ontgroeien is een trend, geen gebeurtenis

De eerste correctie: wacht niet op een moment, maar kijk naar de lijn. Niemand wordt op een ochtend wakker en is zijn platform ineens ontgroeid. Het platform dat twee jaar geleden paste, past elk kwartaal een beetje minder. De catalogus groeit, er komen kanalen bij, het team wordt groter en de eisen gaan verder dan de oorspronkelijke inrichting ooit voorzag. Die verschuiving gaat geleidelijk, en daarom mis je hem makkelijk tot hij ernstig is. Geen enkele dag is duidelijk slechter dan de dag ervoor, dus de achteruitgang verstopt zich achter het uitblijven van een crisis.

Het signaal dat je wilt volgen is dus het tempo waarin iets verandert, geen drempel. Worden releases kwartaal na kwartaal trager, of is het dit kwartaal gewoon druk? Groeit de stapel workarounds, of had je er altijd al een paar? Kruipen de totale kosten om de stack draaiende te houden richting de kosten van vervangen, of blijven ze gelijk? Tel daarbij licenties, apps en de developeruren die naar onderhoud gaan in plaats van naar bouwen. Wat een ouder wordende stack echt kost, staat zelden op de factuur van het platform. Je ziet het in de engineering-backlog, in hoe lang een lancering duurt en in omzet die je misloopt omdat de webshop nog niet kan wat het moment vraagt. Meet je ontgroeien als trend, dan zie je het terwijl je nog tijd hebt om weloverwogen te handelen in plaats van in paniek. Maar de lijn meten vertelt je alleen dát er iets slechter wordt. Niet wat.

Het platform is niet het probleem, tot het dat wel is

Hier komt de andere blik die de titel belooft, en de reden dat deze diagnose lastiger is dan een checklist. Een trage webshop die steeds verder afglijdt en aan elkaar hangt van workarounds, voelt onmiskenbaar als een grens van het platform. Toch geven drie andere oorzaken bijna precies dezelfde symptomen als een echt plafond van het platform. En geen van die drie los je op met replatformen.

De eerste is een probleem in proces en eigenaarschap. Als niemand duidelijk eigenaar is van de webshop, goedkeuringen eindeloos blijven hangen en het marketingteam niet zelf de aanpassingen kan doen die het zou moeten kunnen doen, dan worden releases trager en groeit de frustratie. Het platform krijgt de schuld van wat eigenlijk een werkwijze is. Een nieuw platform geeft je organisatie geen besluitvorming cadeau. Dat is een keuze die je maakt, geen software die je installeert, en als het proces niet verandert, verhuist de traagheid gewoon mee. De tweede is maatwerkschuld die je zelf hebt opgebouwd. Een webshop die zwaar is aangepast tegen de natuurlijke werking van het platform in, wordt duur om te veranderen. Elke update moet kloppen met de maatwerkcode eromheen. Die kosten lijken een beperking van het platform, maar ze zijn de prijs voor het feit dat je eerder tegen het platform in hebt gewerkt. Bouw je dezelfde maatwerklaag opnieuw op een nieuw platform, dan bouw je dezelfde schuld opnieuw op. De derde is een integratie- en dataprobleem in de systemen rond de storefront: een ERP dat niet aansluit, productdata zonder één bron van waarheid. Dat wordt vaak aangezien voor een grens van de storefront, terwijl het achter elke storefront zou blijven bestaan. Replatformen om te ontsnappen aan een probleem dat meeverhuist, is een van de duurste fouten in eCommerce. Juist omdat het de hele tijd als vooruitgang voelt, zolang je ermee bezig bent.

Echt ontgroeid of een probleem dat meeverhuist: zo zie je het verschil

Eén eerlijke vraag scheidt de twee: zou een competent team, op het platform dat het best bij je bedrijf past, tegen dezelfde muur aanlopen? Is het antwoord ja, dan is de beperking structureel en is het platform echt het plafond. Is het antwoord nee, dan verhuist de beperking mee. Overstappen verplaatst hem dan, maar haalt hem niet weg.

Leg je die vraag langs elk symptoom, dan heb je snel een antwoord. Een functie die je niet live krijgt: houdt de architectuur van het platform hem tegen, of de maatwerkcode die je erbovenop hebt gebouwd? Traagheid: zit die in de architectuur, in hoe het platform pagina's serveert, of is het een opeenstapeling van apps en ongeoptimaliseerd maatwerk dat je kunt opruimen? Een workaround: bestaat die omdat het platform het echt niet kan, of omdat niemand ooit verantwoordelijk was voor een goede oplossing? Stijgende kosten: is het de prijs van het platform op jouw schaal, of zijn het de developeruren die je eigen maatwerk nu opslokt? De structurele oorzaken zijn echt, en ze zijn de legitieme redenen om over te stappen: een platform dat het bedrijfsmodel waar je naartoe gaat niet aankan, een architectuur die de prestaties begrenst hoe je ook tunet, een platform dat end-of-life is of geen beveiligingsupdates meer krijgt. De redenen waarom een groeiend merk echt naar Shopify Plus moet zijn in precies die zin structureel: een wholesalekanaal dat echte B2B-infrastructuur nodig heeft, internationale uitbreiding die aan de regels voldoet, abonnementen die het basisplan niet toelaat. Hoeveel je ook aan je processen sleutelt, de huidige inrichting gaat dat niet doen. De oorzaken die meeverhuizen, zoals proces, eigenaarschap, zelf opgebouwde maatwerkschuld en systemen die slecht op elkaar aansluiten, los je op waar ze zitten. Een migratie neemt ze namelijk ongeschonden over.

Als het echt het platform is: het kantelpunt herkennen

Leg de trend en de structurele test naast elkaar, en de beslissing komt neer op een kantelpunt met twee voorwaarden. Aan allebei moet voldaan zijn. De eerste is economisch: alles wat de huidige stack kost, inclusief de workarounds, de backlog die hij veroorzaakt en de omzet die je erdoor misloopt, is hoger geworden dan wat vervangen kost. De tweede gaat over de oorzaak: wat die kosten veroorzaakt is structureel, het platform zelf, en niet een van de problemen die bij een overstap gewoon meeverhuizen. Geldt alleen de eerste voorwaarde, dan heb je een duur probleem dat een replatform misschien niet oplost. Gelden ze allebei, dan is het platform echt het plafond geworden en kost eromheen blijven werken elk kwartaal meer dan overstappen.

Daar draait de titel om: het platform was niet het probleem, tot het probleem niet meer meeverhuisde maar in het platform zelf zat, en de cijfers tegelijk kantelden. Dat punt bereiken is geen planningsfout. Het is wat groei doet met een stack die ooit paste. Neem een merk dat retail, wholesale en meerdere markten draait op een inrichting die gebouwd is voor één kanaal en één land. Zo'n bedrijf is zijn platform echt ontgroeid. Het wordt niet tegengehouden door een proces dat het kan repareren of maatwerk dat het kan schrappen, en voor een bedrijf op dat punt is een replatform een fors en weloverwogen project dat je juist voor dit geval bewaart. Dat patroon zie je terug in doordachte replatformtrajecten met merken waarvan de operationele complexiteit de oorspronkelijke build ontgroeide, Mason Garments is er een van. Daar werd de overstap gemaakt omdat het platform echt de beperking was geworden, niet omdat een traag kwartaal het verleidelijk maakte. Lees de lijn, sluit de oorzaken uit die meeverhuizen, bepaal waar het kantelpunt ligt, en de beslissing om te replatformen is geen reactie op symptomen meer. Het wordt een diagnose die je kunt verdedigen.

Staat de diagnose, dan is de volgende stap kiezen tussen overstappen, herbouwen of blijven, want een ontgroeide bouw en een ontgroeid platform vragen om een ander antwoord.

Veelgestelde vragen

Wat zijn de signalen dat je je eCommerce-platform ontgroeid bent?

De bekende signalen zijn trage releases, een groeiende stapel apps en maatwerk-workarounds, functies die het bedrijf nodig heeft maar niet live krijgt, problemen bij piekverkeer en onderhoudskosten die elk jaar stijgen. Die signalen zijn echt, maar het zijn symptomen met meer dan één oorzaak. Ze kunnen komen van een echte grens van het platform, maar ook van een probleem in proces, maatwerk of integraties. De signalen alleen vertellen je dus niet of replatformen de oplossing is.

Ontgroei je een platform plotseling of geleidelijk?

Bijna altijd geleidelijk. Een platform bezwijkt zelden in één dramatisch moment. Het past elk kwartaal een beetje minder, naarmate catalogus, kanalen, team en eisen verder groeien dan de oorspronkelijke inrichting voorzag. Omdat geen enkele dag veel slechter is dan de vorige, mis je de achteruitgang makkelijk tot hij ernstig is. Het betrouwbare signaal is de trend: worden releases, workarounds en kosten in de loop van de tijd slechter? Niet één losse drempel.

Hoe weet je of het aan het platform ligt of aan je eigen inrichting?

Vraag je af of een competent team op het best passende platform tegen dezelfde muur zou aanlopen. Zo ja, dan is de beperking structureel en is het platform echt het plafond. Zo nee, dan verhuist het probleem mee: het komt uit je processen, je eigenaarschap, je maatwerkcode of de koppelingen tussen je systemen, en een nieuw platform erft het gewoon. Toets elk symptoom zo. Blokkeert het platform de functie of doet je maatwerk dat? Zit de traagheid in de architectuur of in wat zich in de loop der jaren heeft opgestapeld?

Wanneer is replatformen de moeite waard?

Als aan twee voorwaarden tegelijk is voldaan. Ten eerste: blijven kost inmiddels meer dan het platform vervangen, als je workarounds, de engineering-backlog en misgelopen omzet meetelt. Ten tweede: de beperking die die kosten veroorzaakt is structureel, het platform zelf, en geen proces- of maatwerkprobleem dat meeverhuist. Geldt alleen de kostenvoorwaarde, dan lost een replatform de oorzaak misschien niet op. Gelden ze allebei, dan kost blijven elk kwartaal meer dan overstappen.

Lost replatformen trage releases en workarounds op?

Alleen als het platform de oorzaak is. Komen trage releases uit een werkwijze zonder duidelijke eigenaar, of bestaan workarounds omdat maatwerk het platform duur maakte om te veranderen, dan neemt een migratie die oorzaken mee. Op de nieuwe software krijg je dan dezelfde symptomen. Replatformen lost beperkingen op die in de architectuur van het platform zitten. Problemen in je processen, je maatwerkkeuzes of de systemen eromheen lost het niet op.

De belangrijkste punten

• De signalen dat je een platform ontgroeit zijn echt, maar makkelijk verkeerd te lezen. Een echte grens van het platform en een probleem in proces, maatwerk of integraties geven bijna dezelfde symptomen.

• Ontgroeien is een trend, geen gebeurtenis. Kijk of releases, workarounds en de kosten om alles draaiende te houden in de loop van de tijd slechter worden. Wacht niet op een crash of op die ene functie die niet kan.

• Het platform krijgt vaak de schuld, terwijl de echte oorzaak meeverhuist: een probleem in proces en eigenaarschap, maatwerkschuld die je zelf hebt opgebouwd, of een integratie- en dataprobleem in de systemen eromheen.

• De test is één eerlijke vraag: zou een competent team op het best passende platform tegen dezelfde muur aanlopen? Ja betekent structureel, en dan is het platform het plafond. Nee betekent dat het probleem met je meeverhuist.

• Replatform als aan beide voorwaarden is voldaan: blijven kost meer dan overstappen, en de beperking is structureel in plaats van dat ze meeverhuist. Wie overstapt om te ontsnappen aan een probleem dat meeverhuist, verplaatst het alleen. Weg is het niet.

“Het platform is niet het probleem, tot het dat wel is” is de moeite van onthouden, omdat beide helften kloppen en de meeste adviezen er maar één vasthouden. Sceptici die elk replatform een overreactie vinden, missen het moment waarop de verschuiving echt structureel wordt en blijven duur wordt. Enthousiastelingen die elk traag kwartaal zien als bewijs dat het platform op zijn grens zit, missen hoe vaak de echte beperking er een is die een migratie gewoon meeneemt. Volg de lijn, scheid wat structureel is van wat meeverhuist en bepaal waar het kantelpunt ligt. Dan weet je in welke helft je zit. En dat is precies wat een lijstje signalen je nooit vertelt.