Hoe brief je een maatwerk webapplicatie als standaardtools niet passen

Er komt een moment waarop de standaardsoftware het niet meer redt. Niet omdat je team te veeleisend is, maar omdat je situatie werkelijk afwijkt van wat de meeste tools voor ogen hebben. Je hebt specifieke gebruikersstromen, bijzondere integraties, eigen logica. Je hebt een maatwerk webapplicatie nodig.

Maar dan begint het echte werk: hoe brief je dat? Een webapplicatie op maat is geen website met extra functies, en ook geen SaaS-pakket dat je inricht. Het is software die je van de grond af bouwt. De brief die je schrijft, bepaalt voor een groot deel of het project slaagt of vastloopt.

Bij Livewall hebben we tientallen van deze trajecten doorlopen, van interne systemen voor grote organisaties tot publieke platforms die dagelijks duizenden gebruikers bedienen. Dit is wat we leren bij elke brief die we beoordelen.

Begin met het probleem, niet de oplossing

De meest voorkomende fout in briefs voor webapplicaties: ze beschrijven wat er gebouwd moet worden, niet waarom. Schermen worden gespecificeerd, flows uitgetekend, features opgesomd. Maar de vraag waarom dit systeem er moet komen, wordt overgeslagen.

Een bureau dat alleen de oplossing ziet, kan niet beoordelen of die oplossing de juiste is. En in een maatwerk traject is dat gevaarlijk. Als de aanname die aan de basis ligt niet klopt, bouw je de verkeerde applicatie. Netjes, op tijd, binnen budget, maar de verkeerde.

Schrijf dus eerst: wat is het concrete probleem dat dit systeem moet oplossen? Wie ervaart dat probleem, hoe vaak, en wat kost het ze nu? Wat is het gewenste resultaat over een jaar? Een goed bureau, zoals wij dat bij Livewall proberen te zijn, gebruikt dit om de oplossing te beoordelen, aan te scherpen of te vervangen door iets beters.

Beschrijf je gebruikers concreet

Webapplicaties hebben gebruikers. Soms zijn dat interne medewerkers, soms klanten, soms beide. De brief moet duidelijk maken wie die gebruikers zijn en wat ze van het systeem verwachten.

Niet op het niveau van persona-sheets met stock foto's, maar op het niveau van: hoeveel mensen gebruiken dit dagelijks, wat is hun technische vaardigheid, op welke apparaten zitten ze, in welke context gebruiken ze de applicatie? Een logistiek medewerker die een systeem gebruikt op een tablet in een magazijn heeft andere eisen dan een marketeer die dezelfde data bekijkt op een laptop op kantoor.

Voor Zorg van de Zaak bouwden we een B2B-platform waarbij de eindgebruikers zeer uiteenlopend waren: van HR-managers tot medewerkers zonder digitale achtergrond. Die bandbreedte had directe invloed op ontwerpkeuzes, technologie en de manier waarop we toegankelijkheid aanpakten. Dat wisten we omdat de brief het duidelijk maakte.

Voor Veilig Thuis gold iets vergelijkbaars: een kwetsbare doelgroep vraagt om andere ontwerpbeslissingen dan een commercieel platform. Als dat niet in de brief staat, moet het bureau het zelf invullen. Dat is een risico.

Wat moet de applicatie kunnen: functioneel versus technisch

Hier gaan de meeste briefs de mist in. Ze beschrijven ofwel te functioneel (een lijst van features zonder context) ofwel te technisch (een stack-specificatie zonder productvisie). Beide zijn nutteloos voor een bureau dat goed werk wil leveren.

Wat werkt: functionele vereisten beschrijven vanuit gebruikersgedrag. Niet "er moet een dashboard zijn", maar "een beheerder moet in één oogopslag zien hoeveel gebruikers actief zijn, welke content de meeste interactie genereert en welke meldingen openstaand zijn". Dat geeft richting zonder de ontwerpvrijheid weg te nemen.

Technische eisen zijn wél relevant als ze harde randvoorwaarden zijn: een verplichte koppeling met een bestaand systeem, een beveiligingsstandaard die de organisatie hanteert, een hosting-omgeving die niet onderhandelbaar is. Dat zijn constraints die een bureau moet kennen voor ze aan het werk gaan.

