Je hebt gesprekken gehad, je hebt offertes ontvangen, en nu ligt er een contract op tafel. Of eigenlijk: een opdrachtbevestiging van twee kantjes met een paar vage zinnen over “maatwerk website inclusief CMS”. Dit is het moment waarop de meeste opdrachtgevers een fout maken. Ze tekenen, omdat het eindelijk zo ver is en ze er gewoon mee aan de slag willen. Wat er daarna mis kan gaan, had je kunnen voorkomen door vijftien minuten goed naar dat document te kijken.
Een goed contract is geen juridisch obstakel. Het is het moment waarop je afspreekt wat je krijgt, wie er eigenaar van is, en wat er gebeurt als het niet klopt. Als dat niet op papier staat, bestaat het niet.
Wat de offerte en het contract met elkaar te maken hebben
Veel opdrachtgevers behandelen de offerte en het contract als twee aparte dingen. De offerte is wat je krijgt, het contract is de formaliteit daarna. Dat is een gevaarlijke manier van denken.
In de praktijk is de offerte vaak het enige document dat beschrijft wat er gebouwd wordt. Als het contract daar niet naar verwijst, of als de offerte vaag is, heb je straks geen been om op te staan. “Een website met vijf pagina’s en een contactformulier” is geen werkbare beschrijving. Hoeveel tekst schrijft de bouwer zelf? Wie levert de afbeeldingen? Zijn er animaties of is het statisch? Wat is de reactietijd op feedback?
Controleer altijd of het contract expliciet verwijst naar de offerte of het voorstel, en of dat voorstel concreet genoeg is. Als de offerte vaag is, vraag dan om een gedetailleerde versie voordat je tekent. Dat voelt ongemakkelijk, maar het is veel minder ongemakkelijk dan een discussie achteraf over wat er nu eigenlijk beloofd was.
Dingen die in de offerte én het contract thuishoren:
- Een beschrijving van wat er precies opgeleverd wordt
- Wie welke content aanlevert (teksten, afbeeldingen, logo’s)
- Het aantal revisierondes dat inbegrepen is
- Wat er buiten scope valt en hoe meerwerk wordt afgerekend
- De betalingsstructuur: wanneer betaal je wat
Eigendom van de website, de code en het domein
Dit is het onderwerp waar ik de meeste ellende over heb opgeruimd. Je betaalt voor een website, dus je denkt dat je eigenaar bent. Maar eigendom is niet automatisch. Als het niet expliciet in het contract staat, is de kans groot dat de bouwer de rechten op de broncode behoudt.
Dat klinkt abstract, maar de gevolgen zijn heel concreet. Stel dat je na twee jaar wilt overstappen naar een andere partij. Als de code niet van jou is, kun je die niet zomaar meenemen. Je bent afhankelijk van de bereidheid van je vorige bouwer om mee te werken. Sommige bureaus zijn daar heel redelijk in. Anderen niet. En je hebt geen juridisch middel als het contract niets zegt over overdracht.
Hetzelfde geldt voor je domeinnaam. Wie heeft het domein geregistreerd? Op wiens naam staat het? Als het domein op naam van het bureau staat, ben jij niet de eigenaar. Als dat bureau stopt of de relatie verslechtert, heb je een probleem. Jouw domeinnaam is jouw merk. Die hoort op jouw naam te staan, bij een registrar waar jij inloggegevens van hebt.
Controleer voor je tekent:
- Staat er expliciet in het contract dat de broncode na oplevering en volledige betaling eigendom wordt van jou?
- Is de domeinnaam geregistreerd op jouw naam, of word dat geregeld?
- Wie beheert de hosting, en heb jij toegang tot dat account?
- Zijn er licenties van derde partijen (thema’s, plugins, lettertypen) en wat zijn de voorwaarden daarvan?
Als een bouwer zegt “dat regelen we wel”, vraag dan om het op papier. Niet omdat je ze wantrouwt, maar omdat mensen vergeten wat er mondeling is afgesproken. Zeker als er later een conflict ontstaat.
Oplevering, testen en wat er daarna gebeurt
Een website is “af” als de bouwer zegt dat hij af is. Maar af voor de bouwer en af voor jou zijn twee verschillende dingen. Zonder heldere opleveringscriteria in het contract heb je geen grond om te zeggen dat iets niet klopt.
Wat hoort er bij een goede oplevering? In elk geval een testperiode waarin jij de site doorloopt en fouten of afwijkingen van de afspraak kunt melden. Die periode moet lang genoeg zijn om de site grondig te testen, niet drie werkdagen. Denk aan twee tot vier weken, afhankelijk van de complexiteit.
Leg ook vast wat er na oplevering nog gedekt is. De meeste bouwers bieden een garantieperiode voor bugs. Maar wat valt er precies onder een bug? Als een formulier niet werkt, is dat een bug. Als jij vindt dat de kleur van een knop toch anders moet, is dat een wens en geen fout. Die grens moet in het contract staan.
Na de garantieperiode begint het onderhoud. Dit is het deel dat opdrachtgevers het vaakst vergeten te regelen voor ze tekenen, en later het meest betreuren. Een website heeft onderhoud nodig: beveiligingsupdates, software-updates, technische controles. Als je dat niet regelt, veroudert je site en ontstaan er kwetsbaarheden.
Vragen die je voor oplevering beantwoord wilt hebben:
- Wat zijn de exacte opleveringscriteria?
- Hoe lang duurt de testfase en hoe meld je fouten?
- Wat valt er wel en niet onder de garantie?
- Is er een onderhoudscontract, wat kost dat, en wat is de opzegtermijn?
- Wat gebeurt er als je geen onderhoudscontract afsluit?
Over dat laatste: sommige bouwers bouwen hun sites zo dat je zonder hun onderhoud eigenlijk niet verder kunt. Dat is geen goede uitgangspositie. Een eerlijk contract beschrijft ook wat er gebeurt als de samenwerking stopt.
Toegankelijkheid en wat je zelf moet kunnen beheren
Er zijn twee dingen die opdrachtgevers structureel onderschatten: toegankelijkheid en beheerbaarheid. Beide hebben te maken met wat de website doet voor mensen die hem gebruiken, en met wat jij kunt doen zonder telkens de bouwer te bellen.
Toegankelijkheid betekent dat je website bruikbaar is voor mensen met een beperking. Denk aan bezoekers die een schermlezer gebruiken, mensen met een motorische beperking die niet met een muis werken, of mensen met een visuele beperking die grote letters of hoog contrast nodig hebben. Dit is niet alleen een ethische kwestie. Voor veel organisaties is het ook een wettelijke verplichting, en die verplichting wordt strenger. Als jouw bouwer hier niets over zegt en het contract er niets over vermeldt, is de kans groot dat toegankelijkheid niet standaard is meegenomen.
Vraag expliciet welke toegankelijkheidsrichtlijnen gevolgd worden en hoe dat getest wordt. Laat het antwoord in het contract zetten. “We bouwen toegankelijk” is geen antwoord. Concrete richtlijnen en een testmethode zijn een antwoord.
Beheerbaarheid is het andere punt. Jij moet na oplevering zelf teksten kunnen aanpassen, afbeeldingen kunnen wisselen, nieuwe pagina’s kunnen aanmaken. Als dat niet kan zonder de bouwer te bellen, ben je afhankelijk en betaal je voor elke kleine aanpassing. Dat kost geld, maar het kost ook tijd. En het maakt je kwetsbaar als de relatie met de bouwer verslechtert.
Controleer voor je tekent:
- Welk systeem gebruik je om de site te beheren, en hoe makkelijk is dat voor iemand zonder technische kennis?
- Krijg je een training bij oplevering, en is die inbegrepen in de prijs?
- Is er documentatie beschikbaar van hoe het systeem werkt?
- Wat kun je zelf aanpassen, en wat niet?
Een eerlijk bureau vertelt je ook wat je niet zelf kunt doen. Dat is geen zwakte, dat is transparantie. Wees juist wantrouwig als iemand beweert dat je alles zelf kunt, zonder dat ze je laten zien hoe.
Tekenen doe je niet omdat het eindelijk zo ver is. Je tekent als je weet wat je krijgt, van wie het is, hoe het opgeleverd wordt en hoe je het daarna beheert. Dat klinkt als veel, maar de vragen zijn niet ingewikkeld. Het enige wat je nodig hebt is de bereidheid om ze te stellen voordat het geld over tafel gaat.
Een bouwer die moeite heeft met deze vragen is geen bouwer die jij wilt inhuren. Een bouwer die ze snel en helder beantwoordt, geeft je vertrouwen dat er straks ook een website staat die doet wat hij moet doen.
Leave a Reply