Workflows23 sep 202613 min leestijd
Software ontwikkelen kosten: een realistische prijsindicatie
Ontdek wat software ontwikkelen kosten echt beïnvloedt. Van uurtarieven tot projectcomplexiteit: een helder overzicht voor een maatwerkapplicatie.
Co-founder

Introductie
Een eenvoudige interne tool kost in Nederland vaak €5.000–€15.000, een klantportaal meestal €25.000–€75.000 en een SaaS-platform €100.000–€250.000 of meer. De bouwprijs vertegenwoordigt bovendien vaak slechts 30–50% van de totale kosten over vijf jaar, omdat onderhoud, hosting en doorontwikkeling na de oplevering doorgaan.
Dat is de ongemakkelijke waarheid achter software ontwikkelen kosten. Een offerte van €40.000 lijkt overzichtelijk, maar zegt weinig als niemand vermeldt wat de applicatie daarna jaarlijks kost. Nederlandse marktbronnen noemen voor onderhoud vaak 10–20% van de bouwkosten per jaar en voor hosting of infrastructuur ongeveer €100–€500 per maand (MG Software).
Waarom een offerte zelden het echte verhaal vertelt
De bouwsom is vaak slechts 30–50% van de totale lifecycle-kosten over vijf jaar. Een offerte stopt meestal bij de oplevering, terwijl hosting, beveiligingsupdates, support en verbeteringen daarna doorlopen. Wie alleen de initiële offerte vergelijkt, vergelijkt een zichtbaar bedrag met een onvolledig beeld van de werkelijke investering.
Dat verschil verklaart waarom een goedkope aanbieder later duur kan uitvallen. Aannames over support, integraties en wijzigingen moeten daarom schriftelijk in de offerte staan. Zonder die afspraken blijft een lage prijs vooral een beperkte momentopname.

Drie herkenbare prijsniveaus
Een eenvoudige automatisering of interne tool begint vaak rond €5.000–€15.000. Een klantportaal of bedrijfsapplicatie ligt doorgaans tussen €25.000 en €75.000. Grotere platformen en SaaS-oplossingen lopen op tot €100.000–€250.000 of meer (software laten ontwikkelen).
Gebruik deze bandbreedtes als eerste oriëntatie, niet als budget. Een interne tool met formulieren vraagt een andere aanpak dan een applicatie met rollen, auditlogs en foutafhandeling. Ook maakt het verschil of een klantportaal één gegevensbron gebruikt of CRM, facturatie en planning moet verbinden.
Kosten die vaak buiten beeld blijven
Naast onderhoud en hosting kunnen SSL-certificaten, licenties van derden zoals Stripe of SendGrid, een stagingomgeving, monitoring en bugfixes in het eerste jaar extra kosten veroorzaken. Documentatie, deployment, back-ups en ondersteuning na een release staan evenmin automatisch in de bouwprijs.
Vraag daarom om voorwaarden voor de periode na livegang, niet alleen om een omschrijving van de bouw. De uitleg over een onduidelijke offerte voor ondernemers helpt bij het beoordelen van aannames, uitsluitingen en verantwoordelijkheden.
Praktische regel: vraag naast de bouwofferte altijd om een vijfjaarsraming. Zonder die berekening blijft het softwarebudget onvolledig.
De vier kostenfactoren van maatwerksoftware
De bouwsom is vaak slechts een derde tot de helft van de totale lifecycle-kosten. Software ontwikkelen kosten ontstaan uit uren, technologie, integraties en onderhoud. Wie alleen de initiële offerte vergelijkt, mist dus een groot deel van het budget.

