Een offerte van 15.000 euro voor een webapplicatie voelt voor de ene ondernemer als een koopje en voor de andere als een schok. Het verschil zit zelden in de applicatie zelf, maar in het begrip van wat er eigenlijk gebouwd wordt. Tarieven voor maatwerksoftware zijn niet willekeurig, maar ze zijn ook niet transparant genoeg om zonder uitleg te begrijpen. In dit artikel leg ik zo concreet mogelijk uit hoe een prijskaartje tot stand komt, waar de grote kostendrijvers zitten en wat je zelf kunt doen om een project betaalbaar te houden zonder in te leveren op kwaliteit.
Wat je eigenlijk koopt
Een webapplicatie is geen website. Een website toont informatie, een webapplicatie verwerkt iets. Denk aan een portaal waar klanten hun orders bijhouden, een tool waarmee je team planningen beheert, of een systeem dat automatisch facturen aanmaakt op basis van ingevulde gegevens. Achter elke knop zit logica, achter elke pagina zit een database, en achter elke verbinding met een extern systeem zit een API-koppeling die gebouwd en onderhouden moet worden.
Dat onderscheid is zakelijk relevant, want het verklaart waarom uurtarieven voor webapplicaties hoger liggen dan voor standaard webdesign. Het werk vraagt andere kennis: databaseontwerp, beveiligingslagen, rolgebaseerde toegang, prestatiebeheer bij schaal. Een senior developer rekent in Nederland doorgaans tussen de 85 en 130 euro per uur. Een project van 100 uur zit dan al snel boven de 10.000 euro, nog voordat design, testen en projectmanagement zijn meegeteld.
Wat je concreet betaalt is grotendeels afhankelijk van de doorlooptijd. Een doorlooptijd wordt bepaald door de hoeveelheid functionaliteit die je wilt, de integraties die nodig zijn, en hoeveel het ontwerp afwijkt van standaard patronen. Hoe meer maatwerk in het ontwerp, hoe meer ontwerptijd. Hoe meer koppelingen met externe diensten, hoe meer onzekerheid in de planning.
Waar de kosten echt vandaan komen
Het fundament van elke webapplicatie is de technische architectuur. Voordat er ook maar één scherm gebouwd wordt, moet er nagedacht worden over hoe data opgeslagen wordt, hoe de applicatie schaalt als het druk wordt, en hoe je later features toevoegt zonder alles opnieuw te schrijven. Die denkarbeid kost tijd, maar betaalt zich terug in een systeem dat over vijf jaar nog aanpasbaar is.
Authenticatie en autorisatie zijn een ander onderdeel dat onderschat wordt. Wie mag wat zien? Wie mag wat doen? Moeten er rollen zijn, zoals beheerder, medewerker en klant? Mogen bepaalde gebruikers alleen hun eigen data inzien? Dit soort toegangslogica is functioneel eenvoudig te beschrijven, maar technisch arbeidsintensief om goed te implementeren. Een fout hierin is niet alleen een bug, maar een beveiligingsrisico.
Koppelen met externe systemen trekt ook flink aan het budget. Denk aan een koppeling met een boekhoudpakket, een betaalprovider, een CRM of een planning-API. Externe API's zijn soms goed gedocumenteerd, soms niet. Ze veranderen, gaan offline, of geven onverwachte foutmeldingen terug. Dat alles moet worden opgevangen in de code, en het opvangen van randgevallen kost meer tijd dan het bouwen van het happy path. Reken per serieuze koppeling al gauw op twee tot vijf extra dagen werk.
Het verschil tussen een strakke en een vage opdracht
Hoe duidelijker jij als opdrachtgever omschrijft wat je nodig hebt, hoe nauwkeuriger de offerte. Dat klinkt logisch, maar de praktijk is dat de meeste opdrachten beginnen met een idee en eindigen met een functionele omschrijving die gaandeweg wordt aangescherpt. Dat aanscherpen kost tijd, en die tijd staat ergens in de begroting.
Werk je met een vaste prijs, dan zit de onzekerheid verdisconteerd in het tarief. Een vaste prijs geeft jou budgetzekerheid, maar bevat altijd een buffer voor het onbekende. Werk je op uurbasis, dan betaal je voor de werkelijke uren, maar heb je minder grip op de eindfactuur als de scope verandert. Ik ga dieper op dit onderscheid in in mijn artikel over vaste prijs of uurtarief, maar de korte versie is dit: een goede functionele beschrijving is altijd het fundament, ongeacht het contractmodel.
Schrijf je wensen op in termen van wat het systeem moet doen, niet hoe het dat technisch moet bereiken. "Een gebruiker moet een factuur kunnen downloaden als PDF" is een goede functionele beschrijving. "Gebruik Laravel met een PDF-library en sla het op in S3" is technisch voorschrijven, en dat is mijn vakgebied, niet het jouwe. Hoe meer je het wat beschrijft en het hoe aan mij overlaat, hoe beter de samenwerking verloopt en hoe realistischer de schatting wordt.
Terugkerende kosten die je moet meebegroten
De bouwfactuur is één ding, maar een webapplicatie heeft daarna ook onderhoud nodig. Servers moeten draaien, software-updates moeten worden doorgevoerd, beveiligingslekken in onderliggende pakketten moeten worden gedicht. Reken op een maandelijks hostingbedrag van minimaal 30 tot 150 euro, afhankelijk van de belasting en de infrastructuur. Voor applicaties die veel dataverkeer verwerken of strenge uptime-eisen hebben, ligt dat hoger.
Naast hosting is er ook functioneel onderhoud. Jouw bedrijf verandert, wetgeving verandert, gebruikers vragen nieuwe features aan. Een applicatie die na oplevering nooit meer aangeraakt wordt, is over twee jaar verouderd. Bouw dat in je businesscase in. Een retainer van vier tot acht uur per maand is voor de meeste MKB-applicaties een redelijke onderhoudspost.
Vergeet ook niet de doorlooptijd als zakelijk kostenpost. Een project dat acht maanden duurt terwijl het in vier maanden had gekund, kost jou verloren omzet of productiviteit. Doorlooptijd hangt af van de complexiteit van het project, maar ook van hoe snel jij als opdrachtgever feedback geeft, beslissingen neemt en testomgevingen keurt. Een trage beslisser is in mijn ervaring net zo vaak de bottleneck als een trage developer.
Hoe je een realistisch budget bepaalt
Begin niet met een getal, begin met een probleemomschrijving. Wat kost het probleem je nu, in tijd, geld of fouten? Een team dat dagelijks twee uur kwijt is aan handmatige handelingen die een applicatie automatisch kan afhandelen, loopt bij tien medewerkers op 20 uur per dag. Dat is tienduizenden euro's per jaar aan verloren capaciteit. Een applicatie van 25.000 euro betaalt zichzelf dan in zes maanden terug.
Stel vervolgens een prioriteitenlijst op van functies. Welke functie is absoluut noodzakelijk op dag één? Welke kan na twee maanden? Welke is handig maar geen blocker? Die opdeling maakt het mogelijk om een eerste versie te bouwen die snel in productie gaat, en daarna iteratief uit te breiden. Een gefaseerde aanpak verlaagt het initiële risico, geeft eerder terugkoppeling uit de praktijk en spreidt de investering.
Haal meerdere offertes op, maar vergelijk ze niet alleen op prijs. Vergelijk ook wat er in de scope zit, hoe de developer communiceert, of er een testfase is meegenomen, en of je eigenaar wordt van de broncode. Dat laatste klinkt vanzelfsprekend, maar is het niet altijd. Vraag expliciet of de code en alle bijbehorende rechten aan jou worden overgedragen bij oplevering.
Wat ik zelf altijd meeneem in een offerte is een technische risicoanalyse. Welke onderdelen zijn onzeker? Welke koppelingen zijn afhankelijk van een derde partij die zich anders kan gedragen dan verwacht? Transparantie over onzekerheid is geen zwakte in een offerte, het is een teken dat iemand nagedacht heeft over jouw project in plaats van een standaard template ingevuld.
Een webapplicatie bouwen is een investering, geen uitgave. Het verschil zit in het perspectief: een uitgave is voorbij als de factuur betaald is, een investering werkt door in de manier waarop jouw bedrijf opereert. Als de businesscase klopt, de scope helder is en de developer weet wat hij doet, dan is een goed gebouwde webapplicatie een van de meest rendabele keuzes die je als ondernemer kunt maken.
Als je wilt weten wat een webapplicatie voor jouw specifieke situatie zou kosten, vind je meer over hoe ik dit soort projecten aanpak op https://pimvdmolen.nl/diensten/webapplicaties. Wil je direct een gesprek inplannen of een eerste omschrijving doorsturen, dan kun je terecht op https://pimvdmolen.nl/contact.