Hoe kies ik een betrouwbaar webontwikkelingsbedrijf in Nederland?

TL;DR

• Begin met uw bedrijfsdoelen, gebruikers, vereiste integraties, wettelijke verplichtingen, budgetrange en beperkingen rond de lancering - niet met een voorkeur voor een kleur of platform.
• Maak een shortlist van drie tot vijf bedrijven waarvan u het recente vergelijkbare werk live kunt bekijken.
• Controleer de wettelijke naam van de leverancier, het KVK-nummer, het adres, de status en tekenbevoegdheid. Een KVK-registratie bewijst dat een onderneming is geregistreerd; het bewijst niet de kwaliteit van de webontwikkeling.
• Spreek met twee recente klanten en vraag naar gemiste deadlines, wijzigingsverzoeken, ondersteuning na de lancering en of de klant het bedrijf opnieuw zou inhuren.
• Maak kennis met de projectverantwoordelijke en senior developer, niet alleen met de verkoper. Bevestig wat intern wordt uitgevoerd, wat wordt uitbesteed en waar het team werkt.
• Vergelijk offertes op basis van dezelfde briefing. Stem scope, aannames, uitsluitingen, licenties, content, integraties, testen, hosting, onderhoud en btw op elkaar af voordat u prijzen vergelijkt.
• Definieer acceptatiecriteria voor mobiele lay-outs, ondersteunde browsers, toegankelijkheid, beveiliging, Core Web Vitals, SEO-basisprincipes, analytics, formulieren en contentbeheer.
• Houd de domeinregistratie, hostingorganisatie, broncodeposito, analytics, tagmanager, Search Console en betaalaccounts op naam van uw bedrijf of onder uw beheerderscontrole.
• Leg intellectuele-eigendomsrechten, licenties van derden, dataportabiliteit, documentatie, back-ups, incidentrespons, serviceniveaus en ondersteuning bij beëindiging vast in het contract.
• Gebruik een gewogen scorekaart en een betaalde discoveryfase wanneer het project complex of onzeker is.

Bepaal eerst wat u daadwerkelijk koopt

“Een nieuwe website” kan heel verschillende soorten projecten betekenen:

• een informatieve website gebouwd met een beproefd thema
• een op maat gemaakte merk- en marketingwebsite
• een meertalig bedrijfsplatform
• een webshop met integraties voor voorraad, belasting, verzending en betalingen
• een lidmaatschaps-, boekings- of leerplatform
• een klantportaal gekoppeld aan CRM- of ERP-systemen
• een herbouw gericht op toegankelijkheid of prestaties of
• een doorlopende samenwerking voor productontwikkeling

De juiste leverancier voor een lokale bedrijfswebsite van vijf pagina’s kan ongeschikt zijn voor een transactioneel platform. Schrijf daarom vóór uw zoektocht een beslisdocument van 1 pagina.

Minimale beslisbriefing

• Bedrijfsdoel: wat moet verbeteren - gekwalificeerde aanvragen, online verkoop, sollicitaties, selfservice, werving of operationele efficiëntie?
• Gebruikers en markten: Wie gebruikt de website, in welke landen, talen en op welke apparaten?
• Belangrijke gebruikersroutes: Wat moet een bezoeker kunnen voltooien?
• Content: Wie schrijft, vertaalt, keurt goed en migreert de content?
• Functionaliteiten: formulieren, zoeken, betalingen, boekingen, accounts, calculators, afgeschermde content of personalisatie.
• Integraties: CRM, ERP, productinformatie, e-mail, identiteit, betalingen, verzending, analytics of andere API’s.
• Beperkingen: lanceerdatum, inkoopregels, merksysteem, bestaand platform, hosting, interne vaardigheden en compliance.
• Succescriteria: nulmeting en doelstelling voor conversie, taakvoltooiing, prestaties, toegankelijkheid, organische zichtbaarheid of vermindering van supportvragen.
• Budgetrange: een realistische investeringsrange, inclusief discovery, bouw, licenties, content, hosting en ondersteuning voor het eerste jaar.

Een bedrijf kan geen verantwoorde inschatting maken wanneer de behoefte niet duidelijk is gedefinieerd. Een zelfverzekerde vaste offerte op basis van een kort gesprek kan eerder verborgen aannames bevatten dan echte zekerheid.

Kies het juiste type leverancier

“Full service” moet worden geverifieerd. Vraag welke expertise intern beschikbaar is, welke werkzaamheden door partners worden uitgevoerd en wie eindverantwoordelijk blijft wanneer meerdere bedrijven betrokken zijn.

Stap 1: stel een shortlist samen op basis van bewijs, niet alleen op rankings

Gebruik aanbevelingen, sectornetwerken, professionele communities, inkoopplatforms en gerichte zoekopdrachten. Zoek op het probleem, het platform of de sector, en niet alleen op “beste webontwikkelingsbedrijf Nederland.” Voorbeelden zijn:

• “Shopify Plus ontwikkelbureau Nederland B2B”
• “WordPress meertalige zorgwebsite Nederland”
• “toegankelijke webontwikkeling publieke sector Utrecht”; of
• “maatwerk klantportaal Microsoft Dynamics Nederland.”

Directories en reviewplatforms kunnen helpen om bedrijven te vinden, maar posities in ranglijsten, badges en aantallen reviews kunnen betaald, onvolledig of gemanipuleerd zijn. Beschouw ze als leads en niet als bewijs.

Maak eerst een lijst van zes tot tien leveranciers en breng die vervolgens terug tot drie tot vijf op basis van niet-onderhandelbare criteria:

• geschikt projecttype en technische stack
• bewijs van vergelijkbare complexiteit
• beschikbaarheid binnen de vereiste periode
• mogelijkheid om in de vereiste taal te werken
• acceptabele locatie of werkwijze op afstand
• capaciteit om te voldoen aan eisen op het gebied van privacy, beveiliging en toegankelijkheid; en
• Bereidheid om te werken met duidelijke afspraken over eigendom en overdracht.

Stap 2: Verifieer het Nederlandse bedrijf achter de offerte

Vraag naar de volgende gegevens van de leverancier:

• volledige juridische naam en handelsnaam;
• KVK-nummer;
• btw-identificatienummer indien van toepassing;
• geregistreerd adres en vestigingsadres;
• rechtsvorm;
• bevoegde ondertekenaar;
• gegevens over beroepsaansprakelijkheids- en cyberverzekering, indien proportioneel; en
• Relevante algemene voorwaarden.

Gebruik de officiële KVK-dienst om de registratie te bevestigen en bestel bij substantiële contracten een recent uittreksel uit het Handelsregister. KVK legt uit dat een gewaarmerkt uittreksel een officieel bewijs van inschrijving is en de bedrijfsgegevens weergeeft zoals die gelden op het moment van de aanvraag.

Controleer of de persoon die ondertekent bevoegd is om de onderneming te vertegenwoordigen. Business.gov.nl merkt op dat het ontbreken van tekenbevoegdheid gevolgen kan hebben voor de geldigheid van een contract.

Wat KVK-verificatie u wel en niet kan vertellen

Het kan helpen om identiteit, registratie, rechtsvorm, adres en bevoegde vertegenwoordigers te bevestigen. Het certificeert geen technische expertise, financiële stabiliteit, ethisch handelen of toekomstige uitvoering.

Gebruik aanvullende bewijsstukken:

• Komt de juridische naam op de offerte overeen met die op de factuur en de bankrekening?
• Hoe lang werkt het relevante team al bij deze entiteit?
• Heeft het bedrijf recent zijn naam, bestuurders of eigendomsstructuur gewijzigd?
• Is het portfolio eigen werk of betreft het werk dat oprichters eerder bij voormalige werkgevers hebben uitgevoerd?
• Is het bedrijf afhankelijk van één oprichter of één externe ontwikkelaar?
• Kan het bedrijf continuïteit garanderen als een belangrijke medewerker vertrekt?

Overweeg bij een groot of bedrijfskritisch project om, in verhouding tot het risico, financiële en juridische due diligence uit te voeren met uw accountant of adviseur.

Stap 3: Bekijk live projecten, niet alleen portfolio-screenshots

Vraag om drie projecten die in de afgelopen twee of drie jaar zijn afgerond en die op minstens twee punten vergelijkbaar zijn met uw project: sector, bedrijfsmodel, platform, complexiteit van integraties, meertalige content, verkeer, transactierisico of toegankelijkheidseisen.

Open de live websites op desktop en mobiel. Beoordeel niet alleen de visuele uitstraling. Test:

• Kunt u snel begrijpen wat het aanbod is en wat de volgende stap is?
• Werken menu’s, formulieren, zoekfuncties, filters en het afrekenproces goed?
• Is de tekst goed leesbaar en is de navigatie bruikbaar met een toetsenbord?
• Laden de pagina’s snel via een normale mobiele internetverbinding?
• Zijn de cookiekeuzes duidelijk, of worden trackingcookies te vroeg geplaatst?
• Zijn titels, koppen, canonieke URL’s en indexeerbare content op een logische manier geïmplementeerd?
• Zijn foutmeldingen, lege toestanden, laadstatussen en bevestigingsmeldingen consistent?
• Lijkt de website na de lancering nog steeds goed te worden onderhouden?

Gebruik openbare diagnostische tools als aanwijzingen, niet als definitief oordeel. Internet.nl test of websites en e-mail moderne, betrouwbare internetstandaarden gebruiken. PageSpeed Insights en browsertools kunnen prestatiesignalen zichtbaar maken. Geautomatiseerde toegankelijkheidstools signaleren sommige problemen, maar handmatig testen met toetsenbord en ondersteunende technologie blijft noodzakelijk.