Uren bepalen meer dan regels code
De urenraming wordt vooral bepaald door functionele complexiteit, overleg en iteraties. Een scherm met enkele velden kan extra werk vragen door validaties, gebruikersrechten, foutmeldingen en uitzonderingen. Een koppeling met een boekhoudpakket kost als vuistregel 40–80 extra uren wanneer synchronisatie, datamigratie en foutafhandeling nodig zijn.
Vraag om een raming per rol, niet om één totaalgetal. Analyse, UX, frontend, backend, DevOps en testen leveren ieder een eigen bijdrage. “Enkele honderden uren” zonder deze verdeling maakt het budget moeilijk controleerbaar.
Technologie verschuift de rekening
Low-code kan de bouw versnellen, maar daar staan licenties en afhankelijkheid van het platform tegenover. Maatwerkcode vraagt meer ontwerpbeslissingen en ontwikkeluren, maar geeft doorgaans meer controle over integraties, schaalbaarheid en eigendom.
Kies technologie op basis van de verwachte levensduur. Voor een tijdelijk intern proces kan low-code passend zijn. Een bedrijfskritisch platform vraagt een architectuur die het eigen team kan onderhouden, zonder blijvende afhankelijkheid van één leverancier.
Integraties vormen een aparte laag
Een API-koppeling vraagt ontwerp en beheer. Authenticatie, datamodellen, synchronisatie, time-outs, logging en foutscenario's moeten worden ingericht. Daarna volgen tests met externe systemen en aanpassingen wanneer een leverancier zijn API wijzigt.
Zet integraties daarom als afzonderlijke posten in de offerte. Zo zie je welke koppelingen het budget bepalen en welke risico's na livegang blijven bestaan.
Onderhoud hoort vanaf het begin in de begroting
Reserveer jaarlijks 15–20% van de bouwkosten voor onderhoud. Het benodigde bedrag hangt af van beveiligingseisen, integraties, releasefrequentie en het aantal gebruikers. Hosting, licenties, monitoring en ondersteuning komen daar mogelijk nog bij.
Een lage bouwprijs zegt weinig als herstelwerk en doorontwikkeling niet zijn begroot. Beoordeel de offerte daarom op de volledige lifecycle. Anders verschuift de rekening naar licenties, incidenten en latere aanpassingen.
Prijsmodellen voor softwareontwikkeling vergeleken
De keuze voor een prijsmodel bepaalt wie het risico draagt. Een vaste prijs geeft meer budgetzekerheid, terwijl een uurtarief ruimte laat voor onderzoek en bijsturing. Kies het model daarom op basis van de duidelijkheid van de scope, niet op basis van de laagste startprijs.
| Criterium | Vaste prijs | Uurtarief | Sprint / iteratie |
|---|---|---|---|
| Budgetzekerheid | Hoog binnen vastgelegde scope | Laag voor het eindbedrag | Voorspelbaar per iteratie |
| Flexibiliteit | Beperkt | Hoog | Hoog binnen prioriteiten |
| Transparantie | Afhankelijk van aannames | Hoog per gewerkt uur | Hoog per sprint |
| Geschikt voor | Kleine, duidelijke tools | R&D en onzekere vraagstukken | MVP's en doorontwikkeling |
| Belangrijk risico | Meerwerk en scope-discussies | Uitlopende uren | Te veel wijzigingen per sprint |
Vaste prijs
Een vaste prijs werkt goed voor een kleine interne tool met duidelijke functies, acceptatiecriteria en integraties. Je koopt daarmee budgetzekerheid, maar de leverancier verwerkt het uitvoeringsrisico meestal in de offerte. Elke onduidelijke eis kan later leiden tot meerwerk of discussie over de oorspronkelijke scope.
Vraag bij dit model om expliciete aannames, uitsluitingen en acceptatiecriteria. Zonder die afspraken lijkt de offerte helder, terwijl het financiële risico alleen is verschoven.
Uurtarief
Nederlandse ICT-freelancers hebben volgens recente marktdata een mediaan van ongeveer €105 per uur (Digiboox). Senior developers en specialisten vallen vaak in de bandbreedte van €105–€200 per uur. Het tarief is transparant, maar het eindbedrag hangt af van scope, tempo en besluitvorming.
Dit model past bij R&D, complexe modernisering en projecten waarin aannames eerst moeten worden getest. Leg vooraf een urenplafond, rapportage per rol en duidelijke stopmomenten vast. Zo houd je controle zonder de ontwikkeling kunstmatig dicht te timmeren.
Sprint of iteratie
Bij sprints plan je werk in vaste cycli met een afgesproken budget per cyclus. De scope blijft flexibel, terwijl het bedrag per iteratie voorspelbaar blijft. Dat past bij een MVP en bij producten die op basis van gebruikersfeedback verder worden ontwikkeld.
De bouwsom is bovendien vaak slechts een derde tot de helft van de totale lifecycle-kosten. Vergelijk daarom bij kosten webapplicatie ontwikkeling 2026 niet alleen offertes, maar ook de verwachte kosten voor beheer, hosting en doorontwikkeling. Kies het model waarmee de partner het best kan uitleggen hoe onzekerheid wordt beheerst.
Rekenvoorbeelden voor interne tools, klantportalen en SaaS
Een urenraming maakt een offerte controleerbaar. Gebruik onderstaande scenario's als rekenkader, niet als vaste toezegging. Scope, kwaliteitsniveau, integraties en herbruikbare componenten bepalen de uiteindelijke bouwsom.
| Scenario | Geschatte uren | Team | Doorlooptijd | Bandbreedte bouwprijs |
|---|---|---|---|---|
| Interne inventarisatietool | 300–500 | UX, frontend, backend, QA | Afhankelijk van scope | €25.500–€42.500 bij €85 per uur |
| B2B-klantportaal | 800–1.500 | UX, frontend, backend, QA, DevOps | Afhankelijk van integraties | €68.000–€165.000 bij €85–€110 per uur |
| SaaS-platform | 2.500–5.000 | Product, UX, frontend, backend, DevOps, QA | Afhankelijk van platformscope | €212.500–€550.000 of meer |
Interne inventarisatietool
Een applicatie voor 25 gebruikers bevat bijvoorbeeld login, inventarisregistratie, zoekfuncties, rollen en eenvoudige rapportage. Bij 300–500 uur en €85 per uur komt de rekenkundige bouwprijs uit op €25.500–€42.500.
Een eenvoudige variant kan goedkoper uitvallen met low-code-templates en bestaande componenten. Offline gebruik, complexe autorisaties, uitgebreide rapportages en meerdere gegevensbronnen verhogen de inspanning snel. Vraag daarom welke functies in de raming zijn opgenomen en welke expliciet buiten scope vallen.
B2B-klantportaal
Een portaal met login, CRM-koppeling en facturatie vraagt meer dan het bouwen van enkele schermen. Rechten, synchronisatie, dataconsistentie en foutmeldingen bepalen een groot deel van het werk. Bij 800–1.500 uur en €85–€110 per uur bedraagt de rekenkundige bandbreedte €68.000–€165.000.
Eenvoudige klantportalen en dashboards kunnen volgens Nederlandse prijsindelingen tussen €5.000 en €35.000 kosten wanneer de scope beperkt blijft (Invenix). Een portaal met één workflow is financieel niet vergelijkbaar met een bedrijfsapplicatie met facturatie, meerdere rollen en synchronisatie.
Bij een klantportaal laten ontwikkelen begint een betrouwbare raming daarom met de processen en koppelingen, niet met een lijst schermen.
SaaS-platform
Een multi-tenant platform met abonnementen, beheerfuncties, schaalbaarheid en gescheiden klantdata vereist een volwaardig productteam. Bij 2.500–5.000 uur en €85 per uur ontstaat een rekenprijs van €212.500–€425.000. Specialistische tarieven kunnen dit verhogen tot €550.000 of meer.
Een MVP kan rond €100.000 starten; grotere SaaS-oplossingen vallen vaak binnen €100.000–€250.000 of meer (MG Software). Het verschil zit in tenantbeheer, billing, security, onboarding, support en schaalbaarheid. De rekenvoorbeelden gaan uit van volledig maatwerk met integraties. De bandbreedtes in de introductie omvatten ook eenvoudigere marktvarianten. Vergeet bovendien niet dat de bouwsom vaak slechts een derde tot de helft van de lifecycle-kosten vormt.
Onderhoud, hosting en doorontwikkeling na oplevering
De bouwfactuur is vaak slechts een derde tot de helft van wat software gedurende haar levensduur kost. Na livegang blijven beveiligingspatches, dependency-updates, browsercompatibiliteit, bugfixes en kleine wijzigingen nodig. Reken voor regulier onderhoud met 15–20% van de ontwikkelkosten per jaar. Dat is de praktische vuistregel die je in een offerte en begroting moet opnemen.

