Webapplicatie laten maken kosten: wat bepaalt de prijs

Een maatwerk webapplicatie in Nederland kost doorgaans €15.000 tot €80.000 voor een MVP en loopt op tot €150.000 tot €500.000 of meer voor een volwaardig platform, afhankelijk van scope en complexiteit. Een ondernemer die vandaag een offerte van €42.000 ontvangt, vraagt zich dan ook terecht af waarom een concurrent beweert hetzelfde voor €5.000 te kunnen bouwen.

Dat verschil zit meestal niet in een uitzonderlijk hoge winstmarge. Het zit in het aantal gebruikersrollen, de hoeveelheid maatwerk, externe koppelingen, beveiliging, testwerk, infrastructuur en de tijd die nodig is om een betrouwbare applicatie op te leveren. Een lage offerte kan legitiem zijn, maar alleen als de scope werkelijk smal is.

Een offerte van €42.000 voelt hoog als een andere ontwikkelaar €5.000 noemt. Toch vergelijken die bedragen vaak geen gelijkwaardige projecten. De ene offerte beschrijft mogelijk een eenvoudige interne tool met één workflow. De andere bevat authenticatie, autorisaties, rapportages, koppelingen, foutafhandeling, monitoring en ruimte voor verdere groei.

Voor Nederlandse maatwerk-webapplicaties ligt de gebruikelijke bandbreedte volgens marktindicaties voor webapplicaties in Nederland rond €15.000 tot €80.000. Een eenvoudige MVP valt vaak rond €25.000 tot €60.000, terwijl complexe trajecten met meerdere rollen, workflows en integraties kunnen oplopen tot €150.000 tot €500.000 of meer. Een algemene indicatie voor maatwerksoftware ligt volgens Nederlandse projectramingen voor softwareontwikkeling rond €20.000 tot €100.000 of meer.

Een offerte onder €10.000 verdient extra controle. Zo'n bedrag kan passend zijn voor een zeer gerichte tool, een eenvoudige koppeling of een applicatie die grotendeels op bestaande componenten steunt. Het wordt verdacht zodra dezelfde prijs ook een klantportaal, betaalfunctionaliteit, meerdere rollen en een schaalbare architectuur moet omvatten.

Praktische regel: vraag niet alleen wat een webapplicatie kost, maar vooral wat er precies in de scope zit en welke onderdelen buiten de offerte vallen.

Ook bij andere digitale diensten is het verstandig om prijzen en voorwaarden naast elkaar te leggen. Wie bijvoorbeeld zoekt naar betaalbare bellen via 1808, ziet hetzelfde principe: een prijs krijgt pas betekenis wanneer duidelijk is welke dienst en voorwaarden erbij horen. Bij software geldt dat nog sterker, omdat ontbrekende technische werkzaamheden later als meerwerk terugkomen.

De prijsstructuur bepaalt hoe risico en verantwoordelijkheid tussen opdrachtgever en ontwikkelpartner worden verdeeld. Er bestaat geen universeel beste keuze. Het juiste model hangt af van de duidelijkheid van de scope en de fase waarin het project zich bevindt.

Bij een vaste prijs committeert een bureau zich aan een afgesproken bedrag voor een nauw omschreven scope. Dit model werkt goed voor een scherp gedefinieerde MVP waarvan de requirements stabiel zijn. De opdrachtgever krijgt budgetzekerheid, terwijl de ontwikkelaar het risico draagt dat het werk binnen de afgesproken scope meer inspanning vraagt.

Het model wordt riskant zodra gebruikersbehoeften nog onderzocht moeten worden. Een ontdekking tijdens de bouw leidt dan snel tot wijzigingsverzoeken, discussie over meerwerk of een te rigide product.

Een uurtarief past beter bij evolving requirements, technische verkenning of tijdelijke extra capaciteit. Nederlandse freelancers rekenen volgens indicatieve ontwikkelaarstarieven voor 2026 ongeveer €65 tot €130 per uur, terwijl bureaus vaak €85 tot €140 per uur hanteren. Een bredere Nederlandse marktindicatie noemt €85 tot €175 per uur, afhankelijk van senioriteit en specialisatie, zoals beschreven in de marktstudie naar maatwerksoftware in Nederland.