Vraag naar het verhaal achter elk project

Vraag bij elke case study:

• Wat was het zakelijke probleem en wat was de uitgangssituatie?
• Wat heeft uw team zelf geleverd?
• Welke specifieke personen hebben eraan gewerkt en worden zij ook aan ons project toegewezen?
• Welke integraties of beperkingen maakten het project moeilijk?
• Wat is er veranderd na gebruikerstesten of technische discovery?
• Welke meetbare resultaten zijn verbeterd en over welke periode?
• Wat is mislukt of uitgesteld?
• Wie onderhoudt de website nu?

Een resultaat zonder uitgangssituatie, meetmethode of duidelijke toeschrijving is marketing - geen betrouwbaar bewijs.

Stap 4: Spreek met recente klanten

Vraag om twee referenties van projecten die qua omvang vergelijkbaar zijn en recent genoeg zijn afgerond om de ondersteuning na de lancering te kunnen beoordelen. Vraag de kandidaat om toestemming om rechtstreeks contact met hen op te nemen.

Vragen voor referenties:

• Was de oorspronkelijke scope duidelijk en realistisch?
• Heeft het team risico’s vroegtijdig aangegeven?
• Hoe dicht lagen de uiteindelijke kosten en opleverdatum bij het afgesproken plan, en waarom weken ze eventueel af?
• Zijn wijzigingsverzoeken gedocumenteerd en goedgekeurd voordat het werk werd uitgevoerd?
• Bleef het seniorteam betrokken na de verkoop?
• Hoe goed werkte de website bij de lancering?
• Zijn ernstige fouten snel opgelost?
• Waren de training en documentatie voldoende?
• Kan uw team routinematige wijzigingen uitvoeren zonder de leverancier?
• Hoe presteert de ondersteuning zes of twaalf maanden later?
• Wat zou u anders doen?
• Zou u het bedrijf opnieuw inhuren voor een vergelijkbaar project?

De meest onthullende vraag is vaak: “Vertel me over een moeilijk moment en hoe het bureau daarmee omging.” Elk substantieel project kent onzekerheden. Betrouwbaarheid blijkt uit de manier waarop daarop wordt gereageerd.

Stap 5: Maak kennis met het daadwerkelijke uitvoeringsteam

Een goede klik met het salesteam zegt niets over de daadwerkelijke uitvoeringscapaciteit. Maak vóór de opdracht kennis met de voorgestelde:

• project- of deliverymanager;
• senior developer of technisch architect;
• UX- of productdesigner;
• QA-verantwoordelijke of persoon die verantwoordelijk is voor het testen; en
• Verantwoordelijke voor ondersteuning na de lancering.

Vraag welk percentage van hun tijd voor uw project is gereserveerd, aan welke andere projecten zij werken en of genoemde personen kunnen worden vervangen. Als werkzaamheden worden uitbesteed, identificeer dan de onderaannemer, het land, de verantwoordelijkheden, de toegang tot persoonsgegevens, de beveiligingsmaatregelen en het continuïteitsplan.

Let op bewijs van goede communicatie

Een betrouwbaar team kan:

• Het probleem in duidelijke taal opnieuw formuleren;
• onbeantwoorde vragen identificeren;
• alternatieven en afwegingen uitleggen;
• onderscheid maken tussen een vereiste en een aanname;
• zeggen “dat weten we nog niet” en voorstellen hoe dit kan worden uitgezocht;
• beslissingen en verantwoordelijkheden documenteren; en
• Een ongeschikt verzoek op een respectvolle manier ter discussie stellen.

Vermijd teams die met elke functie instemmen, een datum beloven voordat afhankelijkheden zijn onderzocht of technische beslissingen achter jargon verbergen.

Stap 6: Beoordeel het discovery- en opleverproces

Het proces moet aansluiten bij de mate van onzekerheid binnen het project. Voor een kleine website kunnen een korte workshop en een prototype voldoende zijn. Voor een maatwerkportaal kunnen onderzoek, architectuur, datamapping en een betaalde discoveryfase nodig zijn voordat een verantwoorde inschatting van de bouw kan worden gemaakt.

Een geloofwaardig proces omvat doorgaans

• discovery met stakeholders en gebruikers;
• analyse van analytics en de huidige website;
• contentinventarisatie en planning van de migratie;
• functionele en niet-functionele vereisten;
• informatiearchitectuur en gebruikersflows;
• prototypes en validatie van gebruiksvriendelijkheid;
• technische architectuur en onderzoek naar integraties;
• vereisten op het gebied van privacy, beveiliging en toegankelijkheid;
• geprioriteerde backlog en releaseplan;
• beslissingen over design en het componentsysteem;
• ontwikkeling, code review en geautomatiseerde tests;
• QA op verschillende apparaten, browsers en gebruikerssituaties;
• contentinvoer en training voor redacteuren;
• acceptatietesten en een generale repetitie voor de lancering;
• monitoring, back-ups en rollback; en
• Garantie en doorontwikkeling na de lancering.