Een vijfjaarsberekening
Een Nederlands TCO-voorbeeld laat zien hoe een project met €20.000 bouwkosten over vijf jaar kan oplopen tot ongeveer €72.000. Onderhoud, hosting, licenties en doorontwikkeling bepalen daar een groot deel van het totaal (Coding Agency). De initiële bouwsom vertelt dus maar een beperkt deel van het financiële verhaal.
Voor een klantportaal van €60.000 ziet een reservering voor onderhoud er als volgt uit:
| Kostenpost | Berekening | Bedrag |
|---|---|---|
| Bouw | Eenmalig | €60.000 |
| Onderhoud | 5 × €9.000 | €45.000 |
| Hosting | 5 jaar | €18.000 |
| Doorontwikkeling | Nieuwe functies en verbeteringen | €30.000–€80.000 |
| Totale lifecycle-kosten | Alle posten samen | €153.000–€203.000 |
De bouwsom is in dit voorbeeld ongeveer 30–40% van de lifecycle-prijs. Hosting stijgt bij meer verkeer, strengere beschikbaarheidseisen of complexere infrastructuur. Doorontwikkeling betreft geen defectherstel, maar aanpassingen waarmee de applicatie aansluit op nieuwe processen, klantbehoeften en regelgeving.
Budget na livegang
Reserveer vanaf dag één jaarlijks 20% van de bouwsom voor onderhoud. Dat percentage ligt aan de bovenkant van de vuistregel van 15–20% en geeft bewust een conservatieve marge. Het dekt niet automatisch nieuwe functies, maar voorkomt dat beveiligingsupdates en technisch beheer telkens moeten concurreren met commerciële wensen.
Software zonder onderhoud wordt niet goedkoper. De rekening komt later, vaak tegelijk met een storing, een kwetsbaarheid of een noodzakelijke migratie.
Lees ook de uitleg over wat onderhoud van maatwerksoftware kost.
Checklist voor een betrouwbare offerte en budget
Een betrouwbare offerte laat zien welke aannames de prijs dragen. Een document met alleen een totaalbedrag en een globale functielijst geeft onvoldoende informatie om leveranciers eerlijk te vergelijken.
Vragen voor het offertegesprek
- Prijsmodel: Is de prijs vast, gebaseerd op uren of opgebouwd uit sprints? Welke escalatieclausules gelden wanneer de raming niet meer klopt?
- Urenraming per rol: Hoeveel uren zijn voorzien voor analyse, UX, frontend, backend, QA, DevOps en projectleiding?
- Scope: Zijn design, testen, deployment, documentatie, training en datamigratie inbegrepen?
- Wijzigingen: Hoe worden nieuwe wensen geprioriteerd en geprijsd nadat de bouw is gestart?
- SLA en support: Welke reactietijden gelden na oplevering en welk tarief hoort bij ondersteuning buiten het onderhoudscontract?
- Eigendom: Wie bezit de codebase, licenties, cloudaccounts en toegang tot repositories?
- Hosting: Bij welke partij draait de software en welke infrastructuurkosten zijn structureel?
- Exit: Zijn er exit-clausules, overdrachtsdocumenten en afspraken voor beheer door een andere partij?