Wat je kunt weglaten: de exacte technologiestack (tenzij je daar sterke redenen voor hebt), de precieze schermindeling (dat is ontwerp, geen brief), en feature-lijstjes zonder prioritering. Een bureau dat weet wat het doet, vertaalt je functionele vereisten naar de beste technische keuzes. Dat is precies wat webapplicatieontwikkeling bij Livewall inhoudt.

Integraties: het onderschatte deel van de brief

Maatwerk webapplicaties staan zelden op zichzelf. Ze koppelen aan bestaande systemen: een CRM, een ERP, een betaalplatform, een identity provider, een datawarehouse. Die koppelingen zijn technisch complex en vaak tijdrovend. Als ze laat in het traject opduiken, kosten ze niet alleen tijd, ze hertekenen soms de hele architectuur.

Een goede brief beschrijft alle systemen waarmee de applicatie moet praten, inclusief wie de eigenaar is van die systemen en wat er bekend is over de beschikbare APIs. Weet je niet of er een API beschikbaar is? Schrijf dat dan op. Een eerlijk "we weten het niet" is waardevoller dan een aanname die later duur uitvalt.

Voor Lefboom, een duurzaamheidsbeloningsplatform, waren de integraties met externe partners een kritieke factor. Die hadden we vroeg in kaart. Dat maakte het verschil tussen een soepel traject en een heleboel brandjes blussen halverwege.

Voor Dumpert vroeg de streamingarchitectuur om specifieke technische keuzes die al in de early discovery duidelijk moesten zijn. Dat soort complexiteit overleeft een vage brief niet.

Scope, MVP en wat je bewust weglaat

Een van de meest waardevolle dingen die een brief kan bevatten: een expliciete lijst van wat je niet bouwt in de eerste versie. Dit klinkt contra-intuïtief, maar het is essentieel. Zonder die lijst wordt alles prioriteit. Dan loopt het project vast in scope-discussies halverwege, of wordt er opgeleverd wat niemand had bedoeld.

Wij werken bij Livewall met een prototype-first aanpak. Begin klein, valideer, groei. Een goede brief sluit daarbij aan: wat is het minimum dat je nodig hebt om te leren of het concept werkt? Welke aanname wil je als eerste valideren? Dat is de scope van je MVP.

De rest is een backlog, geen dag-1-vereiste. Rapid prototyping werkt alleen als de scope van de eerste versie verdedigbaar klein is. Dat vraagt om lef in de brief. Zeg expliciet wat je uitstelt, en waarom.

Dit geldt ook voor functionaliteit die "leuk zou zijn". Admin-panels, exportfuncties, uitgebreide rapportages: bijna altijd kunnen die later. Zet ze in een tweede fase. Een te volle eerste fase is een van de voornaamste oorzaken van vertraging in webapplicatieprojecten.

Budget, tijdlijn en hoe je eerlijk bent over beide

Veel briefs zwijgen over budget. Dat is begrijpelijk, maar het helpt niemand. Een bureau zonder budgetindicatie kan geen realistisch aanbod doen. Ze schenken je of een te optimistische offerte (die later uitloopt) of een te ruime inschatting (die onnodige kosten met zich meebrengt).

Je hoeft niet tot op de euro precies te zijn. Maar een bandbreedte geeft richting. "We denken aan 80.000 tot 120.000 euro voor de eerste versie" stelt een bureau in staat om eerlijk te zijn over wat daarbinnen haalbaar is, en wat niet.

Hetzelfde geldt voor tijdlijnen. Als er een harde deadline is, schrijf die op en leg uit waarom. Een live-datum die vastligt vanwege een beurs, een contractverplichting of een seizoenspatroon is relevant. Dat soort context helpt het bureau prioriteiten stellen.

Als je geen harde deadline hebt: dat is ook waardevolle informatie. Het geeft ruimte voor een fasering die de kwaliteit ten goede komt. Digitale strategie begint altijd met realisme over tijd en middelen.