Webdeveloper in Zoetermeer kiezen: 8 vragen die je moet stellen

Je zoekt een webdeveloper in Zoetermeer. Je wilt niet alleen een mooie site; je wilt dat het werkt, snel is, en dat je later controle houdt. Dit artikel geeft 8 concrete vragen om bureaus en freelancers te vergelijken. Praktisch, zonder fluff.

De vragen richten zich op wat vaak misgaat: wie bezit de code, hoe worden kosten berekend, wie doet het werk echt, en wat gebeurt er na de livegang. Onderweg geef ik voorbeelden, ranges voor kosten en concrete signalen waar je op moet letten.

Waarom deze 8 vragen

Kies je op basis van gut feeling, dan loop je risico. Stel gerichte vragen en krijg bruikbare antwoorden. Performance en vindbaarheid zijn geen bonusvragen; ze beïnvloeden conversie. Kijk bijvoorbeeld naar Core Web Vitals als performance-eis: een webdeveloper moet ermee bekend zijn en kunnen meten (zie https://web.dev/articles/vitals).

Ook toegankelijkheid en SEO zijn baseline-onderwerpen. Vraag naar hoe het team omgaat met de WCAG-richtlijnen en zoekmachine-optimalisatie. Google heeft praktische richtlijnen die je kunt gebruiken bij het beoordelen van een voorstel: https://developers.google.com/search/docs/essentials.

De 8 vragen (en wat je met het antwoord doet)

1) Wie bezit de code en de hostingaccounts?

Vraag expliciet wie de repository, domein en hosting beheert. Wil je volledige eigendom? Zorg dat de code naar jouw Git-repo kan worden gepusht en dat je beheerderstoegang krijgt. Rode vlag: leverancier zegt "we kunnen het hosten" maar wil geen repo-overdracht.

2) Krijg ik een vaste prijs of op urenbasis?

Een vaste prijs is helder voor scope-fixed projecten. Uren is handiger bij onduidelijke of evoluerende scope. Vraag altijd om een urenraming, een factureringsmodel en een change-procedure. Indicatieve ranges: eenvoudige bedrijfswebsite €2.000–€6.000, maatwerk webapplicatie €10.000–€50.000 (kan flink afwijken per project).

3) Wie bouwt het daadwerkelijk?

Vraag naar het team: wie is de lead developer, wie doet frontend en backend, en wie test? Freelancers doen vaak alles zelf. Bureaus werken in teams. Voordeel freelancer: één aanspreekpunt; nadeel: minder capaciteit bij ziekte of vakantie. Nadeel bureau: mogelijk meerdere handen, maar meer continuïteit.

4) Hoe zit het met support en onderhoud na livegang?

Vraag naar SLA-achtige afspraken: responstijd, doorlooptijd voor wijzigingen en veiligheidsupdates. Wil je 24–48 uur voor kleine fixes, of langere termijnen? Als je verwacht dat iemand snel pakt, leg dat vast in een onderhoudscontract. Bekijk ook welke services ze aanbieden op hun onderhoudspagina: kijk of ze actieve support hebben en wat er wel of niet is inbegrepen.

5) Hebben ze aantoonbare cases en meetbare resultaten?

Bekijk het portfolio, maar vraag door. Een referentie en een korte technische toelichting zeggen meer dan een screenshot. Vraag welke delen zij precies hebben gebouwd en welke metrics verbeterden (laadtijd, conversie) — zonder beloftes natuurlijk. Check voorbeelden op de portfolio-pagina en vraag een walkthrough: bekijk portfolio.

6) Hoe meten jullie performance en SEO-kenmerken?

Een technische builder moet Core Web Vitals kennen en kunnen verbeteren. Vraag welke tools ze gebruiken (Lighthouse, PageSpeed, Web Vitals) en hoe ze LCP/CLS/INP aanpakken. Zie praktische uitleg over performance-eisen op https://web.dev/articles/vitals en de Google-richtlijnen voor zoekmachines op https://developers.google.com/search/docs/essentials.

7) Hoe zit het met toegankelijkheid en regelgeving?

Toegankelijkheid is geen luxe. Vraag of ze ontwikkelen volgens WCAG 2.1/2.2 en welke criteria ze standaard controleren. Laat ze de contrastregels en toetsenbordnavigatie toelichten. Zie de richtlijnen: https://www.w3.org/TR/WCAG22/.

8) Security, back-ups en updates

Vraag naar deploy-processen, backups en security-hardening. Voor WordPress-projecten zijn er standaardmaatregelen zoals regelmatige back-ups en hardening; vraag welke tools en routines ze gebruiken. Een open antwoord of ontwijking is een signaal om door te vragen.

Praktische checklist om offertes te vergelijken

• Vraag om een copy van het contractvoorstel en lees eigendomsclausules.
• Vraag naar de Git-geschiedenis en toegang bij oplevering.
• Vergelijk prijzen plus wat er wel/niet in scope zit (beeld, copy, hosting).
• Controleer wie jouw vaste contactpersoon wordt en wat de vervangingsregeling is.
• Vraag naar SLA-niveaus en responstijden voor support.
• Vraag om 2 technische referenties of een korte technische walkthrough van een case.
• Laat de leverancier één performanceverbetering benoemen die ze voor jouw site zouden toepassen.

Kleine kanttekening: niet elk project heeft een vaste prijs nodig. Bij doorontwikkeltrajecten werkt urenregistratie vaak beter. Maar leg wel kaders vast.

Waar je direct op kunt letten in gesprekken

• Vraag naar voorbeelden waar ze LCP of CLS echt hebben verbeterd; concreet getal of aanpak tellen.
• Als ze geen repo-toegang willen geven, vraag waarom en overweeg alternatieven.
• Vraag altijd naar fallback: wie neemt het over als de kandidaat ziek wordt of stopt.

Volgende stap

Wil je een lokale ontwikkelaar die meteen meekijkt naar scope en budget? Vraag bij meerdere partijen hetzelfde plan aan en vergelijk. Zie wat wij doen bij DevCru en welke services we aanbieden: diensten. Als je wilt, kun je direct een vrijblijvende prijsindicatie aanvragen via offerte.