Vraag om concrete werkdocumenten te zien

Vraag om geanonimiseerde voorbeelden van een discoveryrapport, backlogitem, beslislogboek, testplan, toegankelijkheidsbevinding, releasechecklist en supportrapport. Een proces dat alleen in presentaties wordt beschreven, is minder overtuigend dan bewijs dat het daadwerkelijk wordt toegepast.

Stap 7: Test technische expertise zonder zelf developer te worden

U hoeft de programmeertaal niet zelf te kiezen. U moet weten of het bedrijf onderhoudbare keuzes maakt en deze duidelijk kan uitleggen.

Vraag:

• Waarom past het voorgestelde platform bij onze gebruikers, redacteuren, integraties, schaal en interne vaardigheden?
• Welke onderdelen zijn standaard, geconfigureerd, aangepast of volledig vanaf nul gebouwd?
• Welke verplichtingen op het gebied van upgrades en onderhoud worden verwacht?
• Hoe wordt de code beoordeeld en getest?
• Hoe werken ontwikkelomgevingen, deployment en rollback?
• Hoe wordt gestructureerde content gescheiden van de presentatie?
• Hoe worden fouten in API’s veilig afgehandeld en gemonitord?
• Welke componenten zorgen voor vendor lock-in?
• Hoe kan een ander competent bedrijf het project overnemen?
• Welke technische schuld accepteert u bewust?

Geef de voorkeur aan eenvoudige duidelijkheid boven modieuze complexiteit

Een gewone contentwebsite heeft zelden de architectuur van een wereldwijd softwareplatform nodig. Omgekeerd moet een transactionele dienst met veel verkeer niet worden gedwongen om te werken met een kwetsbare verzameling plugins alleen omdat dit aanvankelijk goedkoop is. De juiste architectuur is de eenvoudigste oplossing die voldoet aan de huidige vereisten en geloofwaardige toekomstige behoeften.

Stap 8: maak beveiliging een contractuele vereiste

“We gebruiken SSL” is geen beveiligingsprogramma. Vereis een risicogebaseerde aanpak die ontwerp, ontwikkeling, deployment en onderhoud omvat.

Vraag voor een standaardwebsite naar:

• multifactorauthenticatie voor administratieve toegang;
• rollen met minimale toegangsrechten en afzonderlijke gebruikersaccounts;
• updates van afhankelijkheden en CMS/plugins;
• veilige verwerking van secrets en API-sleutels;
• versleutelde gegevensoverdracht en passende beveiligingsheaders;
• misbruik van formulieren, spam en rate limiting;
• back-ups, hersteltests en bewaartermijnen;
• logging, monitoring en waarschuwingen;
• rapportage van kwetsbaarheden en incidentrespons;
• goedkeuring van deployments en rollback; en
• Verwijdering van testgegevens en toegangsrechten na de lancering.

Gebruik voor webapplicaties met accounts, betalingen of gevoelige gegevens een gestructureerde standaard. OWASP ASVS is ontwikkeld ter ondersteuning van ontwikkeling, beveiligingsverificatie en inkoopvereisten. Specificeer de relevante versie en het risicogeschikte verificatieniveau in plaats van alleen “OWASP-compliant” te vermelden.

Het Nederlandse NCSC onderhoudt actuele TLS-beveiligingsrichtlijnen. Vraag wie beveiligingsadviezen monitort en hoe snel kritieke updates worden beoordeeld en geïnstalleerd. Een beveiligingscertificaat is ondersteunend bewijs, maar geen bewijs dat uw opgeleverde website daadwerkelijk veilig is.

Stap 9: Controleer expertise op het gebied van privacy en cookies

Als het bedrijf namens u persoonsgegevens host, ondersteunt of kan inzien, bepaal dan samen met uw privacyadviseur de rollen onder de AVG. De richtlijnen van de Europese Commissie voor verwerkers geven aan dat een verwerker een overeenkomst of andere rechtshandeling nodig heeft en voldoende garanties moet bieden voor passende technische en organisatorische maatregelen. De richtlijnen behandelen ook vertrouwelijkheid, instructies van de verwerkingsverantwoordelijke en subverwerkers.

Vraag naar:

• een gegevensstroomdiagram voor formulieren, analytics, CRM, hosting, back-ups en ondersteuning
• het doel en de rechtsgrond voor elke stroom van persoonsgegevens
• de identiteit en locatie van verwerkers en subverwerkers
• regels voor gegevensbewaring en verwijdering
• toegangscontroles en auditlogs
• de procedure voor het melden van datalekken
• het mechanisme voor internationale gegevensoverdracht, indien relevant; en
• een passende verwerkersovereenkomst wanneer het bureau als verwerker optreedt

