Vragen om aan een webontwikkelaar te stellen vóór je tekent
Je beoordeelt iemand die werk gaat leveren dat je niet zelf kunt controleren. De oplossing is niet technischer worden maar vragen stellen waarvan de antwoorden ook zonder technische kennis te beoordelen zijn.
Deze gids geeft die vragen, gegroepeerd per fase, met per vraag wat een sterk antwoord bevat.
Over proces en samenwerking#
Deze vragen voorspellen meer over hoe het project verloopt dan enige technische vraag.
- Hoe verloopt een typisch project bij jullie? Een sterk antwoord noemt fasen, beslismomenten en wat er van jou verwacht wordt.
- Wie werkt er werkelijk aan, en hoeveel projecten draait die persoon tegelijk? Dit voorspelt de doorlooptijd beter dan de planning.
- Hoe vaak spreken we elkaar, en hoe? Vage antwoorden hier worden later stilte.
- Wat heb je van mij nodig, en wanneer? Iemand die dit scherp beantwoordt heeft eerder projecten zien vertragen op inhoud.
- Wat gebeurt er als we halverwege iets willen wijzigen? Er hoort een procedure te zijn, geen «dat regelen we wel».
- Vertel me over een project dat moeilijk ging. Het antwoord «die hebben we niet gehad» is zelf een antwoord.
Over techniek en keuzes#
Je hoeft de techniek niet te begrijpen; je moet kunnen beoordelen of iemand zijn keuzes kan uitleggen.
| Vraag | Wat een sterk antwoord bevat |
|---|---|
| Wat bouw je dit op, en waarom? | Een reden die met jouw situatie te maken heeft |
| Wat kan ik zelf wijzigen na de lancering? | Een concrete lijst, niet «alles» |
| Hoe zorg je dat het snel is? | Concrete maatregelen en meetwaarden |
| Hoe ga je om met mobiel? | Ontwerpen vanaf mobiel, niet «het is responsief» |
| Wat doe je aan toegankelijkheid? | Een standaard en hoe ze die controleren |
| Wat doe je aan beveiliging? | Updates, back-ups, toegang, HTTPS |
| Gebruik je bestaande thema's of bouw je zelf? | Een eerlijk antwoord met de afweging erbij |
Let op of antwoorden aan jouw situatie gekoppeld worden of algemeen blijven. «Wij gebruiken altijd X» is minder informatief dan «voor wat jij nodig hebt past X, omdat».
Over inhoud, SEO en de lancering#
Het gebied waar projecten het vaakst vertragen en waar aannames het vaakst uiteenlopen.
- Wie schrijft de teksten? Dit is de belangrijkste vraag in het hele gesprek en wordt het vaakst overgeslagen.
- Wie levert de foto's, en zijn stockfoto's inbegrepen?
- Wie voert de inhoud in het systeem in? Bij tweehonderd pagina's is dat serieus werk.
- Wat doe je met de bestaande URL's? Het antwoord moet omleidingen bevatten. Bevat het dat niet, is dat een probleem.
- Wat is inbegrepen op SEO-gebied? Technisch werk hoort erbij; contentstrategie is apart.
- Hoe test je vóór de lancering? Er hoort een testomgeving en een lijst te zijn.
- Wat gebeurt er op de lanceringsdag, en wie is bereikbaar?
- Krijg ik training of documentatie?
Over de periode na oplevering#
De vragen die bepalen of je over twee jaar tevreden bent, en die tijdens de verkoop het minst worden gesteld.
| Vraag | Waarom hij telt |
|---|---|
| Wat kost onderhoud per maand? | Voorkomt een verrassing kort na de lancering |
| Wat zit er in onderhoud? | «Onderhoud» zonder opsomming betekent weinig |
| Hoe snel reageer je bij storing? | Zet de verwachting nu, niet tijdens de storing |
| Wat als ik met iemand anders verder wil? | Toets voor de overdracht |
| Van wie is de code en de hosting? | Vraag dit vóór ondertekening |
| Wat gebeurt er als jullie stoppen? | Belangrijker bij een freelancer of klein bureau |
| Wie heeft toegang tot mijn accounts? | Moet aan het eind terug naar jou |
Veelgestelde vragen
Welke vraag is het belangrijkst?
«Wie schrijft de teksten?» Inhoud vertraagt meer websiteprojecten dan enige technische factor, en beide partijen nemen te vaak aan dat de ander het doet. Is het antwoord «jullie», vraag dan wanneer het aangeleverd moet zijn en wat er gebeurt als dat later wordt — en zorg dat dat in het contract staat.
Moet ik technische vragen stellen als ik het antwoord niet kan beoordelen?
Ja, maar beoordeel de uitleg in plaats van de inhoud. Iemand die zijn keuze in gewone taal kan uitleggen en de nadelen ervan benoemt, begrijpt wat hij doet. Iemand die achter jargon schuilt of nooit een nadeel noemt, is het risico. Dat onderscheid kun je zonder technische kennis maken.
Is het redelijk om referenties te vragen?
Volstrekt, en bel er werkelijk één. Vraag niet of ze tevreden waren maar wat er misging en hoe het werd opgelost, en hoe de samenwerking na de lancering verliep. Dat laatste is de meest voorspellende vraag en de minst gestelde — vóór de lancering is iedereen bereikbaar.
Wat als een leverancier deze vragen vervelend vindt?
Dat is zelf het antwoord. Dit zijn normale vragen van een klant die een substantieel bedrag uitgeeft, en professionals verwachten ze. Irritatie bij redelijke vragen vóór de handtekening voorspelt hoe het gaat wanneer je een probleem meldt na de lancering.
vragen webontwikkelaarwebbureau selecterenwebsite offerte vragendeveloper beoordelenwebsite project startenleverancier kiezen
