Checklist voor een contract webontwikkeling
De meeste geschillen over websiteprojecten gaan niet over kwaliteit maar over verwachtingen die nergens waren vastgelegd. Een contract dat de juiste dingen benoemt voorkomt vrijwel al die geschillen, en het duurt een uur om te lezen.
Deze gids behandelt wat erin hoort te staan, waarom elk punt bestaat, en de clausules waar je bij twijfel op moet aandringen.
Scope: het deel dat de meeste geschillen veroorzaakt#
«De website bouwen» is geen scope. Dit is wat er expliciet in hoort.
- Aantal unieke sjablonen, niet aantal pagina's. Vijftig pagina's op vier sjablonen is een klein project.
- Wat is inbegrepen: ontwerp, bouw, inhoud invoeren, migratie, koppelingen, testen.
- Wat níét is inbegrepen — dit is de belangrijkste zin in het hele contract.
- Wie de teksten schrijft, en wie de foto's levert.
- Aantal ontwerprondes en wat een «ronde» is.
- Ondersteunde browsers en apparaten, en het uitgangspunt voor toegankelijkheid.
- Prestatiedoelen als die belangrijk zijn, uitgedrukt in meetbare waarden.
- Welke talen, en wie de vertalingen levert.
Een leverancier die uit zichzelf opschrijft wat er níét in zit, is meestal een leverancier die eerder een projectgeschil heeft meegemaakt — dat is een goed teken.
Eigendom, toegang en uittreden#
Deze punten voelen abstract tot je van leverancier wilt wisselen, en dan zijn het de enige die tellen.
| Punt | Wat het contract moet zeggen |
|---|---|
| Broncode | Gaat volledig naar jou bij eindbetaling |
| Ontwerpbestanden | Ook van jou, inclusief de bronbestanden |
| Domeinnaam | Op jouw naam geregistreerd, met jouw toegang |
| Hosting | Op jouw account, of overdraagbaar op verzoek |
| Accounts van derden | Analyse, e-mail, betaaldienst — op jouw naam |
| Licenties van derden | Welke, en wie ze na afloop betaalt |
| Overdracht | Documentatie en toegangsoverdracht bij beëindiging |
| Portfoliogebruik | Zij mogen het tonen; redelijk om toe te staan |
Domein en hosting op naam van de leverancier is de meest voorkomende manier waarop bedrijven vast komen te zitten. Controleer dat vóór ondertekening, niet bij vertrek.
Betaling, doorlooptijd en wijzigingen#
Deze drie hangen samen: wie wanneer betaalt, wat de datum bepaalt, en wat er gebeurt als de scope groeit.
- Betaling in fasen gekoppeld aan opleveringen, niet aan kalenderdata.
- Een aanbetaling is normaal; volledige vooruitbetaling is dat niet.
- Een slottermijn na oplevering, groot genoeg om betekenis te hebben.
- Wederzijdse afhankelijkheden: de planning schuift als jij teksten te laat aanlevert, en dat hoort er te staan.
- Een wijzigingsprocedure: elke uitbreiding krijgt een geschreven raming vóór het werk begint.
- Uurtarief voor werk buiten de scope, vooraf vastgelegd.
- Wat er gebeurt bij vertraging aan beide zijden — niet alleen aan de jouwe.
- Beëindigingsvoorwaarden: hoe je stopt en wat er dan betaald en overgedragen wordt.
Garantie, onderhoud en aansprakelijkheid#
Het deel dat over de periode na de lancering gaat, en dat het vaakst ontbreekt.
| Punt | Redelijke afspraak |
|---|---|
| Bugperiode | Dertig tot negentig dagen kosteloos herstel |
| Wat een bug is | Werkt niet zoals afgesproken — niet: nieuwe wens |
| Reactietijd | Werkdagen voor gewone meldingen, sneller bij storing |
| Onderhoud | Apart contract, met een expliciete opsomming |
| Beveiligingslekken | Wie patcht, binnen welke termijn |
| Persoonsgegevens | Verwerkersovereenkomst als zij gegevens verwerken |
| Aansprakelijkheid | Beperkt tot de contractwaarde is gebruikelijk |
| Geschillen | Welk recht, welke rechtbank — kort maar aanwezig |
Het onderscheid tussen «bug» en «nieuwe wens» veroorzaakt na de lancering de meeste wrijving. Eén zin die het definieert bespaart maanden discussie.
Veelgestelde vragen
Heb ik een contract nodig voor een klein project?
Ja, al mag het kort zijn. Twee pagina's die scope, prijs, betaalmomenten, eigendom en wat er niet in zit vastleggen, dekken het merendeel van wat er misgaat. De kleine projecten zijn juist de projecten waarin niemand iets vastlegt en waarin de scope daardoor ongemerkt verdubbelt.
Wat als de leverancier eigenaar wil blijven van de code?
Dat is een reden om door te vragen. Bij maatwerk hoort de code na betaling van jou te zijn. Uitzondering is een eigen platform of framework van de leverancier — dan krijg je een licentie in plaats van eigendom, en dat kan redelijk zijn, mits het contract benoemt wat er gebeurt als je vertrekt of als zij stoppen.
Hoeveel moet ik vooraf betalen?
Een aanbetaling van een kwart tot een derde is gebruikelijk en redelijk. Volledige vooruitbetaling is dat niet, want dan verdwijnt elke prikkel om af te ronden. Koppel de rest aan opleveringen die je kunt zien — ontwerp goedgekeurd, bouw opgeleverd, live — in plaats van aan kalenderdata die kunnen schuiven.
Wat moet een garantieperiode dekken?
Fouten in wat is opgeleverd: dingen die niet werken zoals afgesproken. Niet: nieuwe wensen, wijzigingen door een browserupdate na maanden, of problemen door wijzigingen die jij zelf hebt gemaakt. Dertig tot negentig dagen is gebruikelijk. Zorg dat het contract definieert wat een bug is, anders discussieer je daarover op het slechtst denkbare moment.
contract webontwikkelingwebsite contractscope afsprakeneigendom broncodeopdrachtbevestiging websitegarantie website
