Het eerste gesprek met een webdeveloper of bureau bepaalt meer dan je denkt. Kom je met een vaag "we willen iets moois" binnen, dan krijg je een vage offerte terug, met een prijs die nergens op gebaseerd is. Kom je goed voorbereid binnen, dan krijg je een scherpe inschatting van tijd en kosten, en een project dat vanaf dag één de juiste richting op gaat.
Je hoeft geen technisch document te schrijven. Een half uurtje nadenken over de onderstaande punten is al genoeg.
Waarom voorbereiding zo veel uitmaakt
Elke onduidelijkheid die je nu niet wegneemt, kom je later tegen. Vaak op het duurste moment: halverwege de bouw, als aanpassingen meer tijd (en dus geld) kosten dan wanneer je er vooraf over had nagedacht.
Een vage briefing werkt in twee richtingen tegen je. Een developer die niet precies weet wat er gebouwd moet worden, rekent een buffer in voor alles wat nog onduidelijk is: hoe minder er vastligt, hoe groter het risico dat hij inschat, en hoe hoger de prijs die daaruit rolt. En zelfs met die buffer loop je nog de kans dat je uiteindelijk iets anders krijgt dan je in gedachten had, simpelweg omdat niemand precies wist wat er bedoeld werd.
Concreet zie je een slechte voorbereiding terug in:
- Langere doorlooptijd. Elke aanname die achteraf niet blijkt te kloppen, betekent een nieuwe ronde overleg, aanpassen en opnieuw bouwen.
- Hogere kosten. Wijzigingen die je vooraf had kunnen noemen, kosten ná de start van de bouw al snel het dubbele of meer.
- Meer reviewrondes. Hoe vager de briefing, hoe meer heen-en-weer nodig is voordat het ontwerp echt aansluit bij wat je voor ogen had.
- Een offerte die niet klopt. Zonder duidelijke scope schat een developer breed in: te hoog uit voorzichtigheid, of te laag en later alsnog naar boven bijgesteld.
Een half uur voorbereiding voorkomt dus niet alleen een ongemakkelijk gesprek, het bespaart in de praktijk vaak weken aan doorlooptijd en een aanzienlijk deel van het budget.
Een developer kan geen goede prijs geven op "we willen een website die goed converteert". Wel op "we willen een website waar bezoekers een offerte kunnen aanvragen, met een koppeling naar ons CRM".
Wat je op orde moet hebben
Het doel
Waarom wil je dit project, en wat moet het opleveren? Meer aanvragen, minder telefoontjes, een professionelere uitstraling, tijd besparen op administratie? Een concreet doel stuurt elke keuze die de developer later maakt.
De doelgroep
Wie gebruikt de website of applicatie? Consumenten, zakelijke klanten, je eigen medewerkers? Dat bepaalt toon, structuur en functionaliteit.
Voorbeelden
Verzamel twee of drie websites die je aanspreken, en benoem waarom: de uitstraling, de structuur, een specifieke functie. Minstens zo waardevol: voorbeelden die je juist niet wilt. "Niet zo druk als deze site" zegt vaak meer dan een lange lijst wensen.
Content
Heb je al teksten, een logo, huisstijl en foto's? Of moet dat allemaal nog gemaakt worden? Dit is een van de meest onderschatte vertragers van een project: een prachtig ontworpen website die weken blijft liggen omdat de content nog niet af is.
Bestaande systemen
Gebruik je een boekhoudpakket, CRM, voorraadsysteem of planningstool waarmee gekoppeld moet worden? Noem ze bij naam. Of een koppeling mogelijk is, en wat die kost, hangt volledig af van welk systeem het is.
Budget
Lastig om te delen, maar juist heel nuttig. Een indicatie (ook een bandbreedte) helpt een developer om een voorstel te maken dat past, in plaats van te gokken en er compleet naast te zitten. Geen budget delen levert zelden een lagere prijs op, vaak juist een offerte die niet aansluit.
Deadline
Is er een harde datum (bijvoorbeeld een beurs, seizoen of contractovergang) of is de planning flexibel? Een harde deadline kan de aanpak en dus de prijs beïnvloeden.
Praktische dingen om mee te nemen
Als je een bestaande website vervangt of uitbreidt, is het handig om alvast te weten (of te achterhalen):
- Bij wie je domeinnaam is geregistreerd
- Waar de huidige website gehost wordt
- Of je bij de huidige inloggegevens en broncode kunt
Je hoeft dit niet uit te zoeken voor het gesprek, maar het scheelt tijd als je alvast weet waar je moet zoeken.
Wees niet bang om lastige vragen te stellen
Een goed gesprek gaat twee kanten op. Wil je weten hoe je een developer of bureau kritisch beoordeelt, inclusief een lijst met vragen die je altijd zou moeten stellen? Dat hebben we uitgewerkt in hoe kies je de juiste webdeveloper voor jouw bedrijf.
Wat je beter kunt vermijden
- Te vaag blijven. "Gewoon iets moois" is geen briefing. Concreet worden kost je vooraf tien minuten, en bespaart achteraf uren discussie.
- Wachten met content. Teksten en beeldmateriaal op het laatste moment aanleveren is de meest voorkomende reden dat projecten uitlopen.
- Budget verzwijgen uit angst. Dat levert zelden een lagere prijs op, wel vaker een voorstel dat niet aansluit bij wat je eigenlijk wilt.
- Alles dichttimmeren voor het gesprek. Voorbereiding helpt, maar een goede developer denkt ook mee. Kom met richting, niet met een compleet dichtgetimmerd plan waar geen ruimte meer in zit voor advies.
Kort samengevat
Een scherpe voorbereiding bestaat uit: je doel, je doelgroep, een paar voorbeelden, de status van je content, welke systemen gekoppeld moeten worden, een indicatie van budget en een reëel beeld van je deadline. Meer is niet nodig. Met die basis loopt het eerste gesprek soepeler, is de offerte realistischer en begint het project meteen op de juiste voet.
Klaar voor dat gesprek? Plan een vrijblijvend adviesgesprek en we denken meteen met je mee.