Magento specialist kiezen: 10 vragen voor je tekent

Je tekent een contract van 12 of 24 maanden met een partij die je shop gaat bouwen of beheren. Daarna is stappen lastig. De code staat bij hen, de kennis zit in hun hoofd en je omzet hangt eraan.

De keuze voor een Magento specialist wordt toch vaak gemaakt op basis van een mooie offerte en een prettig kennismakingsgesprek. Dat is te weinig. Hieronder staan 10 vragen die je vooraf stelt, de rode vlaggen die je herkent en een eerlijke vergelijking tussen freelancer, groot bureau en klein senior team.

Zoek je vooral de mechaniek van het inhuren zelf (profielen, tarieven, intake)? Lees dan Magento developer inhuren. Dit artikel gaat over de selectievragen en wat in het contract hoort.

Waarom de keuze zwaarder weegt dan bij andere leveranciers

Een Magento 2 shop is geen website die je oplevert en vergeet. Het is software met releases, security patches, extensies en integraties. Een fout in de keuze zie je pas na maanden terug: in trage deploys, openstaande patches of een bouwer die niet meer opneemt.

De rekenstap is simpel. Een shop met 1 miljoen euro omzet per jaar levert ruim 2.700 euro per dag op. Een checkout die een dag uit de lucht is, kost je dus meer dan een gemiddelde sprint. Kies dus op kwaliteit van werken, niet alleen op uurtarief.

De 10 vragen

1. Van wie is de code?

Vraag het letterlijk: staat de code in jouw Git-repository, of in die van het bureau? Wie is eigenaar van maatwerkmodules na afloop?

• Goed: repository op jouw naam, bureau heeft toegang. Eigendom van maatwerk gaat over bij betaling.
• Slecht: "de code staat bij ons, je krijgt een zip bij beëindiging".

Leg ook vast hoe het zit met licenties van third-party extensies. Die koop je meestal zelf; check op wiens account ze staan.

2. Welke ervaring hebben jullie met Hyvä?

Hyvä is voor veel shops de logische frontend geworden: lichter dan Luma en eenvoudiger te onderhouden. Vraag daarom niet "kunnen jullie dat?" maar:

• Hoeveel shops hebben jullie op Hyvä live gezet, en mag ik die bekijken?
• Hoe lossen jullie extensies op die niet compatibel zijn?
• Werken jullie met de Hyvä-compatibiliteitsmodules of bouwen jullie zelf?

Een partijstatus helpt als indicatie, maar bewijst geen kwaliteit. Wil je zelf eerst weten wat Hyvä betekent? Zie de Hyvä-pagina.

3. Wat is jullie beleid voor upgrades binnen 2.4.x?

Magento 2.4.x krijgt periodiek nieuwe minor releases en patches, en oudere releases verliezen na verloop van tijd ondersteuning. Controleer de actuele support-kalender van Adobe voor de versie die jij draait; die verandert.

Vraag:

• Hoe vaak upgraden jullie een klantshop, en wanneer?
• Doen jullie dat op staging met regressietests, of direct op productie?
• Is een minor upgrade inbegrepen in het onderhoudscontract, of apart gefactureerd?

Een bureau dat zegt "als het werkt, laten we het" bouwt technische schuld op jouw rekening.

4. Wat is de SLA voor security patches?

Magento is een doelwit. Adobe brengt security patches uit en kritieke kwetsbaarheden worden snel misbruikt. Een bureau moet dus in uren of dagen reageren, niet in weken.

Vraag om een getal, op papier:

• Binnen hoeveel werkdagen na een kritieke patch staat die op jouw productie?
• Wie monitort releases, en op welk kanaal krijg jij bericht?
• Wat gebeurt er in het weekend?

"We houden het in de gaten" is geen SLA. Zie ook wat een onderhoudscontract concreet hoort te dekken.

5. Wie schrijft de code echt?

De eerlijke versie: bij veel bureaus verkoopt een senior en bouwt een junior of een externe partij. Dat hoeft niet fout te zijn, maar je moet het weten.

• Wie van het team werkt aan mijn shop, met naam?
• Wordt werk uitbesteed of doorgeschoven naar een buitenlandse partner?
• Wie reviewt de code voordat die live gaat?
• Wie neem ik aan de telefoon als het misgaat?

Korte lijnen zijn hier de maatstaf. Heb je iemand nodig die je shop kent, of een ticketsysteem dat je door vier mensen heen stuurt?

6. Hoe werken jullie met test- en stagingomgevingen?

Minimale standaard:

• Een staging die lijkt op productie (zelfde PHP-, MySQL- en Elasticsearch/OpenSearch-versies).
• Deploys via Git en een pipeline, niet via FTP of handmatig kopiëren.
• Een korte smoke test op checkout, betaling en zoeken voor elke release.

Vraag ook of er geautomatiseerde tests zijn voor maatwerk. Bij een kleine shop is volledige testdekking niet realistisch. Kritieke flows afdekken wel.

7. Waar hosten jullie, en kan ik zelf kiezen?

Hosting bepaalt snelheid en kosten. Sommige bureaus verplichten eigen hosting met een opslag. Dat is bespreekbaar, zolang je weet wat je betaalt en je kunt vertrekken.

• Is hosting gekoppeld aan het contract, of staat het los?
• Wie heeft root- of deploytoegang?
• Kan ik bij vertrek de server en data meenemen?

Een Magento-geoptimaliseerde hoster is meestal verstandiger dan generieke shared hosting.

8. Wat staat er in de exit-clausule?