Een zzp-softwaredeveloper rekent volgens Knab's overzicht van zzp-softwaredeveloper tarieven in 2026 gemiddeld €94 per uur exclusief btw. Transparantie ontstaat alleen wanneer uren per onderdeel worden geraamd, geregistreerd en besproken.

Een retainer, of doorontwikkelmodel, koppelt een vast maandbedrag aan een team of een afgesproken hoeveelheid capaciteit. Dit past bij SaaS-producten en bedrijfsapplicaties die continu nieuwe functies, onderhoud en verbeteringen nodig hebben. De organisatie voorkomt telkens nieuwe aanbestedingen en houdt technische kennis binnen het team.

In Nederland komt ook een hybride model steeds vaker voor. Discovery en een eerste afgebakende module krijgen bijvoorbeeld een vaste prijs, terwijl verdere ontwikkeling op uurbasis of via een retainer verloopt. Dat combineert budgetcontrole met ruimte voor leren.

Een webapplicatie wordt niet duur door één spectaculaire functie. De kosten groeien door de combinatie van scope, ontwerp, techniek, team en kwaliteitsniveau. Vooral onderdelen die gebruikers niet direct zien, zoals logging, foutafhandeling en regressietests, bepalen hoeveel ontwikkelwerk nodig is.

Een scope bestaat uit userstories, schermen, datamodellen, rechten en workflows. Een extra scherm kost niet simpelweg een evenredig deel van het budget, omdat het ook wijzigingen kan veroorzaken in navigatie, API's, database-structuur, tests en autorisaties.

Een interne tool met één kernproces blijft overzichtelijk. Zodra klanten, medewerkers en beheerders elk eigen schermen en rechten krijgen, stijgt de complexiteit snel. De kosten van een eenvoudige interne tool beginnen volgens Nederlandse marktinformatie over webapplicatieontwikkeling rond €8.000 tot €10.000, terwijl een platform met rollen, workflows en koppelingen al snel €30.000 of meer kost.

Een standaard design-system met bewezen componenten beperkt ontwerpwerk en versnelt de bouw. Een volledig maatwerkontwerp vraagt meer keuzes, validatie en afstemming. Dat verschil is vooral relevant bij klantgerichte producten, waar onboarding, responsive gedrag en interactieontwerp direct invloed hebben op gebruiksgemak.

Voor een interne applicatie is een functionele interface vaak verstandiger dan pixel-perfect maatwerk. Het budget hoort daar naar foutloze workflows en duidelijke gegevensweergave te gaan.

Een koppeling met een betaalprovider, ERP of CRM omvat meer dan een API-aanroep. Developers moeten datamapping, foutafhandeling, monitoring, beveiliging, versiebeheer en regressietests regelen. Volgens informatie over kosten van maatwerk webapps en integraties schaalt integratiecomplexiteit daardoor niet lineair.

Een koppeling kan bovendien afhankelijk zijn van documentatie en beperkingen bij een derde partij. Een technisch eenvoudige integratie kan daardoor toch veel validatie en herstelwerk vereisen.

Managed cloud, observability en security-audits vormen structurele kosten naast de bouw. Hosting, logging, monitoring en beschikbaarheidsbewaking horen daarom al in het technisch ontwerp en de offerte thuis.

Onderhoud omvat updates, beveiligingscorrecties, wijzigingen in externe API's en kleine functionele verbeteringen. Een Nederlandse prijsopbouw voor maatwerk-webapplicaties laat zien dat discovery, design, development en testing afzonderlijk worden begroot, met projecttotalen van €50.000 tot €200.000. De echte total cost of ownership ligt daardoor vaak boven de eerste headline-prijs.

De beste manier om een project te plaatsen is niet vragen of het “klein” of “groot” is. Kijk naar het aantal processen, gebruikersgroepen, koppelingen en eisen aan beschikbaarheid.

Een MVP is geschikt wanneer één probleem eerst bewezen moet worden. De applicatie bevat dan alleen wat nodig is om de kernworkflow te testen. Een klantportaal met meerdere rollen, koppelingen en rapportages hoort eerder bij de middenklasse. Een SaaS-platform voor meerdere organisaties vraagt daarnaast om tenantisolatie, beheerfuncties, monitoring en een architectuur die groei aankan.

De grens tussen categorieën ligt in de praktijk bij afhankelijkheden. Een MVP dat zonder architectuuraanpassing moet uitgroeien tot een groter platform, verandert later in een verbouwproject. Dat kan duurder uitpakken dan vanaf het begin bewuste keuzes maken voor de middenklasse.

