Echte projecten. Echte keuzes. Echte lessen. We werken veel met B2B-platforms, complexe integraties en performance-optimalisatie. Hier delen we wat we onderweg hebben geleerd.
Geen marktingpraat – alleen wat we echt hebben gebouwd en waarom.
Een B2B-klant had een massieve product-configurator die alles in één PHP-file zat. We breidden uit, maar de bouwproces werd langzaam. Hoe splitsen we dit zonder het te breken?
Klant draaide op een zwaar Magento-thema met veel custom JS. Deploy duurde lang. Hyvä was niet alleen sneller – het veranderde hoe we denken over checkout.
Een e-commerce site scoorde goed op GTmetrix maar de LCP was slecht. Profiling bracht verrassingen: het was niet wat we verwachtten.
Junior dev start maandag. Project heeft 5 jaar geschiedenis. Hoe zorg je dat ze snel productief zijn zonder alles uit te hoeven leggen?
Maandelijkse updates, security patches, dependency management. Hoe zorg je dat klanten niet bang zijn voor updates?
Klant heeft 20 jaar oude ERP. Magento moet data halen/sturen via SOAP. API's zijn traag. We gingen queuing bouwen.
Zoals veel B2B-projecten groeien. Je begint met één pagina. Dan voeg je een optie toe. Dan nog één. Na drie jaar zitten alle business-logica, validaties en calculaties in één grote file.
Klant bouwt op maat gemaakte machines. Elk model heeft tientallen opties, elk met bijbehorende beperking of extra kosten. De configurator in Magento was gegroeid naar 1500+ regels PHP zonder duidelijke structuur.
Bouwproces was traag. Testen was handmatig. Als je één regel veranderde, kon je iets anders breken. Niemand durfde eraan te zitten.
We hebben de configurator in logische modules gesplitst. Elk component: validation, calculation, UI-rendering – los van elkaar.
Refactoring is niet gratis – het vraagt discipline. Maar wij zagen daling in bugs en makkelijker feature-adds. Maintainability wint op den duur.
"Na refactor durfde ik eindelijk een nieuwe optie toe te voegen zonder alles te breken. Dat voelt goed."
Een klant had een custom Magento-thema met honderden regels jQuery. Deploy duurde lang, browser-debug was lastig. We hebben over de vraag nagedacht: waarom laden we al dat? En: moet het echt in JavaScript?
Het oude thema was niet slecht – het was gewoon zwaar. Checkout-flow verliep traag. Core Web Vitals waren niet goed.
Hyvä biedt twee ding: een moderne Tailwind-gebaseerde basis, en Alpine.js in plaats van jQuery/RequireJS. Deploy naar hosten werd sneller.
We migreerden incrementeel. Thema's, Checkout, daarna custom modules.
Checkout werd sneller. Deploy-time ging van 6 minuten naar 2. Developers schreven makkelijker front-end code. Niets dramatisch, maar alles voelde beter.
"Hyvä voelde eerst als zomaar een nieuwe stack. Maar je merkt al snel: het is slim gebouwd. Minder 'magic', meer transparantie."
Klant zei: "Google zegt we scoren goed op GTmetrix, maar conversie is laag. Wat doen we fout?" Profiling bracht rare bevindingen.
CLS en LCP scoorden slecht in Real User Monitoring (RUM), maar lab tools zeiden dat het goed was. Wat staat er werkelijk in de weg?
We keken naar Network tab, JavaScript-parsing, font-loading, third-party scripts. Het bleek: tracking-tags en advertentieprogramma's blockerden rendering.
We hebben strategisch ingelaagd. Niet alles moet synchroon laden.
"GTmetrix zei: prima. Chrome DevTools zei: prima. Echte gebruikers ervaarden: te traag. Dat verschil leert je veel."
Junior dev begint. Codebase is 5 jaar oud, complex, geen README. "Ik weet niet waar ik moet beginnen." Hoe zorg je dat ze productief worden in één sprint?
We hebben veel knowledge in iemands hoofd. Documenten zijn snel out-of-date. Hoe delen we weten?
We hebben onboarding anders ingerichting: hands-on met mentoring, niet passief lezen.
Langzamer at-the-start, maar sneller productief. Junior kan na 2 weken zelfstandig taken pakken. Senior voelt zich beter als mentor.
"Ik dacht dat ik veel moest bijleren voordat ik code kon aanpassen. Maar door direct mee te doen, begreep ik sneller. En vragen stellen zonder schaamte helpt echt."
Klant belt: "Magento heeft een security update. Moeten wij iets doen?" Klassiek problem: klanten zijn bang voor updates. Ze kunnen breeken. Hoe zorg je dat security-patching routine wordt?
Maandelijks patches, security-updates, dependency-management, kleine performance-tuning. Klant betaalt vaste vergoeding, wij zorgen dat site stabiel blijft.
Updates kunnen niet zomaar naar production. Testen nodig. Rollback-plan. Klant wil zekerheid, geen verrassingen.
Alles geautomatiseerd. Tests moet slagen. Staging voor final check. Git-workflow strak.
Security-updates voelen normaal. Klant hoeft niet nerveus te zijn. We hebben geen incident gehad door update-related issues in jaren.
"Updates voelen nu als routine, niet als risico. Dat geeft rust."
Klant: "Magento moet productgegevens halen van ons ERP-systeem. Soms volgt 1 update 2 seconden. Soms hangt het vast." Dit gebeurt duizenden keer per dag. Hoe zorg je dat het schaalbaar is?
Klant draait 20 jaar oude ERP (SOAP API, traag). Magento moet real-time productdata, prijzen, voorraden. Direct aanroepen = traag en onbetrouwbaar.
Als ERP traag is, hangt Magento product-page op. Timeout. Customer-experience stinks.
We hebben async queuing gebouwd. Haalt data van ERP, cached het, Magento leest cache. Updates gebeuren op achtergrond.
Product-pages laden in 200ms, niet 5s. ERP traagheid valt niet meer op. Customer-experience verbeterd. Schaalbaar voor groei.
"Ik dacht dat we oude ERP nooit snel zouden krijgen. Maar met caching en queuing voelt het web-modern. Blij."
Dit zijn de soort problemen die we graag oplossen. Hyvä-thema's, complex-integraties, performance-optimalisatie, onderhoud. Interesse?