Voorbereiding aan opdrachtgeverszijde
Een opdrachtgever moet vóór het gesprek de MVP-scope, must-haves en nice-to-haves vastleggen. Per belangrijke functie horen acceptatiecriteria te staan. Ook deadline en budgetplafond moeten vooraf bekend zijn, anders bepaalt de leverancier onbedoeld de prioriteiten.
Vergelijk minimaal drie offertes, maar vergelijk vooral de inhoud achter het bedrag. Vraag referentieprojecten op die qua gebruikers, integraties en procescomplexiteit werkelijk aansluiten. Een lage prijs zonder vergelijkbare ervaring is geen voordeel, maar een open risico.
Hoe je als MKB of startup een realistisch budget opbouwt
Een offertebedrag is slechts het begin. Plan het budget in drie delen: bouw, buffer en doorontwikkeling. Voor onvoorziene complexiteit is een buffer van 15–25% gebruikelijk. Reserveer daarnaast jaarlijks 20–25% van de bouwsom voor onderhoud en verdere ontwikkeling, zoals eerder toegelicht.
Reken daarom eerst met de vraag: wat mag de applicatie over vijf jaar kosten? Neem hosting, onderhoud, licenties, support en productverbeteringen mee. De bouwsom is vaak maar een derde tot de helft van de totale lifecycle-kosten. Vertaal het vijfjaarsbedrag daarna naar een jaarlijks investeringskader.
De juiste route per organisatie
Een startup die snel een producthypothese wil testen, kiest voor een afgebakende MVP. In het prijsmodel-overzicht ligt daarvoor een bandbreedte van €15.000–€50.000. Deze MVP-bandbreedte gaat uit van één kernflow zonder integraties, en sluit daarmee aan op de klantportaal- en SaaS-scenario's uit de rekenvoorbeelden. Laat de MVP één probleem oplossen, gebruikersfeedback opleveren en functies buiten de eerste productversie vermijden.
Een eenvoudige interne tool kan goedkoper uitvallen, omdat die doorgaans minder gebruikersrollen, externe koppelingen en commerciële productfuncties nodig heeft. Het rekenvoorbeeld van €25.500–€42.500 past bij een bredere scope waarin analyse, bouw, testen en implementatie zijn meegenomen. Vergelijk bedragen dus alleen wanneer scope en oplevering gelijk zijn.
Een MKB-bedrijf met duidelijke interne processen kiest meestal voor fasering. Bouw eerst de kernmodule en voeg functies toe op basis van gebruik, fouten en nieuwe prioriteiten. Zo blijft elke volgende investering gekoppeld aan bewezen waarde.
Een organisatie met SaaS-ambitie reserveert het volledige bouwbudget plus minstens een halfjaar doorontwikkeling voordat de eerste omzet binnenkomt. Multi-tenancy, abonnementen, schaalbaarheid en support horen vanaf het begin bij het productontwerp.
Drie regels voor budgetdiscipline
- Plan niet alles in jaar één: houd geld vrij voor onderhoud, leren en aanpassingen.
- Eis een TCO-berekening: laat bouw, infrastructuur, support en doorontwikkeling over meerdere jaren doorrekenen.
- Heronderhandel scope op tijd: maak keuzes zodra het budget onder druk komt.
Plan software als investering over meerdere jaren, niet uitsluitend uit de winst van het lopende jaar. Zo belast een ambitieus platform de dagelijkse bedrijfsvoering minder.
MG Software bouwt maatwerk webapplicaties, interne tools, klantportalen, API-koppelingen en AI-integraties met duidelijke mijlpalen. Bespreek scope, TCO en fasering via MG Software.

Co-founder