Een MVP moet klein zijn in functionaliteit, niet slordig in fundament.

Zodra de applicatie door meer dan één organisatie of door honderd gelijktijdige gebruikers gebruikt zal worden, bereikt het project volgens deze praktische vuistregel de volgende categorie. Dat betekent niet automatisch dat een enterprise-platform nodig is, wel dat schaalbaarheid, rechten, monitoring en performance niet meer als latere details kunnen worden behandeld. Een gefaseerde route blijft mogelijk. De eerste fase moet dan wel rekening houden met de richting waarin het product beweegt. Voor een concrete aanpak van een eerste versie helpt de gids over een MVP ontwikkelen.

Een betrouwbare raming begint niet met een lijst technologieën. Ze begint met het probleem dat de applicatie moet oplossen en de gebruikers die ermee werken.

Een discoveryfase van één tot twee weken brengt het probleem, de gebruikers en de kernflows in kaart. Het team beschrijft welke handelingen de applicatie ondersteunt, welke gegevens nodig zijn en waar beslissingen of uitzonderingen ontstaan.

Zonder discovery worden aannames tijdens de bouw ontdekt. Dan lijkt de scope eerst klein, maar ontstaan later extra schermen, rollen en integraties.

Een bruikbare raming verdeelt werk over frontend, backend, integraties en testen. Een totaalbedrag zonder onderliggende onderdelen maakt het onmogelijk om keuzes te maken. De opdrachtgever moet kunnen zien welk onderdeel vervalt als het budget lager uitvalt.

Een bandbreedte van min twintig tot plus dertig procent maakt onzekerheid zichtbaar. De raming wordt daardoor geen schijnzeker getal, maar een werkdocument dat meebeweegt met nieuwe informatie.

Elke raming rust op aannames. Denk aan performance, gebruikersaantallen, gegevenskwaliteit en de mogelijkheden van derde partijen. Een offerte moet expliciet maken wat gebeurt als een API niet alle benodigde data levert, als bestaande data vervuild is of als gebruikers andere rechten nodig hebben dan aanvankelijk beschreven.

Een risicobuffer van vijftien tot twintig procent bovenop de uren beschermt tegen ontdekkingen die pas tijdens de bouw zichtbaar worden. Die buffer is geen vrij besteedbaar budget. Het is een gereserveerde ruimte voor technische onzekerheid, wijzigingen in koppelingen en herstelwerk.

Een senior developer controleert de inschatting op onderschatte complexiteit. Vooral autorisaties, migratie, foutafhandeling en testen verdwijnen anders gemakkelijk uit beeld. Het resultaat is geen glazen bol, maar een onderbouwd document waarmee meerwerk herleidbaar blijft. Een bredere werkwijze staat in de uitleg over een webapplicatie laten bouwen.

AI verlaagt de kosten niet automatisch. Een LLM-integratie voegt volgens Nederlandse prijsindicaties al snel €8.000 tot €25.000 toe aan een eerste versie door API-kosten, prompt engineering, evaluatiesets en foutafhandeling, zoals uitgewerkt in de analyse van AI-featurekosten in producten.

AI loont wanneer de kernwaarde draait om samenvatten, classificeren of het interpreteren van ongestructureerde tekst. De applicatie moet dan ook een duidelijke fallback bieden wanneer de uitkomst onzeker is. Menselijke goedkeuring blijft in een eerste versie vaak de verstandigste veiligheidslaag.

Een formulier, beslisboom of eenvoudige zoekopdracht heeft geen AI nodig als vaste regels hetzelfde resultaat opleveren. Regels zijn in zo'n situatie goedkoper te testen, makkelijker uit te leggen en eenvoudiger te beheren.

Ook ontbrekende of inconsistente data maakt AI riskant. Zonder een bruikbaar labelproces en duidelijke beoordelingscriteria weet een team niet of de output betrouwbaar genoeg is. Dan wordt de AI-module een extra project binnen het project.

AI-regel: pas AI toe waar regels niet werken, niet waar AI alleen moderner klinkt.

De juiste volgorde is daarom meestal: eerst de workflow vereenvoudigen, daarna rule-based automatisering testen en pas vervolgens beoordelen waar taalmodellen waarde toevoegen. Zo verschuift AI naar een bewuste productkeuze in plaats van een onvoorspelbare kostenpost in versie één.

