Webapplicatie ontwikkelen: keuzes die kosten bepalen

Twee offertes voor dezelfde webapplicatie kunnen een factor drie uit elkaar liggen. Dat verschil zit zelden in het uurtarief. Het zit in de technische keuzes die aan het begin gemaakt worden, vaak voordat er een regel code geschreven is. Wie een webapplicatie wil ontwikkelen zonder die keuzes te begrijpen, tekent in feite een blanco cheque. Dit artikel loopt de beslissingen langs die het grootste effect hebben op je budget en op de snelheid waarmee je live gaat.

Een veelgemaakte aanname is dat de zichtbare kant, de schermen en knoppen, het meeste werk kost. In de praktijk is dat vaak het goedkoopste deel. Het geld verdwijnt in wat de gebruiker niet ziet: het datamodel, de logica achter beslissingen, de omgang met randgevallen en de koppelingen met andere systemen. Een formulier bouwen is een middag werk. Bepalen wat er gebeurt als twee gebruikers tegelijk hetzelfde record wijzigen, dat is een week nadenken.

Als je een webapplicatie laat maken, vraag dan niet alleen naar het aantal schermen. Vraag naar het aantal entiteiten in het datamodel en naar het aantal externe systemen waarmee gekoppeld wordt. Die twee getallen voorspellen de kosten beter dan welke schets dan ook.

De eerste grote splitsing is of je functionaliteit uit een bestaand platform haalt of zelf bouwt. Een standaardoplossing is sneller live en goedkoper in aanschaf. Je betaalt die snelheid terug op het moment dat je iets nodig hebt dat het platform niet ondersteunt. Dan begin je te vechten tegen het systeem in plaats van ermee te werken.

Maatwerk draait dat om. De eerste weken voelen trager, omdat je fundering legt in plaats van een kant-en-klaar geraamte vult. Elke uitzondering die je bedrijf nodig heeft, past daarna wel gewoon. Wij bouwen maatwerk met Nuxt.js en Sanity: een moderne frontend gekoppeld aan een flexibele contentlaag. Die combinatie is snel te ontwikkelen en tegelijk volledig naar jouw processen te vormen.

De vuistregel: hoe unieker je processen, hoe eerder maatwerk zichzelf terugverdient. Een standaardwebshop hoort niet op maat gebouwd te worden. Een applicatie die een intern proces automatiseert dat nergens anders zo werkt, hoort dat wel.

Van alle keuzes bij het ontwikkelen van een webapplicatie heeft het datamodel de langste levensduur en de grootste gevolgen. Het is de structuur waarin je informatie opslaat en met elkaar in verband brengt. Een goed datamodel maakt nieuwe functies bijna gratis, omdat de gegevens er al logisch liggen. Een slecht datamodel maakt elke aanpassing tot een verbouwing.

Een concreet voorbeeld: stel je bouwt een reserveringssysteem en je slaat een boeking op als één datum. Later blijkt dat klanten meerdaagse boekingen willen. Wie het datamodel slim opzette met een begin- en einddatum, past niets aan. Wie een enkele datum koos, moet de hele opslag, alle queries en alle schermen herzien. Dezelfde functie, wekenlang verschil in kosten. Investeer daarom vroeg in het datamodel, ook al levert dat op dag één nog geen zichtbaar resultaat.

Elke koppeling met een extern systeem, een boekhoudpakket, een betaalprovider, een CRM of een voorraadsysteem, is een aparte miniproject. De complexiteit zit niet in de gelukkige gevallen. Die zit in wat er gebeurt als het andere systeem traag reageert, tijdelijk uitvalt of onverwachte data terugstuurt.

Vraag bij elke gewenste integratie of hij realtime moet zijn of dat een periodieke synchronisatie volstaat. Realtime koppelingen zijn aanzienlijk duurder om betrouwbaar te maken. Voor veel processen is een synchronisatie elk kwartier ruim voldoende, en dat scheelt fors in de rekening. Deze vraag stellen bespaart geld dat anders ongemerkt weglekt.

Zodra verschillende gebruikers verschillende dingen mogen zien en doen, groeit de complexiteit snel. Een applicatie waar iedereen alles mag, is simpel. Een applicatie met beheerders, medewerkers, klanten en gasten, elk met eigen rechten per onderdeel, vraagt een doordacht rechtensysteem dat door de hele applicatie heen loopt.

Bepaal vooraf hoeveel rollen je echt nodig hebt. Vaak blijken drie zorgvuldig gekozen rollen genoeg, terwijl een eerste wensenlijst er zeven noemt. Elke overbodige rol kost ontwikkeltijd en maakt testen ingewikkelder, omdat elke combinatie gecontroleerd moet worden.

De gekozen technologie bepaalt hoe snel je team kan werken en hoe makkelijk je later iemand vindt om verder te bouwen. Een moderne, breed gedragen stack betekent goede documentatie, kant-en-klare bouwstenen en een grote groep ontwikkelaars die ermee overweg kan. Een obscure of verouderde keuze betekent het tegenovergestelde: alles zelf uitzoeken en afhankelijk zijn van een kleine groep specialisten.

Wij werken met Nuxt.js voor de applicatiekant en Sanity voor de gegevens en content. Die keuze is bewust: het levert snelle laadtijden, het is prettig uit te breiden en het maakt de applicatie beheersbaar door meerdere mensen. Snelheid van ontwikkelen is geen toeval, het volgt uit de gereedschappen die je aan het begin kiest.

De goedkoopste manier om een webapplicatie te ontwikkelen is niet om zuinig te zijn op elk onderdeel. Het is om te beginnen met de kern die daadwerkelijk waarde levert en de rest uit te stellen. Veel functies die vooraf onmisbaar lijken, blijken na de lancering nauwelijks gebruikt te worden. Elke functie die je niet bouwt, is honderd procent bespaard.

Een eerste versie die één ding goed doet, levert eerder feedback op dan een complete versie die drie maanden later klaar is. Die feedback stuurt vervolgens waar je budget het beste heen kan. Zo bouw je wat mensen echt gebruiken, in plaats van wat op papier compleet leek.

De keuzes uit dit artikel zijn makkelijker te maken met iemand die er de gevolgen van kent. De duurste vergissingen in een webapplicatie ontstaan aan het begin, in het datamodel en de architectuur, en zijn later moeilijk terug te draaien. Een goed gesprek vooraf verdient zichzelf ruimschoots terug.

Speelt er bij jou een idee voor een webapplicatie, of twijfel je tussen een standaardplatform en maatwerk? Leg het aan ons voor. We denken met je mee over datamodel, integraties en de slimste volgorde van bouwen, zodat je weet waar je budget heen gaat voordat de eerste regel code geschreven is. Neem contact op met Reinspire en we kijken samen naar de concrete situatie.

Bekijk hoe Reinspire websites bouwt