Cookiebanners zijn een praktische test van expertise. De Autoriteit Persoonsgegevens heeft opgetreden tegen websites waar de mogelijkheid om te weigeren verborgen was, keuzes vooraf waren geselecteerd of tracking plaatsvond voordat geldige toestemming was verkregen. De richtlijnen voor cookiebanners benadrukken duidelijke doeleinden, niet vooraf aangevinkte vakjes en even toegankelijke keuzemogelijkheden. Vraag het bureau om het toestemmingsgedrag in de browser te demonstreren - en niet alleen het ontwerp van de banner te tonen.

Uw organisatie blijft verantwoordelijk voor de doeleinden en middelen die zij bepaalt. Besteed het nadenken over privacy niet volledig uit als onderdeel van de bouw.

Stap 10: Maak toegankelijkheid meetbaar

Toegankelijkheid moet worden ontworpen en getest, niet vlak voor de lancering worden toegevoegd met een overlay. Vraag het bedrijf welke standaard, welk niveau, welke scope, testmethode en welk bewijs het zal gebruiken.

WCAG 2.2 is de nieuwste W3C-standaard en structureert de vereisten volgens de principes waarneembaar, bedienbaar, begrijpelijk en robuust. W3C moedigt het gebruik van WCAG 2.2 aan. Een praktisch doel voor inkoop is vaak WCAG 2.2 niveau AA, maar toepasselijke Nederlandse of EU-regels, sectorspecifieke verplichtingen en contracten kunnen verwijzen naar specifieke standaarden of versies.

De European Accessibility Act is sinds 28 juni 2025 van toepassing op producten en diensten die binnen de reikwijdte vallen. Officiële Nederlandse richtlijnen voor bedrijven noemen e-commerce als een van de diensten die onder de wet vallen en beschrijven vereisten voor toegankelijkheidsverklaringen en dienstverlening, afhankelijk van de reikwijdte en uitzonderingen. Verplichtingen voor de publieke sector en specifieke sectoren kunnen verschillen. Win juridisch advies in voor uw dienst.

Vereist:

• toegankelijke componenten en richtlijnen voor het creëren van content;
• testen met toetsenbord en schermlezer;
• testen van zoom, reflow, contrast en mobiel gebruik;
• testen van formulieren, foutmeldingen, menu’s, dialoogvensters en dynamische toestanden;
• het meenemen van externe checkout-, boekings- of consenttools;
• een gedocumenteerde audit en herstelwerkzaamheden vóór acceptatie; en
• Een plan om regressies na de lancering te voorkomen.

Alleen een geautomatiseerde score is geen bewijs van conformiteit.

Stap 11: Definieer prestaties en SEO-basisprincipes

“Snel” en “SEO-vriendelijk” zijn geen acceptatiecriteria.

Prestaties

Definieer representatieve paginatypen, apparaten en meetomstandigheden. De Core Web Vitals-richtlijnen van Google gebruiken momenteel:

• LCP van 2,5 seconden of minder voor laadtijd
• INP van 200 milliseconden of minder voor interactiviteit; en
• CLS van 0,1 of minder voor visuele stabiliteit

Gemeten op het 75e percentiel, afzonderlijk voor mobiel en desktop. Nieuwe websites beschikken niet direct over voldoende veldgegevens van echte gebruikers, dus gebruik vóór de lancering labbudgetten en implementeer daarna monitoring van echte gebruikers. In het contract moet worden vastgelegd welke partij verantwoordelijk is voor optimalisatie als externe tags, content of hosting later de resultaten beïnvloeden.

Technische SEO-basisprincipes

Vereis correcte:

• indexeerbaarheid en robots-instellingen
• canonieke URL’s en redirectmapping
• paginatitels, metabeschrijvingen en koppen
• semantische HTML en interne links
• XML-sitemaps
• gestructureerde data waar deze daadwerkelijk van toepassing is
• taal- en regionale signalen voor meertalige websites
• afbeeldingsbeheer en workflow voor alt-teksten
• strategie voor paginering of gefacetteerde navigatie waar relevant
• instellen van Analytics en Search Console; en
• monitoring van migraties bij gewijzigde URL’s

Geen enkele developer kan rankings garanderen. Vraag hoe bestaande organische waarde behouden blijft en hoe de website technisch goed vindbaar wordt gemaakt.

Stap 12: vergelijk offertes regel voor regel

Stuur elk geselecteerd bedrijf dezelfde briefing en dezelfde vragenlijst. Een betrouwbare offerte moet het volgende bevatten:

