Wie offertes opvraagt voor een webapplicatie, ziet bedragen die ver uiteenlopen. Dat verschil zit zelden in het uurtarief. Het zit in wat er ontwikkeld wordt: hoeveel schermen, hoeveel uitzonderingen op de regel, hoeveel maatwerk op plekken waar een bestaande bouwsteen had volstaan. En wie die offerte vervolgens naast het maandbedrag van een standaardpakket legt, vergelijkt een investering vooraf met een abonnement dat nooit ophoudt.
De prijs van maatwerk is daardoor minder grillig dan hij lijkt. Het grootste deel van je investering wordt bepaald door een paar keuzes die je maakt voordat de eerste regel code geschreven is. We lopen die keuzes langs, ruimen onderweg een paar hardnekkige misvattingen uit de weg en eindigen met hoe je een realistisch budget opstelt.
Schrap voordat je laat ontwikkelen
De grootste kostenpost van een webapplicatie is functionaliteit die er niet in had gehoeven. Elke extra pagina, elk extra veld en elke uitzondering op de regel moet ontworpen, ontwikkeld, getest en daarna jarenlang onderhouden worden. De goedkoopste functie is dan ook de functie die je niet laat maken.
Maak daarom vooraf onderscheid tussen wat het systeem moet kunnen en wat handig zou zijn. Een scherpe scope is geen beperking maar een besparing: alles wat naar een latere versie kan, hoeft nu niet betaald te worden. Na een paar maanden gebruik weet je team bovendien veel beter welke wensen op die lijst nog overeind staan.
Maatwerk betekent niet dat alles opnieuw gemaakt wordt
Een hardnekkige misvatting is dat bij maatwerk elke functie vanaf nul wordt ontwikkeld, tegen de volle prijs. Inloggen, rechtenbeheer, betalingen, facturen als pdf: daarvoor bestaan beproefde frameworks en kant-en-klare componenten. Een ervaren ontwikkelpartner bouwt daarop voort in plaats van het wiel opnieuw uit te vinden. Dat scheelt ontwikkeltijd, testwerk en onderhoud.
Maatwerk is het waard op de plekken waar je proces afwijkt van de rest van de markt, want daar zit je voorsprong. Daar heeft elke functie een duidelijke reden om te bestaan: een stap die tijd kost, een plek waar fouten ontstaan, een inzicht dat ontbreekt. Vraag een bureau dus niet alleen wat het ontwikkelt, maar ook wat het hergebruikt.
Standaardsoftware lijkt goedkoper, tot je alles meetelt
De bekendste misvatting is dat maatwerk per definitie duurder is dan een standaardpakket. Het maandbedrag is echter niet de hele rekening. Licenties lopen door zolang je het pakket gebruikt, extra gebruikers en premiumfuncties kosten bij, en zodra het pakket net niet aansluit op je proces, betaalt je team het verschil in werktijd. De grootste verborgen post zit vaak tussen de systemen in: gegevens die van het ene scherm naar het andere worden overgetypt, met fouten en dubbel werk als gevolg.
Vergelijk daarom nooit instapbedragen, maar de totale kosten over meerdere jaren, inclusief de uren die je team nu kwijt is aan omwegen. Soms is de uitkomst dan niet eens een nieuwe applicatie, maar een goede koppeling tussen de systemen die je al hebt; dat is het terrein van data-integraties. Wanneer een standaardpakket wel de betere keuze is, en waaraan je herkent dat je proces er niet in past, lees je in wanneer een maatwerkwebapplicatie wint van SaaS.
Ontwikkel in fasen en breid uit op bewijs
Projecten die twee keer zo duur uitvielen bestaan, en die verhalen reizen ver. Kijk je naar de oorzaken, dan zie je bijna altijd hetzelfde patroon: er werd vooraf te veel tegelijk vastgelegd, en pas tijdens het ontwikkelen bleek wat er werkelijk nodig was.
Dat patroon is te doorbreken. Een webapplicatie hoeft niet in één keer af te zijn. Begin met een eerste versie die het kernproces goed ondersteunt, neem die in gebruik en kijk wat er gebeurt. Gebruikers wijzen feilloos aan welke uitbreiding waarde toevoegt en welke alleen op papier aantrekkelijk leek. Hoe je die eerste versie afbakent, beschreven we in de verschillen tussen een MVP en volledig uitgewerkte software.
Gefaseerd ontwikkelen spreidt bovendien je investering. Je geeft pas geld uit aan uitbreidingen als de basis zich bewijst, en je kunt bijsturen zonder dat er maanden werk verloren gaat. Voor een budgethouder is dat misschien wel de belangrijkste besparing: niet minder betalen per onderdeel, maar nooit betalen voor iets waarvan de waarde niet is aangetoond. Vraag een ontwikkelpartner daarom niet alleen naar de prijs, maar ook hoe hij faseert en hoe hij omgaat met inzichten die onderweg ontstaan.
Reken de jaren na de livegang mee
De ontwikkelsom is niet het hele verhaal. Een webapplicatie draait daarna jaren, en in die jaren horen hosting, updates, beveiligingspatches en monitoring bij de investering. Wie daarop bezuinigt, betaalt dat later terug in storingen, noodreparaties en een systeem dat niemand meer durft aan te passen.
Kijk bij het vergelijken van offertes dus verder dan het bedrag voor de oplevering. Vraag door op drie punten:
- wat hosting en onderhoud per jaar kosten, en wat daarvoor gebeurt;
- wie er ingrijpt als er iets misgaat, en hoe snel;
- hoe de applicatie meegroeit als het aantal gebruikers toeneemt.
Een partij die hier helder op antwoordt, denkt na over de jaren waarin het systeem zijn geld moet opbrengen, precies de periode waarin een degelijk fundament zich terugverdient. Wat er in die jaren bij komt kijken, lees je bij doorontwikkeling en beheer.
Zo kom je tot een realistisch budget
Een goed budget begint niet bij offertes, maar bij je huidige kosten. Drie stappen brengen je ver:
- Breng in kaart wat je nu betaalt: licenties, de uren die opgaan aan handwerk en foutherstel, en de omwegen die je team dagelijks neemt. Dat is het bedrag waar je elke offerte tegen afzet.
- Scheid wat de applicatie vanaf de eerste dag moet kunnen van wat later mag komen. De eerste groep bepaalt je startbudget, de tweede je routekaart.
- Reserveer ruimte voor voortschrijdend inzicht. Tijdens het ontwikkelen leer je altijd iets over je eigen proces, en dat wil je kunnen verwerken zonder discussie over elke wijziging.
Met dat huiswerk wordt een offertegesprek een inhoudelijk gesprek in plaats van een prijsonderhandeling. Je weet wat de applicatie moet opleveren om de investering waard te zijn, en wat je bewust later laat komen.
We ontwikkelen webapplicaties voor organisaties die deze afweging serieus nemen, en dat gesprek voeren we het liefst voordat er iets gemaakt wordt. Lees hoe we webapplicaties en portalen ontwikkelen, of leg ons je wensenlijst voor. Grote kans dat we beginnen met de vraag wat eraf kan.