Je hebt drie offertes ontvangen voor je nieuwe website. Ze zien er allemaal anders uit, de prijzen lopen uiteen en je weet niet goed waar je op moet letten. Dat is precies het moment waarop de meeste opdrachtgevers een beslissing nemen op basis van gevoel of prijs — en dat is ook precies het moment waarop het later mis kan gaan. In deze post leg ik je uit wat er echt in een offerte moet staan, en waarom sommige dingen die er níét in staan minstens zo belangrijk zijn.
Offertes vergelijken is geen appels met appels vergelijken
Het eerste wat je moet begrijpen: twee offertes van gelijke prijs kunnen enorm van elkaar verschillen in wat ze daadwerkelijk leveren. De ene bouwer rekent een vast bedrag voor het ontwerp en de bouw, maar noemt met geen woord wat er daarna gebeurt. De andere heeft een lager starttarief, maar zit vol maandelijkse kosten die pas in de kleine lettertjes zichtbaar worden.
Wat je altijd moet uitvragen voordat je tekent:
- Wat valt er precies onder het vaste bedrag?
- Zijn revisierondes inbegrepen, en zo ja, hoeveel?
- Wat kost een aanpassing ná oplevering?
- Zijn hosting en domeinnaam inbegrepen of apart?
- Wat zijn de kosten als het project uitloopt?
Een offerte die deze vragen niet beantwoordt, is geen offerte — het is een prijsindicatie. Die twee zijn niet hetzelfde. Een prijsindicatie is vrijblijvend en kan later in alle richtingen bewegen. Een offerte zou een helder kader moeten bieden voor wat je krijgt, wanneer je het krijgt en wat het kost als er iets verandert. Vraag altijd om een gespecificeerde offerte, niet een totaalprijs met een vage omschrijving eronder.
Vergelijk offertes ook altijd op scope, niet alleen op prijs. Als de ene bouwer vijf pagina’s aanbiedt en de andere tien, vergelijk je niets. Maak zelf een lijst van wat je nodig hebt — pagina’s, functies, formulieren, taalversies — en vraag alle partijen op dezelfde basis te offreren. Dat is meer werk vooraf, maar het voorkomt dat je achteraf betaalt voor dingen die je dacht dat inbegrepen waren.
Eigendom van domein en broncode: dit mag je nooit weggeven
Dit is het onderwerp waar ik de meeste schade zie. Opdrachtgevers die jarenlang hebben gebouwd aan een website, en op het moment dat ze van bouwer willen wisselen, ontdekken dat de domeinnaam op naam van het bureau staat. Of dat de broncode niet wordt vrijgegeven omdat die “eigendom van de bouwer” is. Of dat de logingegevens van de hostingomgeving nergens zijn vastgelegd.
Laat me duidelijk zijn: jij bent de opdrachtgever. Jij betaalt. De website is van jou. Maar als dat niet contractueel is vastgelegd, kun je er niet vanuit gaan dat het ook zo wordt behandeld.
Wat je in elk contract moet laten opnemen:
- De domeinnaam staat op jouw naam, bij een registrar waar jij toegang toe hebt
- De broncode wordt bij oplevering volledig aan jou overgedragen
- Je ontvangt alle inloggegevens voor hosting, CMS en eventuele externe diensten
- Er is geen clausule die overdracht van de code beperkt of vertraagt
Het begrip broncode klinkt technisch, maar het is eigenlijk simpel: het zijn de bestanden waaruit je website is opgebouwd. Zonder die bestanden kun je niet van bouwer wisselen zonder alles opnieuw te laten bouwen. Dat maakt je afhankelijk — en afhankelijkheid kost geld. Wie meer wil begrijpen over hoe broncode en softwareeigendom juridisch zijn gedefinieerd, kan een goed startpunt vinden in een artikel op Wikipedia over intellectueel eigendom in de softwaresector.
Controleer ook wie de domeinnaam heeft geregistreerd. Dit kun je zelf nakijken via een WHOIS-zoekopdracht. Als je naam er niet bij staat, los dat dan op vóórdat je verder gaat. Een bouwer die weigert de domeinnaam op jouw naam te zetten, is een bouwer die je afhankelijkheid als verdienmodel gebruikt.
Onderhoudscontracten en oplevering: wat je moet weten vóór je tekent
Na de bouw begint het echte werk: de website moet live, veilig en vindbaar blijven. Veel opdrachtgevers denken dat de bouw het zwaarste deel is, maar de periode daarna is minstens zo belangrijk — en vaak een stuk minder goed geregeld.
Een onderhoudscontract is niet per definitie slecht. Updates moeten worden uitgevoerd, back-ups moeten worden gemaakt en beveiligingsproblemen moeten worden opgelost. Maar een onderhoudscontract is ook een manier om je langdurig aan een partij te binden. Let dus op wat er in staat.
Vragen die je moet stellen over onderhoud:
- Wat valt er precies onder het maandelijkse bedrag?
- Zijn software-updates inbegrepen of apart?
- Wat is de reactietijd bij problemen?
- Kun je het contract opzeggen, en zo ja, met welke opzegtermijn?
- Wat gebeurt er als je het contract opzegt — krijg je dan nog steeds toegang tot alles?
Die laatste vraag is cruciaal. Sommige onderhoudscontracten zijn zo opgesteld dat je toegang verliest tot bepaalde functies of ondersteuning zodra je opzegt. Dat is geen onderhoud — dat is een abonnement op je eigen website. Zorg dat je weet waarvoor je tekent.
Over oplevering: spreek een duidelijk oplevermoment af en leg vast wat er op dat moment wordt gecontroleerd. Een goede oplevering omvat minimaal:
- Werkt de website op alle gangbare browsers en apparaten?
- Zijn alle formulieren getest en werken die correct?
- Zijn er geen gebroken links of ontbrekende afbeeldingen?
- Is de website vindbaar voor zoekmachines (robots.txt, sitemap)?
- Zijn alle inloggegevens overgedragen?
Teken nooit een opleveringsdocument als je de website nog niet zelf hebt doorgelopen. Neem daar de tijd voor. Zodra je tekent, is de bouwfase officieel afgesloten en begint de garantieperiode — als die er al is.
Toegankelijkheid: niet alleen een ethische keuze
Toegankelijkheid van websites staat steeds vaker op de agenda, en terecht. Maar ik merk dat veel opdrachtgevers het als een extra zien, iets wat je doet als het budget het toelaat. Dat is een misverstand dat ik graag rechtzet.
Een toegankelijke website is niet alleen beter voor mensen met een visuele beperking, een motorische beperking of dyslexie. Het is ook beter voor zoekmachines, voor gebruikers op trage verbindingen en voor mensen die je site op een klein scherm bekijken. Toegankelijkheid en bruikbaarheid overlappen meer dan de meeste mensen denken.
Wat je minimaal moet vragen aan je bouwer:
- Wordt de website gebouwd volgens de WCAG-richtlijnen?
- Op welk niveau (A, AA of AAA)?
- Hoe wordt dit getest — handmatig, automatisch of allebei?
- Wordt er rekening gehouden met toetsenbordnavigatie en schermleessoftware?
Voor overheidsinstanties en publieke organisaties is toegankelijkheid inmiddels wettelijk verplicht. Maar ook als je een commerciële organisatie bent, is het verstandig om hier aandacht aan te besteden. Een website die voor een deel van je doelgroep onbruikbaar is, is een website die omzet mist.
Laat je bouwer ook uitleggen hoe ze toegankelijkheid testen. Alleen een geautomatiseerde scan is niet voldoende — die vangt misschien de helft van de problemen op. Handmatige tests, bij voorkeur met echte gebruikers, geven een veel betrouwbaarder beeld. Als een bouwer zegt dat hun website “gewoon toegankelijk is” zonder verder te specificeren hoe ze dat weten, is dat een rode vlag.
Tot slot: vraag ook hoe je zelf toegankelijk houdt wat de bouwer heeft opgeleverd. Als jij straks zelf teksten toevoegt, afbeeldingen uploadt of pagina’s aanmaakt, moet je weten hoe je dat op een toegankelijke manier doet. Denk aan alt-teksten voor afbeeldingen, logische kopenstructuur en voldoende kleurcontrast. Een bouwer die dit niet uitlegt bij de oplevering, levert eigenlijk een half product.
Tot slot
Een website laten maken is een investering, en zoals bij elke investering geldt: hoe beter je voorbereid bent, hoe minder onaangename verrassingen je krijgt. Lees offertes zorgvuldig, vraag door op wat onduidelijk is en zorg dat eigendom, onderhoud en oplevering contractueel zijn vastgelegd. Toegankelijkheid is geen luxe maar een basiskwaliteit die je van elke bouwer mag verwachten.
Je hoeft geen technisch expert te zijn om goede vragen te stellen. Je hoeft alleen te weten wat je rechten zijn — en die beginnen altijd bij wat er op papier staat.
Leave a Reply