Technische schuld verlagen met Hyvä Commerce

Technische schuld verlagen met Hyvä Commerce

De gemiddelde Magento 2-shop draait op vijf tot tien losse extensies die niemand meer durft aan te raken. Elke upgrade wordt een risico-inventarisatie in plaats van een routine. Hyvä Commerce lost dit structureel op: één suite, één update-pad, drastisch minder maatwerk-koppelingen.

Wat technische schuld in Magento 2 kost

Technische schuld is niet abstract. Het heeft een prijs.

Bij klanten die wij begeleiden bij migraties zien wij hetzelfde patroon: een shop die jaren geleden live ging met een verzameling losse extensies voor checkout, CMS, media en UI-componenten. Elke extensie heeft zijn eigen release-cyclus, zijn eigen conflicthistorie en zijn eigen manier om Magento te overschrijven.

Concreet betekent dat:

• Een Magento-upgrade kost 2 tot 5 dagen extra alleen al voor het uittesten van extensie-conflicten.
• Security patches worden uitgesteld omdat niemand weet wat er breekt.
• Junior developers durven de checkout-code niet aan te raken.
• De PHP-versie loopt achter omdat een extensie niet meekomt.

Dat zijn geen hypothetische kosten. Dat zijn offertes die wij schrijven.

Waarom losse tooling technische schuld stapelt

De klassieke Magento 2-stack voor een serieuze webshop ziet er zo uit:

Elke rij in die tabel is een afhankelijkheid. Elke afhankelijkheid is een potentieel conflict bij de volgende Magento-release.

Hoe Hyvä Commerce dit aanpakt

De bundel bevat:

• Hyvä Theme — HTML-first frontend op Tailwind en Alpine.js.
• Hyvä UI — componentenbibliotheek met design tokens, gebouwd voor hergebruik.
• Hyvä Checkout — een eigen checkout, los van Knockout.js en de legacy Magento-checkout.
• Merchant-tools — een modern CMS met live preview (liveview), een vernieuwd admin-theme, een ingebouwde image editor, automatische media-optimalisatie en een dashboard.

Het cruciale verschil: al die componenten zijn door Hyvä als team gebundeld en onderhouden. Ze volgen één update-pad. Als Magento een nieuwe versie uitbrengt, hoef je niet zes leveranciers te volgen — je volgt Hyvä.

Minder maatwerk-koppelingen in de praktijk

De technische schuld-reductie zit voor een groot deel in het verdwijnen van koppelingen.

In een klassieke Magento 2-setup stuurt een checkout-extensie events die het theme moet afvangen. Het theme overschrijft een layout die de CMS-extensie ook aanpast. Drie losse partijen, drie potentiële conflicten. Elke keer als één van die drie een update uitbrengt, test jij de andere twee.

Met Hyvä Commerce zijn checkout, theme en UI-componenten intern consistent. Ze zijn ontworpen om samen te werken. De kans op conflicten bij een update is structureel kleiner omdat de verantwoordelijkheid bij één partij ligt.

Een concreet voorbeeld: de Hyvä Checkout communiceert met de theme-laag via dezelfde Alpine.js-patronen en design tokens als de rest van de frontend. Er is geen aparte Knockout.js-stack die je moet maintainen of omzeilen.

// Klassieke Magento Luma checkout: Knockout.js dependency
define(['ko', 'uiComponent'], function (ko, Component) {
    return Component.extend({
        totals: ko.observable(null),
        // ... 300 regels boilerplate
    });
});

// Hyvä Checkout: Alpine.js, geen aparte module-loader
<div x-data="hyvaCheckout()">
    <span x-text="totals.grand_total"></span>
</div>

Minder code, minder lagen, minder leercurve voor nieuwe developers.

Het update-pad: één cyclus in plaats van zes

Technische schuld groeit het snelst bij upgrades die worden uitgesteld. En upgrades worden uitgesteld omdat ze te riskant zijn.

Met Hyvä Commerce werkt het anders:

1. Hyvä bundelt updates voor de hele suite.
2. Jij update via Composer, één pakket.
3. Regressietests richten zich op jouw eigen maatwerk, niet op onderlinge extensie-conflicten.
4. Security patches worden eerder doorgevoerd omdat de drempel lager is.

Wij zien bij klanten die wij op Hyvä Commerce migreren dat upgrade-sessies van dagen naar uren gaan. Niet omdat de shop kleiner is, maar omdat de afhankelijkheden zijn teruggebracht.

Performance als bijkomend voordeel

Hyvä Theme levert standaard:

• ~95% minder JavaScript dan een Luma-gebaseerde shop.
• Geen RequireJS, geen Knockout.js, geen jQuery als fundament.
• Lighthouse-scores structureel boven de 95.

Dat is relevant voor technische schuld omdat performance-problemen in Luma zelden oplosbaar zijn zonder de architectuur te raken. Je plakt workarounds op een fundamenteel zwaar fundament. Met Hyvä is de basis snel — maatwerk dat je toevoegt degradeert die basis minder snel.

Kosten en afweging

Hyvä Commerce kost circa 3.000 euro per jaar aan licentie, of circa 12.000 euro voor een eenmalige licentie met doorlopend eigenaarschap. Prijzen kunnen variëren; PPP- en trade-in-regelingen bestaan. De implementatie komt daar bovenop.

Vergelijk dat met de alternatieve kostenpost: jaarlijkse upgrade-trajecten van meerdere dagen, extensie-vervangingen, performance-fixes en de opportunity cost van features die wachten omdat niemand de codebase durft aan te raken.

Voor shops met een serieuze omzet is de licentie geen kostenpost. Het is een investering in voorspelbaarheid.

Wanneer Hyvä Commerce niet de juiste keuze is

Eerlijkheid eerst.

Hyvä Commerce is niet voor iedereen de juiste keuze:

• Kleine shops met weinig ontwikkelbudget. De licentiekosten plus implementatie vereisen een businesscase. Een shop van 200.000 euro omzet per jaar haalt die drempel mogelijk niet.
• Shops die zwaar afhankelijk zijn van Luma-specifieke extensies die nog geen Hyvä-compatibele versie hebben. Controleer de compatibiliteitsmatrix voor je start.
• Teams die diep in Adobe Commerce-specifieke features zitten die Hyvä (nog) niet volledig ondersteunt. Hyvä werkt op Adobe Commerce, maar niet alle edge cases zijn gedekt.
• Projecten die over 12 maanden toch migreren naar een ander platform. Als je al zeker weet dat je naar Shopify gaat, is een Hyvä-implementatie geen goede investering.

Wij adviseren ook weleens om Hyvä Commerce niet te implementeren. Dat is geen verlies — dat is eerlijk werk.

Wat overblijft na de migratie

Na een migratie naar Hyvä Commerce zien wij bij klanten structureel minder:

• Extensie-conflicten bij upgrades.
• Onbegrijpelijke XML-layout-overrides.
• Jquery-afhankelijkheden in de frontend.
• Onderhoudstrajecten voor de checkout.

En meer:

• Developers die durven te werken in de checkout-code.
• Merchants die CMS-content aanpassen zonder ticket aan development.
• Upgrades die als routine worden uitgevoerd in plaats van als project.

Technische schuld nul bestaat niet. Maar een beheersbare schuld met één update-pad is fundamenteel anders dan een onbeheerste stapel afhankelijkheden.

Conclusie

Technische schuld in Magento 2 ontstaat niet door slechte intenties. Het ontstaat door de optelsom van losse beslissingen over jaren: een checkout-extensie hier, een theme daar, een image-optimizer die buiten de cyclus valt.

Hyvä Commerce pakt dat structureel aan. Niet door één wonderoplossing, maar door bundeling van de meest kritische componenten onder één update-pad. Dat is het kernargument voor CTO's en development-teams: minder koppelingen, minder conflicten, meer controle.

Wil je weten of Hyvä Commerce past bij jouw huidige Magento 2-installatie? Wij doen een gratis Tech Check en kijken naar je extensieset, upgrade-geschiedenis en architectuur. Neem contact op via /contact — geen verplichtingen, geen sales-praatje.