• begrip van de doelstellingen en gebruikers
• scope en duidelijk benoemde deliverables
• aannames, afhankelijkheden en uitsluitingen
• discovery- en validatieactiviteiten
• teamrollen en beschikbaarheid
• projectplan, mijlpalen en verantwoordelijkheden van de klant
• technologie- en hostingaanpak
• verantwoordelijkheden voor content en migratie
• scope van integraties
• test- en acceptatiemethode
• toezeggingen op het gebied van beveiliging, privacy, toegankelijkheid en prestaties
• prijs, btw, betalingsschema en tarieven
• licenties van derden en terugkerende kosten
• garantie, ondersteuning en onderhoud
• eigendom en overdracht; en
• geldigheidsduur van de offerte en contractuele voorwaarden

Vergelijk de werkelijke totale kosten

Totaalprijzen zijn niet vergelijkbaar wanneer de ene offerte contentmigratie, toegankelijkheidstesten en het eerste jaar aan licenties bevat en de andere niet.

Vaste prijs, nacalculatie of hybride?

• Vaste prijs past bij een stabiele en duidelijk gedefinieerde scope. Hiermee wordt een deel van het inschattingsrisico overgedragen, maar vaak wordt er een risicomarge in de prijs opgenomen en is strak wijzigingsbeheer nodig.
• Nacalculatie past bij discovery en doorlopende productontwikkeling. Dit vereist transparante prioriteiten, budgetbewaking en frequente demonstraties.
• Hybride kan gebruikmaken van discovery of mijlpalen tegen een vaste prijs, gecombineerd met een begrensde of doorlopende uitvoering.

Het prijsmodel bepaalt niet of een leverancier betrouwbaar is. Duidelijke scope, bewijs, governance en transparantie doen dat wel.

Gebruik een gewogen selectiescorekaart

Geef elke kandidaat een score van 1 tot 5 en vermenigvuldig deze met het gewicht. Spreek de wegingsfactoren af voordat u de definitieve offertes beoordeelt, zodat de presentatie de prioriteiten niet vertekent.

Voeg een geslaagd/niet-geslaagd criterium toe voor niet-onderhandelbare voorwaarden zoals KVK-verificatie, datalocatie, toegankelijkheid, platform, verzekering of capaciteit om binnen de gewenste termijn te lanceren. Een hoge totaalscore mag een niet-behaalde kritieke vereiste niet compenseren.

Contractclausules die kostbare verrassingen voorkomen

Laat een materiële overeenkomst beoordelen door een geschikte Nederlandse juridische adviseur. Behandel minimaal de volgende punten.

Scope en acceptatie

Definieer deliverables, uitgesloten werkzaamheden, acceptatiecriteria, beoordelingsperioden, ernstniveaus van defecten en wat er gebeurt als de acceptatie niet wordt behaald. Vermijd termen als “kwaliteit volgens industriestandaard” zonder meetbare details.

Mijlpalen en betaling

Koppel betalingen aan betekenisvolle opleveringen of tijdsperioden, niet aan vage percentages. Behoud voldoende onderhandelingsruimte voor definitieve documentatie, overdracht van accounts en herstel van defecten. Vermijd een grote niet-restitueerbare vooruitbetaling zonder overeenkomstige waarde of bescherming.

Wijzigingsbeheer

Elke wijziging moet vóór goedkeuring de gevolgen voor scope, prijs, planning, kwaliteit en afhankelijkheden vermelden. Leg vast wie wijzigingen mag goedkeuren.

Intellectueel eigendom en licenties

Nederlands auteursrecht kan originele software en ander creatief werk automatisch beschermen. Business.gov.nl legt uit dat software auteursrechtelijk beschermd kan zijn en dat deze rechten automatisch ontstaan. Ga er niet van uit dat betaling automatisch eigendom overdraagt.

Specificeer:

• eigendom of licentie voor maatwerkcode, ontwerp, teksten, data en documentatie;
• het moment en de voorwaarden van eventuele overdracht;
• rechten op reeds bestaande frameworks van de leverancier;
• open-source- en commerciële licenties van derden;
• of componenten opnieuw mogen worden gebruikt voor andere klanten;
• garanties met betrekking tot bevoegdheid en inbreuk op rechten; en
• Uw recht om wijzigingen aan te brengen en een andere leverancier aan te stellen.

Accounts, domein en broncodebeheer

De klant moet normaal gesproken controle hebben over het account van de domeinregistrant en de belangrijkste serviceaccounts. Voor .nl-domeinen legt SIDN uit dat voor overdracht een token nodig is en dat de registrar dit op verzoek binnen vijf dagen moet verstrekken. Zie de richtlijnen voor registrars van SIDN.

Vereis beheerderstoegang tot:

• domein en DNS;
• hosting- en cloudaccount;
• broncoderepository;
• CMS en database;
• analytics, tagmanager en consentplatform;
• Google Search Console en advertentieaccounts;
• diensten voor e-mailverzending;
• betaal- en e-commerceaccounts; en
• Bronbestanden van ontwerpen en gelicentieerde assets.

Gebruik door het bedrijf beheerde e-mailadressen en multifactorauthenticatie. Wacht niet tot er een conflict ontstaat om te ontdekken dat het bureau de sleutels beheert.

