Je vraagt drie ontwikkelaars een offerte voor hetzelfde project. De ene komt uit op €9.000, de andere op €31.000 en de derde stuurt een lijst met vragen terug voordat hij ook maar een getal noemt. Dat prijsverschil is zelden een kwestie van hebzucht of incompetentie. Bijna altijd zit het probleem in wat jij hebt aangeleverd: een beschrijving die voor jou glashelder is, maar voor een developer vol gaten zit. Wie de gaten opvult, bepaalt mee wat er gebouwd wordt en wat het kost. Een goede technische briefing voorkomt dat iemand anders die keuzes voor jou maakt.
Een technische briefing is het contract vóór het contract
De meeste problemen bij maatwerkontwikkeling ontstaan niet tijdens het bouwen, maar vóór de eerste regel code. Een vage opdrachtomschrijving leidt tot aannames, aannames leiden tot discussies, en discussies kosten geld, fouten die je beter van meet af aan goed doet. Een technische briefing voor maatwerkontwikkeling lost dit op door iedereen op hetzelfde startpunt te zetten: jij als opdrachtgever, de ontwikkelaar als uitvoerende partij, en eventuele externe systemen die een rol spelen.
Wij van Ondernemerstips.be zien bij ondernemers regelmatig hetzelfde patroon: een enthousiast gesprek, een offerte op hoofdlijnen, en dan stilte tot het moment dat de rekening hoger uitvalt dan verwacht. De oplossing is niet meer vertrouwen, maar meer helderheid aan het begin. Hieronder vind je een concreet stappenplan om je briefing op te bouwen.
Stap 1: Begin met het probleem, niet de oplossing
De eerste alinea van je briefing beschrijft het probleem dat je oplost, niet de tool die je wil bouwen. Schrijf in één alinea wie er nu last heeft van welk probleem, en waarom bestaande software tekortschiet. Een voorbeeld: ‘Onze klantenservicemedewerkers loggen dagelijks handmatig bestellingen over vanuit drie verschillende systemen, omdat onze webshop niet koppelt met ons ERP. Dit kost gemiddeld anderhalf uur per dag en leidt tot fouten bij circa 4% van de orders.’
Dit is precies de informatie die een goede ontwikkelaar nodig heeft om de juiste architectuurbeslissingen te nemen. Een tool die twintig medewerkers dagelijks gebruiken vraagt om een andere aanpak dan een dashboard dat de directeur één keer per week raadpleegt.
Stap 2: Schrijf gebruikersstromen als korte scenario’s
In plaats van te omschrijven hoe een functie ‘moet werken’, beschrijf je wat een gebruiker stap voor stap doet. Zo’n scenario ziet er als volgt uit: ‘Klant logt in met e-mailadres en wachtwoord, ziet een overzicht van openstaande bestellingen, klikt op een bestelling, ziet de details inclusief track-and-trace, en kan vanuit dit scherm een retour aanvragen.’
Eén pagina met dit soort scenario’s vervangt tien pagina’s vage beschrijving. Het geeft de ontwikkelaar direct inzicht in het verwachte gedrag van het systeem en maakt het makkelijker om de scope te bewaken.
Stap 3: Maak een schermlijst met functionele bullets
Zet elk scherm of elke view van je applicatie op papier, samen met drie tot vijf bullets over wat de gebruiker daar kan doen. Vermijd technische termen en houd je bij de gebruikersacties. Voor een inlogpagina zou dat er zo uitzien:
- Gebruiker voert e-mailadres en wachtwoord in
- Gebruiker kan wachtwoord resetten via een link
- Na drie mislukte pogingen wordt het account tijdelijk geblokkeerd
- Er is een optie om ingelogd te blijven op dit apparaat
Je bepaalt hier niet hoe het er technisch uitziet, dat is aan de ontwikkelaar. Jij beschrijft wat het moet doen. Dit onderscheid is cruciaal.
Stap 4: Splits functionaliteiten in drie lagen
Niet alles hoeft op dag één live te gaan. Door functies te prioriteren voorkom je dat je budget opgaat aan features die voor de lancering weinig waarde toevoegen. Gebruik drie categorieën:
- Moet er absoluut in bij livegang (zónder dit werkt het product niet)
- Mag later worden toegevoegd in een volgende sprint of versie
- Nice-to-have, alleen als er tijd en budget over is
Voeg bij elke keuze één zin toe die de beslissing onderbouwt. Bijvoorbeeld: ‘Exportfunctie naar Excel mag later, want onze medewerkers gebruiken dit maximaal één keer per maand.’ Die ene zin voorkomt eindeloze discussies over prioriteiten.
Stap 5: Beschrijf integraties als input-outputtabel
Als je nieuwe tool moet communiceren met andere systemen, zoals een boekhoudpakket, een webshop of een CRM, dan is een overzicht van die koppelingen onmisbaar. Een tabel werkt hier goed:
| Systeem | Levert data aan | Formaat | Frequentie | Wat doet jouw tool daarmee |
|---|---|---|---|---|
| WooCommerce | Nieuwe bestellingen | Webhook (JSON) | Real-time | Opslaan in eigen database, tonen in dashboard |
| Exact Online | Factuurstatus | REST API | Elk uur | Koppelen aan klantprofiel |
Weet je het antwoord op een kolom niet zeker? Noteer dan de openstaande vraag. ‘Formaat onbekend, moet nog worden nagevraagd bij leverancier’ is waardevoller dan een blinde aanname die later een herprogrammering vereist.
Stap 6: Meetbare schaalbaarheids- en beveiligingsverwachtingen
Vage termen als ‘moet schaalbaar zijn’ of ‘veiligheid is belangrijk’ helpen een ontwikkelaar niet verder. Vertaal dit naar concrete getallen en eisen. Hoeveel gebruikers verwacht je bij de lancering en over twee jaar? Gaat het om gevoelige persoonsgegevens die onder de AVG vallen? Gelden er branchespecifieke normen, zoals ISO-certificering of sectorale beveiligingseisen?
Een concrete formulering klinkt dan zo: ‘Bij lancering verwachten we 50 actieve gebruikers, over 18 maanden mogelijk 500. We verwerken persoonsgegevens van klanten en zijn AVG-plichtig. Twee-factor-authenticatie is verplicht.’ Dit soort specificaties bepaalt mede de architectuur en dus de prijs.
Stap 7: Beantwoord de zeven standaardvragen van elke serieuze ontwikkelaar
Een goede ontwikkelaar stelt bij elke nieuwe opdracht dezelfde vragen. Als je die al beantwoord hebt in je briefing, bespaar je twee rondes heen-en-weermailen en geef je direct een professionele indruk. Dit zijn de zeven vragen die je zeker moet adresseren:
- Wie is eigenaar van de broncode na oplevering?
- Waar moet de applicatie gehost worden (eigen server, cloud, specifieke provider)?
- Welke bestaande systemen moeten blijven bestaan of worden vervangen?
- Is er een testomgeving nodig naast de productieomgeving?
- Wat zijn de acceptatiecriteria: hoe weet je dat het ‘klaar’ is?
- Wat is de beoogde doorlooptijd of uiterste opleverdatum?
- Wat is de budgetbandbreedte?
Over dat laatste punt: wees eerlijk. Je hoeft geen exact bedrag te noemen, maar ’tussen €15.000 en €25.000′ is nuttige informatie. Dit helpt je investeringsplan opstellen dat aansluit bij je bedrijfsvisie. Een ontwikkelaar die weet dat je budget €10.000 is, gaat je geen architectuur voorstellen die €40.000 kost. Dat spaart jullie beiden tijd.
Stap 8: Sluit af met een expliciete out-of-scope lijst
Dit is de stap die de meeste briefings missen, en tegelijk de stap die de meeste discussies voorkomt. Benoem expliciet wat je bewust buiten scope laat. Voorbeelden: ‘Een mobiele app valt buiten scope voor deze versie’, ‘Automatische facturatie is geen onderdeel van deze opdracht’, ‘Meertaligheid is niet inbegrepen tenzij apart geoffreerd.’
Zodra een klant later vraagt om iets wat op deze lijst staat, is het antwoord helder: dat is een scopewijziging, geen onderdeel van de afspraak. Zo voorkom je dat ‘kleine aanpassingen’ de planning opblazen en de verhouding met je ontwikkelaar onder druk zetten.
Een technische briefing schrijf je niet nadat de offerte tegenvalt of nadat het eerste misverstand zich aandient. Je schrijft hem voordat je ook maar één gesprek aangaat met een ontwikkelaar. Wij van Ondernemerstips.be zien dat dit document het verschil maakt tussen een samenwerking die soepel loopt en één die verzandt in meerwerk en bijstellingen. Begin met het probleem dat je oplost, werk toe naar de technische details, en benoem expliciet wat buiten scope valt. Dat laatste wordt het vaakst vergeten, en het is precies wat ontwikkelaars later als meerwerk doorrekenen.
