Toen doorbouwen duurder werd
dan opnieuw beginnen.
RoPa Workwear levert werkkleding aan bedrijven. Wat ze nodig hadden bestond niet kant en klaar, dus was er in de loop van de jaren van alles omheen gebouwd. Op een gegeven moment raakte elke aanpassing drie andere dingen, en werd nog een plugin erbij duurder dan het in één keer goed doen.
Zeven plugins die elkaar in de weg zaten.
Wat RoPa nodig had, bestond niet kant en klaar. Dus was het er in de loop van de jaren omheen gebouwd: een plugin voor de productimport, een voor de branding, een voor het klantportaal, een voor de totaalpakketten, en zo verder tot er zeven waren. Elk stuk deed zijn werk. Samen waren ze een systeem dat niemand meer in één keer kon overzien.
Elke wijziging raakte er drie. De importer wist dingen die het portaal ook wist, de branding-plugin hing aan de filters, en wie een categorie wilde aanpassen moest op vier plekken kijken. Dat is geen kritiek op hoe het gebouwd is: elk stuk is ooit gemaakt omdat er iets moest. Maar opgeteld werd doorbouwen duurder dan opnieuw beginnen.
Wat er kant en klaar niet was, is precies wat een zakelijke klant nodig heeft. Kledingbudget per medewerker, maten die vastliggen per persoon, een aanvraag die langs de manager gaat, en een logo dat op de rug anders is dan op de borst. Dat zijn geen instellingen in een webshop, dat is een systeem.
Productimport, filters, branding, klantportaal, totaalpakketten, chatbot en AI-content. Zeven stukken die elk hun werk deden en samen een systeem vormden dat niemand meer in één keer kon overzien. Vervangen door één shop waarin dat allemaal één ding is.
Van zeven losse stukken naar één systeem.
Opnieuw bouwen is zelden het goedkoopste antwoord. Hier was het dat wel, omdat elke aanpassing anders drie andere plugins raakte.
Zeven plugins, een trage shop en een onzichtbaar assortiment
Elke wijziging raakte iets anders. De shop was traag, en het assortiment stond niet in de HTML waar een zoekmachine het kan lezen.
Het kledingmanagementsysteem als hart
Alles opnieuw op Next.js en Supabase, met de zakelijke klant als uitgangspunt: budgetten, medewerkers en goedkeuringen zitten in de kern, niet eromheen.
Sneller, leesbaar en uit te leggen
Eén systeem in plaats van zeven, met het kledingbeheer in de kern. En een bouwfout in ons eigen werk die we hebben gemeten, opgelost en dichtgezet met een test.
Vier stukken die de shop dragen.
Het beheer van kleding per medewerker, de personalisatie, de catalogus en de vindbaarheid.
Kledingbudget per medewerker, per jaar
Bij een zakelijke klant bestelt niet één inkoper, maar bestelt iedereen. Daarom krijgt elke medewerker een eigen jaarbudget en een eigen omgeving. Wat binnen het budget past, bestelt hij zelf. Wat erbuiten valt, gaat als aanvraag naar de manager. Die hoeft niet meer te onthouden wie welke maat heeft, want dat staat vast per persoon.
Bedrukken of borduren, per locatie
Een jas krijgt het grote logo op de rug en het kleine op de borst. Dat zijn twee bestanden, twee technieken en twee prijzen, op één kledingstuk. De configurator laat je per locatie kiezen uit de logo's die het bedrijf al heeft aangeleverd, en rekent de prijs meteen mee. Wat er geborduurd wordt, krijgt de klant eerst als digitaal voorbeeld te zien.
Circa 4.400 actieve producten, elke nacht bijgewerkt. Een feed levert data, geen winkel; die indeling moest er nog omheen.
4.400 producten die kloppen
De catalogus komt uit de leveranciersfeed en wordt automatisch bijgewerkt. Maar een feed levert data, geen winkel. Er zaten 138 capuchontruien bij de sweaters terwijl de hoodie-categorie op 26 bleef steken, en de restbak accessoires zat op 644 producten. Dat is niet met een filter op te lossen, dat is indelen.
De fout die we in ons eigen werk vonden
Dit was onze eigen fout. De productlijst zat achter een Suspense-grens met een lege fallback, dus de statische pagina bevatte 936 KB aan productdata en geen enkele link. Google rendert JavaScript en kwam er uiteindelijk bij, maar de crawlers van ChatGPT, Claude en Perplexity doen dat niet en zagen het assortiment nooit. De eerste 24 producten worden nu serverside gerenderd en de paginatie is een gewone link. De meting staat in een script dat faalt zodra een lijstpagina onder de 20 productlinks zakt.
De fix staat live sinds 18 augustus 2026. Wat hij oplevert, weten we pas als er genoeg maanden overheen zijn. Daarom staat hier de diagnose en nog geen resultaat: dit zijn de cijfers van vóór de ingreep, niet erna.
Wat we in ons eigen werk vonden.
Een nieuwe shop is niet automatisch een snelle shop. Dit is wat de eerste versie deed en wat een dag meten en bijsturen opleverde.
Alle metingen zijn van 28 mei 2026 op de nieuwe shop, mobiel, en gaan over onze eigen performance-sprint van die dag. Van de oude WooCommerce-shop bestaat geen Lighthouse-meting, dus we zetten er ook geen naast. De productpagina staat op 74 en dus niet in het groen; die moet meer doen dan de homepage.
De eerste versie van de nieuwe shop laadde de lettertypes te zwaar, hield de chatwidget en de vergelijkbalk in de hoofdbundel en reserveerde geen ruimte voor de beelden. Dat laatste zie je terug in een CLS van 0,878: de pagina sprong tijdens het laden onder je vinger weg.
Een dag bijsturen loste dat op. De widgets werden apart geladen, twee lettertypes gingen eruit en de beeldruimte wordt nu vooraf vastgelegd. CLS staat op 0,000 en de grootste afbeelding is er in 2,5 seconden.
Dit had niemand hoeven weten. We zetten het erbij omdat een case zonder misstappen niet bestaat, en omdat de vraag die je aan een bureau wil stellen niet is of het fout gaat, maar of het gemeten en opgelost wordt.
Van de winkel tot het portaal.
De storefront, het kledingmanagementsysteem en het beheerscherm waar de klant op de hoogte wordt gehouden.
Homepage
Werkkleding per categorie en per merk, met de zakelijke ingang meteen in beeld.
Van etalage tot medewerkersportaal.
Twaalf schermen uit de live shop, het kledingbeheer en de backoffice. Klik er een aan om hem groot te bekijken.
Wat het opleverde.
Een snellere shop, een assortiment dat leesbaar is voor zoekmachines en een systeem dat een opvolger kan overnemen.
De pagina springt niet meer
CLS ging van 0,878 naar 0,000 en LCP van 5,9 naar 2,5 seconden. Op de homepage tilde onze performance-sprint Lighthouse van 53 naar 78 bij een koude cache, en 98 zodra die warm is. De productpagina staat op 74, daar ligt nog werk.
De producten staan nu in de HTML
Onze eigen eerste versie stuurde 936 KB naar de browser zonder één product als link in de HTML. Nu renderen categoriepagina's de eerste 24 producten serverside en is de paginatie een echte link. Een script slaat alarm als het terugkomt.
De architectuur staat op papier
Het architectuurdocument telt 1.027 regels en legt niet alleen vast wat er is gebouwd, maar ook wat er is afgewezen en waarom. Iemand anders kan het systeem overnemen zonder dat wij ernaast hoeven te zitten.
Draait jouw shop ook op losse plugins?
Soms is opnieuw bouwen goedkoper dan nog een plugin erbij. We kijken eerst wat je hebt, en zeggen het ook als je beter kunt blijven waar je zit. Bekijk wat we doen met webshops.