Garantie en ondersteuning

Definieer de garantieperiode voor defecten, wat als defect geldt, respons- en hersteltijden per ernstniveau, supporturen, noodcontacten, uitsluitingen en escalatie. Maak onderscheid tussen:

• responstijd: wanneer de leverancier het probleem bevestigt en met triage begint;
• Doel voor workaround: wanneer de essentiële dienstverlening tijdelijk wordt hersteld; en
• Doel voor oplossing: wanneer het onderliggende defect definitief is opgelost.

Beveiliging, privacy en incidenten

Neem minimale beveiligingsmaatregelen, afhandeling van kwetsbaarheden, patchtermijnen, melding van datalekken, subverwerkers, gegevensverwijdering, auditbewijs en samenwerkingsverplichtingen op. Stem de verplichtingen af op het daadwerkelijke risico.

Beëindiging en exit

Leg opzegtermijnen, exportformaten, overdracht van repository en accounts, documentatie, uren voor kennisoverdracht, teruggave en verwijdering van gegevens, ondersteuningstarieven en deadlines vast. Zorg ervoor dat de website kan blijven functioneren als de samenwerking eindigt.

Business.gov.nl legt uit dat algemene voorwaarden betrekking kunnen hebben op betaling, levering, reparaties, garanties en geschillen, en dat klanten hierover vóór het sluiten van de overeenkomst moeten worden geïnformeerd. Lees zowel de offerte als de opgenomen algemene voorwaarden; tegenstrijdige bepalingen moeten worden opgelost volgens de in de ondertekende overeenkomst vastgelegde rangorde.

Waarschuwingssignalen van een onbetrouwbaar webbedrijf

• Het bedrijf weigert een KVK-nummer te verstrekken, of de contracterende entiteit verandert onverwacht.
• Het bedrijf kan niet aangeven wie het project daadwerkelijk zal uitvoeren.
• Het portfolio bestaat voornamelijk uit screenshots, niet-actieve websites of werk dat bij vorige werkgevers is uitgevoerd.
• Alle referenties zijn oud, niet relevant of niet beschikbaar.
• Het bedrijf adviseert een platform voordat het inzicht heeft in de gebruikers, content en integraties.
• Het belooft gegarandeerde Google-rankings of perfecte toegankelijkheid via een plugin.
• Het beschouwt een beveiligingscertificaat of HTTPS als de volledige beveiligingsoplossing.
• Het wil trackingcookies laden voordat geldige toestemming is verkregen, zonder een onderbouwde juridische grondslag.
• Het wil het domein, de hosting en analytics uitsluitend op eigen naam registreren.
• Het wil geen toegang tot de repository, back-ups of exportrechten verstrekken.
• De offerte bevat een totaalprijs, maar weinig aannames, uitsluitingen of acceptatiecriteria.
• Het bedrijf zet u onder druk om direct te tekenen door een grote korting aan te bieden.
• Het vermijdt gesprekken over onderhoud, licenties, vendor lock-in of beëindiging.
• Het beschouwt documentatie als overbodig.
• Het stemt in met een onrealistische deadline zonder afhankelijkheden aan de kant van de klant te benoemen.
• Het kan geen mislukt project of moeilijke klantsituatie toelichten.

Eén waarschuwingssignaal kan een onschuldige verklaring hebben. Een patroon van gebrek aan transparantie vormt het echte risico.

Vragen om te stellen tijdens het laatste gesprek

Bedrijf en gebruikers

• Wat moet dit project volgens u bereiken?
• Welke aanname in onze briefing baart u de meeste zorgen?
• Hoe valideert u dat de oplossing goed werkt voor gebruikers?
• Welke gevraagde functionaliteit zou u ter discussie stellen en waarom?

Uitvoering

• Wie is dagelijks verantwoordelijk en wie mag technische beslissingen nemen?
• Laat ons zien hoe voortgang, risico’s, budget en beslissingen worden gerapporteerd.
• Wat gebeurt er als wij te laat zijn met content of feedback?
• Wat is uw proces voor wijzigingsbeheer?
• Vertel ons over een vergelijkbaar project dat afweek van de oorspronkelijke planning.

Technologie en kwaliteit

• Waarom is deze technische stack geschikt en welke alternatieven heeft u afgewezen?
• Wat wordt geautomatiseerd getest, wat wordt handmatig getest en door wie?
• Hoe voorkomt u regressies?
• Hoe kan een andere leverancier het project overnemen?
• Welk onderdeel zal over drie jaar het moeilijkst te onderhouden zijn?

Beveiliging, privacy en toegankelijkheid

• Welke beveiligingseisen en verificatiestandaard worden contractueel vastgelegd?
• Wie zijn de verwerkers en subverwerkers en waar worden gegevens verwerkt?
• Demonstreer technisch hoe de cookietoestemming werkt.
• Welke WCAG-versie en welk niveau test u en welk bewijs ontvangen wij?
• Zet u waar nodig testers met een beperking of onafhankelijke specialisten in?

