Een webaanbieder kies je niet op basis van een portfolio of een dagtarief. De doorslaggevende factor in 2024 is het vermogen van de aanbieder om een project te leveren dat voldoet aan de recente wettelijke verplichtingen, met name op het gebied van toegankelijkheid, terwijl je technische autonomie na de lancering wordt gegarandeerd.
Toegankelijkheid en de European Accessibility Act: de criteria die je bestek vergeet
Sinds 28 juni 2025 verplicht de European Accessibility Act de conformiteit van e-commerce diensten voor consumenten. Nieuwe diensten moeten toegankelijk zijn vanaf hun lancering. Bestaande diensten hebben een overgangsperiode tot 28 juni 2030.
De verantwoordelijkheid voor deze conformiteit ligt bij het bedrijf dat de dienst aan de consument levert, niet bij het bureau dat de site ontwikkelt. Kortom, als jouw aanbieder een niet-conforme site levert, loop jij het juridische risico.
Wij raden aan om contractueel drie elementen te eisen: de toegankelijkheidsreferentie (RGAA of WCAG), de tests die tijdens de ontwikkeling zijn gepland, en een gedocumenteerde correctieprocedure met auditleveringen. Een aanbieder die toegankelijkheid niet vermeldt in zijn offerte in 2024 heeft een aanzienlijke methodologische achterstand.
Toegankelijkheid beperkt zich niet tot kleurcontrast. De vereisten omvatten de volledige aankoopervaring, formulieren, toetsenbordnavigatie, de semantische structuur van de HTML en de compatibiliteit met assistentietechnologieën. Controleer of het voorgestelde team echte expertise op deze onderwerpen heeft, en geen simpele commerciële vermelding.
De uitzondering geldt alleen voor micro-ondernemingen met minder dan tien personen waarvan de jaarlijkse omzet of de totale balans niet meer dan 2 miljoen euro bedraagt. Als jouw organisatie deze drempels overschrijdt, ben je betrokken, ongeacht de grootte van je site.
Eigendom van de code en toegang: contractuele clausule boven alle technische criteria
Voordat je de vaardigheden van een webbureau evalueert, moet je een juridisch punt verduidelijken dat vaak over het hoofd wordt gezien in offertes: aan wie behoren de broncode, de domeinnaam en de toegang tot de hosting zodra het project is geleverd. We zien nog steeds contracten waarin de aanbieder het eigendom van de code behoudt, wat elke latere migratie juridisch complex en technisch kostbaar maakt.
Het contract moet expliciet de overdracht van de patrimoniale rechten op de geleverde code vermelden. Het moet ook de overdracht van alle identificaties (hosting, registrar, back-office CMS, analytics-accounts) binnen een bepaalde termijn na de lancering voorzien. Een aanbieder die deze clausule weigert, houdt je in een technische afhankelijkheid.
Wanneer je probeert een aanbieder te vinden met CM 35, verdienen deze contractuele punten het om al bij de eerste uitwisseling aan de orde te komen, zelfs voordat je over CMS of design praat.
Technische stack en keuze van CMS: vergelijk methoden, niet logo’s
De keuze tussen WordPress, maatwerkontwikkeling of een no-code platform zou niet afhankelijk moeten zijn van de voorkeuren van de aanbieder. Het hangt af van de functionele complexiteit van jouw project, jouw interne contentbeheer capaciteiten en jouw prestatie-eisen.
Een vitrinewebsite met een tiental pagina’s en een contactformulier rechtvaardigt geen maatwerkontwikkeling. Aan de andere kant kan een e-commerce site met specifieke voorraadbeheerfunctionaliteiten, meerdere betaalmethoden of een specifieke bedrijfslogica een headless CMS of een speciaal framework vereisen.
Wij raden aan om de technische stack te evalueren op drie concrete criteria:
- Redactionele autonomie: kun je de inhoud aanpassen, pagina’s toevoegen en media beheren zonder tussenkomst van de aanbieder na de levering?
- Onderhoudbaarheid: documenteert de aanbieder zijn code, gebruikt hij een versiebeheerder (Git) en heeft hij een plan voor beveiligingsupdates?
- Meetbare prestaties: bevat de offerte kwantitatieve doelstellingen voor de Core Web Vitals (LCP, CLS, INP) of beperkt het zich tot een responsief design?
Een aanbieder die systematisch hetzelfde CMS-platform aanbiedt ongeacht het project, geeft aan dat er een gebrek aan technische veelzijdigheid is. De aanbeveling van het CMS zou voort moeten komen uit de analyse van jouw functionele behoeften, niet andersom.
Samenstelling van het projectteam en uitbesteding: de vragen die je moet stellen voordat je tekent
De kwaliteit van een webaanbieder meet je aan het team dat daadwerkelijk aan jouw project werkt. Vraag naar de namen en de rollen van de betrokken personen. Een projectmanager die tussen twaalf klanten tegelijk jongleert, levert niet hetzelfde niveau van opvolging als een toegewijd team met gestructureerde wekelijkse punten.
Offshore uitbesteding is op zich geen probleem, maar moet in het contract worden vermeld. Het belangrijkste risico: een commerciële contactpersoon in Frankrijk en ontwikkelaars in het buitenland zonder directe communicatie mogelijk. Eis te weten wie codeert, wie integreert en wie test.
Controleer ook wat is uitgesloten van de offerte. Het schrijven van inhoud, on-page SEO-optimalisatie, configuratie van analysetools, training voor het back-office: deze diensten vertegenwoordigen vaak een vergelijkbaar werkvolume als de ontwikkeling zelf. Een offerte die een aantrekkelijke prijs toont door deze posten uit te sluiten, is niet te vergelijken met een globale offerte.
- Vraag om een leveringsplanning met tussentijdse mijlpalen en valideerbare leveringen bij elke stap
- Controleer of de acceptatie (testfase voor de lancering) is inbegrepen en hoeveel correctiecycli zijn voorzien
- Verduidelijk de voorwaarden voor onderhoud na levering: duur, reikwijdte, gegarandeerde responstijd in geval van een storing
De keuze van een webaanbieder in 2024 draait minder om design dan om contractuele soliditeit, wettelijke conformiteit en operationele transparantie. Een goede aanbieder maakt je autonoom na de lancering, hij maakt je niet afhankelijk voor elke tekstwijziging of beveiligingsupdate.