Dit is de vraag die niemand stelt en iedereen later mist. Leg vast:

• Opzegtermijn (liefst maximaal 3 maanden voor onderhoud).
• Overdracht van code, database, toegangen en documentatie, binnen een afgesproken termijn.
• Medewerking aan de overdracht, tegen een vooraf bekend tarief.
• Geen boete voor het vertrekken zelf.

Een bureau dat zeker is van zijn werk, heeft hier geen moeite mee.

9. Zijn jullie referenties controleerbaar?

Een logo op een website is geen referentie. Vraag:

• Kan ik met twee klanten bellen die vergelijkbaar zijn met mijn shop (omvang, branche, Hyvä of Luma)?
• Kan ik de live shop bekijken en de laadtijd zelf meten?
• Kan ik de onderhoudsgeschiedenis zien: hoe snel waren patches live?

Controleer zelf Core Web Vitals via PageSpeed Insights of CrUX. Cijfers van een shop zijn publiek te verifiëren.

10. Hoe ziet het prijsmodel eruit?

Er zijn grofweg drie vormen:

• Uurtarief met inschatting: flexibel, maar budget kan oplopen.
• Vaste prijs per project: voorspelbaar, mits de scope strak is. Wijzigingen kosten extra.
• Retainer voor onderhoud: vast bedrag per maand voor een afgesproken aantal uren of taken.

Vraag naar wat niet in de prijs zit: licenties, hosting, extra testronden, spoedwerk. En naar hoe overschrijding wordt gecommuniceerd, voordat je de factuur ziet. Een globaal beeld van wat je mag verwachten staat op de kostenpagina voor Magento.

Rode vlaggen

Haak af of vraag door bij:

• Geen concrete antwoorden op vraag 1, 4 of 8.
• "Alles kan" zonder een enkele kanttekening. Een goede partij zegt ook nee, of "dit moet je niet bouwen".
• Geen Git, geen staging, geen code review.
• Een offerte zonder scope of aannames.
• Druk om snel te tekenen ("deze korting vervalt vrijdag").
• Referenties die je niet mag spreken.
• Het team dat je ontmoet, is niet het team dat bouwt.

Freelancer, groot bureau of klein senior team?

Er is geen universeel beste keuze. Dit is de eerlijke vergelijking.

Wanneer is welke het beste?

• Freelancer: je hebt een afgebakende klus, zoals een module of een kleine fix, en een goede bekende. Of je budget is klein en het risico acceptabel. Stel wel een tweede persoon voor noodgevallen vast.
• Groot bureau: je hebt een groot programma met meerdere landen, ERP/PIM-koppelingen, design, content en marketing in één traject, en je wilt één partij die alles coördineert. Dan betaal je voor het coördineren, en dat is terecht.
• Klein senior team: je shop draait, je wilt doorontwikkelen en betrouwbaar beheer, en je wilt weten wie er aan je code werkt. Voor een zeer groot internationaal programma schiet een klein team tekort.

Hoe je het gesprek voert

Stuur de 10 vragen vooraf per mail. Je leert twee dingen: hoe snel en concreet het antwoord komt, en of ze zich door de vragen laten bewijzen of ontwijken.

Vraag drie bureaus. Vergelijk niet alleen de prijs, maar de antwoorden op vraag 1, 4, 5 en 8. Daar zit het echte risico.

Hoe wij dit aanpakken

Wij zijn een klein team uit Emmen en werken met Magento 2 en Hyvä (Hyvä Silver Partner). Op de vragen hierboven geven wij liever vooraf antwoord dan achteraf: de code staat in jouw repository, je weet wie aan je shop werkt en we bespreken ook wanneer een andere route beter bij je past. Dat laatste kan een freelancer zijn, of een groter bureau.

Wil je weten of we passen? Stuur ons dezelfde vragen. We beantwoorden ze schriftelijk.

Veelgestelde vragen

Wat doet een Magento specialist precies?

Een Magento specialist bouwt, onderhoudt en optimaliseert Magento 2 shops. Denk aan maatwerk modules, thema's (Luma of Hyvä), integraties met ERP of PIM, upgrades, security patches en performance. Let op het verschil: sommige partijen doen alleen bouw, anderen ook beheer.

Wat kost een Magento 2 ontwikkelaar of bureau?

Dat hangt af van scope, shopgrootte en het prijsmodel. Tarieven verschillen tussen freelancers en bureaus, en een vaste projectprijs zegt weinig zonder scope. Vraag altijd om aannames en uitsluitingen. Meer richtlijnen staan op de kostenpagina.

Is een freelancer of een bureau beter voor Magento?

Voor een afgebakende klus is een freelancer vaak voldoende en goedkoper. Voor grote, meerlaagse programma's is een groot bureau logischer. Voor doorlopende ontwikkeling en beheer werkt een klein vast team vaak goed. Zie de tabel hierboven.

Hoe controleer ik of een Magento bureau Hyvä-ervaring heeft?

Vraag naar live Hyvä-shops, bel een klant en meet de Core Web Vitals zelf via PageSpeed Insights. Vraag ook hoe ze omgaan met niet-compatibele extensies. Achtergrond vind je op de Hyvä-pagina.

Wat moet er in een contract met een Magento bureau?

In elk geval: eigendom van code, SLA voor security patches, upgradebeleid, hostingafspraken, opzegtermijn en een overdrachtsregeling. Zonder die punten ben je afhankelijk van goede wil.

Wil je sparren?

Twijfel je tussen partijen, of wil je een second opinion op een offerte? Neem contact op. Je spreekt direct met degene die ook naar je shop kijkt.