Besparen betekent niet automatisch minder bouwen. Het betekent vooral minder onzekerheid, minder dubbel werk en minder functies die nog niet bewezen waarde leveren.

• Prioriteer harde must-haves: leg vooraf vast wat noodzakelijk is en wat naar een latere fase kan. Een nieuw idee dat tijdens de bouw alsnog wordt toegevoegd, kost volgens projectramingen al snel €1.500 tot €5.000, zoals benoemd in de Nederlandse marktcontent over maatwerksoftware op OpenKlauw.
• Bouw eerst een stille MVP: laat de eerste versie intern gebruiken voordat externe klanten toegang krijgen. Fouten in de workflow worden dan ontdekt zonder dat een brede lancering meteen extra supportdruk veroorzaakt.
• Gebruik bewezen componenten: bestaande libraries, design-systemen en SaaS-diensten zijn vaak verstandiger dan volledig maatwerk. Maatwerk hoort alleen waar het bedrijfsproces zich echt onderscheidt.
• Ontwerp modulair: losse componenten en duidelijke API-grenzen maken latere uitbreidingen eenvoudiger. Een module die zelfstandig werkt, kan bovendien eerder worden opgeleverd.
• Test vóór de bouw: een design-sprint van één of twee weken kan onduidelijke flows vroeg blootleggen. Dat voorkomt rework nadat frontend en backend al op verkeerde aannames zijn gebaseerd.
• Kies vaste deelopleveringen: een vaste prijs voor afgebakende modules geeft meer controle dan een open retainer wanneer de scope nog niet stabiel is. Doorontwikkeling kan daarna flexibel worden ingericht.
• Automatiseer tests vanaf de eerste sprint: automatische tests vangen regressies op voordat ze na livegang bij gebruikers terechtkomen. Dat beschermt zowel de kwaliteit als het budget voor herstelwerk.
• Begroot beheer vooraf: hosting, monitoring, onderhoud en API-wijzigingen horen in dezelfde financiële planning als development. Een actuele Nederlandse prijsopbouw noemt onderhoud als structurele kostenpost, niet als optionele afterthought.

De fiscale context kan daarnaast relevant zijn voor organisaties die subsidiemogelijkheden onderzoeken. De officiële toelichting op een Nederlandse softwareontwikkelingsregeling vermeldt dat MKB-subsidie onder voorwaarden onder de de-minimisverordening kan vallen, zoals beschreven in de officiële regelingstoelichting. Controleer altijd de actuele voorwaarden voordat een subsidie als onderdeel van het budget wordt ingerekend.

Een eerste gesprek met een bureau of freelancer moet drie vragen beantwoorden:

1. Wat zit precies in de scope? Vraag om concrete userstories, schermen, rollen, integraties en testwerk.
2. Wat zit niet in de scope? Laat aannames over hosting, migratie, support, wijzigingen in API's en doorontwikkeling expliciet opschrijven.
3. Welk prijsmodel geldt? Een vaste prijs, uurtarief, retainer of hybride aanpak verdeelt risico's elk op een andere manier.

Een buffer van vijftien tot twintig procent blijft verstandig, ook wanneer de scope helder lijkt. Tijdens de bouw komen technische beperkingen, uitzonderingen in processen en nieuwe inzichten aan het licht. Een buffer voorkomt dat een klein probleem direct leidt tot stilstand of een nieuwe budgetronde.

Een gefaseerde oplevering spreidt het risico beter dan een big bang-release. Eerst komt de kernworkflow, daarna volgen koppelingen, rapportages en uitbreidingen. Na elke fase kan de opdrachtgever controleren of de investering nog aansluit bij de waarde voor gebruikers.

De beste budgetbeslissing is uiteindelijk niet de goedkoopste offerte. Het is de kleinste stap die het meeste oplevert voor de gebruiker. Bij elke nieuwe functie hoort daarom een simpele afweging: hoeveel tijd kost dit, welk probleem lost het op en kan een eenvoudiger alternatief hetzelfde resultaat geven?

MG Software bouwt maatwerk-webapplicaties, interne tools, klantportalen en API-koppelingen, met aandacht voor scope, fasering, onderhoud en technische risico's. Bespreek de eigen situatie en vraag een concrete indicatie aan via MG Software, zodat de eerste raming niet alleen een bedrag bevat, maar ook een verdedigbare route naar oplevering.