Commerciële voorwaarden en ondersteuning

• Welke kosten zijn uitgesloten of zullen waarschijnlijk veranderen?
• Welke terugkerende licentie- en infrastructuurkosten kunnen we over een periode van drie jaar verwachten?
• Wat valt onder de garantie en wat onder onderhoud?
• Laat de respons- en hersteltijden voor een kritisch incident zien.
• Wat ontvangen en beheren wij als het contract morgen eindigt?

Een verstandig selectieproces en tijdlijn

Fase 1: voorbereiding

• Wijs de beslisser en stakeholdergroep aan.
• Stel de beslisbriefing en budgetrange op.
• Bepaal gewogen criteria en niet-onderhandelbare voorwaarden.
• Bepaal of een betaalde discoveryfase nodig is voordat een offerte voor de bouw wordt opgesteld.

Fase 2: marktverkenning

• Selecteer zes tot tien kandidaten.
• Beoordeel relevant livewerk en de juridische identiteit.
• Nodig drie tot vijf bedrijven uit met dezelfde briefing.

Fase 3: evaluatie

• Voer een gestructureerd gesprek met het daadwerkelijke team.
• Beoordeel voorbeeldwerkdocumenten en technische antwoorden.
• Neem onafhankelijk contact op met referenties.
• Breng de scope van offertes en de totale eigendomskosten op een vergelijkbare basis.
• Laat iedereen individueel scoren vóór de bespreking met het beoordelingspanel.

Fase 4: risicovermindering

• Voer bij grote onzekerheid een betaalde discovery-sprint, technische proof of concept of designworkshop uit met de voorkeursleverancier.
• Controleer het contract, de voorwaarden, intellectuele-eigendomsrechten, privacy, beveiliging, ondersteuning en exitvoorwaarden.
• Bevestig het benoemde team, de capaciteit, startdatum en governance.

Fase 5: aanstelling en opstart

• Onderteken de definitieve scope en rangorde van documenten.
• Maak door de klant beheerde accounts aan en regel toegang tot de repository.
• Stel logboeken op voor beslissingen, risico’s, wijzigingen en acceptatie.
• Leg baselinegegevens uit analytics en migratievereisten vast voordat de ontwikkeling begint.

Wat moet een goede overdracht bevatten?

Beschouw een overdracht niet als alleen een zipbestand na de lancering. Vereis:

• broncode en volledige repositorygeschiedenis;
• instructies voor build en deployment;
• documentatie van architectuur en integraties;
• inventarisatie van omgevingen en configuraties, zonder geheime gegevens in documenten bloot te stellen;
• databaseschema en exportmethode;
• eigendom van domein, DNS, hosting en diensten;
• matrix van beheerders en rollen;
• inventarisatie van licenties en afhankelijkheden;
• procedure voor back-up en herstel, inclusief testbewijs;
• monitoring en contactgegevens voor incidenten;
• testrapporten voor toegankelijkheid, prestaties en beveiliging;
• redirectmapping en registratie van de SEO-migratie;
• training voor CMS-redacteuren en richtlijnen voor toegankelijke content;
• register van bekende problemen en technische schuld; en
• details over ondersteuning, garantie en escalatie.

Test de overdracht vóór de definitieve acceptatie: kan een bevoegde beheerder van de klant inloggen, veilig deployen, een back-up herstellen, gegevens exporteren en een andere leverancier uitnodigen zonder verborgen inloggegevens op te vragen?

Veelgestelde vragen

Uw volgende stap

Maak een shortlist van drie bedrijven en doorloop voor elk bedrijf deze bewijsgerichte controle:

• Verifieer de juridische entiteit en de bevoegde ondertekenaar via de KVK.
• Bekijk drie vergelijkbare live websites op mobiel, met toetsenbordbediening en met openbare diagnostische tools.
• Spreek met twee recente klanten.
• Maak kennis met de genoemde projectverantwoordelijke en senior developer.
• Stuur dezelfde schriftelijke briefing en vragenlijst.
• Breng scope, uitsluitingen, terugkerende kosten en totale kosten over drie jaar op een vergelijkbare basis.
• Beoordeel het bedrijf aan de hand van vooraf vastgestelde criteria.
• Controleer afspraken over eigendom, beveiliging, privacy, toegankelijkheid, ondersteuning en exit.
• Gebruik een betaalde discoveryfase als er nog grote onzekerheden bestaan.

Kies het bedrijf dat risico’s zichtbaar en beheersbaar maakt. Een betrouwbare partner zal niet beloven dat webontwikkeling eenvoudig is; die zal laten zien hoe beslissingen worden genomen, kwaliteit wordt geverifieerd en de controle bij uw bedrijf blijft.