Wat kost het maken van een app en hoe plan je je budget

Voor een MVP met één platform ligt het budget in Nederland vaak op €15.000–€40.000, terwijl een volwassen B2B-app doorgaans €40.000–€120.000+ kost. Het verschil zit vooral in scope, integraties, rollen, onderhoud en de uurtarieven van het gekozen team.

Een ondernemer die zoekt op “wat kost het maken van een app” heeft meestal al een idee, maar nog geen scherp afgebakend product. Er ligt misschien een eerste schets, een lijst met functies en een paar enthousiaste offertes. De ene ontwikkelaar noemt een bedrag dat binnen het budget past, terwijl een bureau voor ogenschijnlijk dezelfde app veel hoger uitkomt. Dat voelt verwarrend, maar de offertes beschrijven vaak niet hetzelfde product.

De betere vraag luidt daarom niet alleen wat de bouwprijs is. De relevante vraag is wat het kost om de app drie jaar betrouwbaar, veilig en bruikbaar te laten draaien. Onderhoud, hosting, monitoring, API-wijzigingen, app-store-updates en compliance horen vanaf het begin bij het budget.

Een MKB-ondernemer vat een app vaak samen als één idee: klanten loggen in, bekijken gegevens en dienen een aanvraag in. Voor een ontwikkelteam bestaat dat idee uit schermen, gebruikersrollen, datamodellen, backendlogica, koppelingen, beveiliging, tests en publicatie. Elke extra laag vraagt ontwerp, bouw en controle. Daar ontstaat het prijsverschil.

Een eerste werkende versie van een MKB-app kost in Nederlandse marktindicaties vaak €15.000–€50.000. Een beperkte MVP wordt regelmatig geraamd op €15.000–€40.000. Een volwassen B2B-app valt eerder binnen €40.000–€120.000+, afhankelijk van functies, integraties en beheer, volgens deze Nederlandse kostenraming voor appontwikkeling.

Stel, twee bureaus bouwen een klantportaal. Bureau A rekent met één platform, een basislogin en eenvoudige formulieren. Bureau B neemt meerdere rollen, CRM-koppeling, pushmeldingen, foutafhandeling, uitgebreide autorisaties en ondersteuning na livegang mee. Beide noemen het een klantportaal, maar leveren technisch een ander product.

Ook de samenstelling van het team beïnvloedt de offerte. Freelancers rekenen indicatief €60–€100 per uur en bureaus €85–€140 per uur, exclusief btw. Een hoger tarief garandeert geen beter resultaat. Zonder urenverdeling blijft bovendien onduidelijk welke werkzaamheden het verschil verklaren.

Praktische regel: vergelijk niet alleen het eindbedrag. Controleer wat elk team bouwt, test, oplevert en na de lancering beheert.

Een realistisch budget kijkt daarom verder dan de eerste bouwfactuur. Kies eerst welke versie klanten nodig hebben. Plan daarna de groei van MVP naar volwassen app, terwijl je onderhoud, hosting en compliance voor de eerste drie jaar meeneemt. Zo wordt de bouwprijs een budgetkeuze, geen losse verrassing.

Een ondernemer die een app wil laten bouwen, koopt geen verzameling schermen. Hij financiert een werkend product. Een scherm lijkt op een kamer, maar zonder fundering, leidingen en onderhoud is het geen bruikbaar huis. Bij een app zijn architectuur, gebruikersbeheer en dataopslag de fundering. Functies vormen de kamers, API-koppelingen de leidingen. Testen, beveiliging en publicatie maken het geheel geschikt voor gebruik.

De basisformule is helder: uren maal uurtarief bepaalt de ontwikkelkosten. Nederlandse marktdata noemt voor softwareontwikkeling bij bureaus doorgaans €90–€160 per uur. Zzp-softwaredevelopers rekenen gemiddeld circa €94 per uur, volgens deze Nederlandse uitleg over softwareontwikkelkosten.

Een bruikbare offerte laat zien welke werkzaamheden de uren veroorzaken:

• Product en UX: gebruikersonderzoek, procesflows en wireframes of ontwerpen. Zo voorkom je dat techniek op een verkeerd proces wordt gebouwd.
• Frontend: schermen, formulieren, navigatie en foutmeldingen die gebruikers bedienen.
• Backend: bedrijfsregels, gegevensopslag en rechtenbeheer.
• Koppelingen: verbindingen met ERP, CRM, webshop of boekhouding, inclusief data-afspraken, authenticatie en foutafhandeling.
• Testen: functionele tests, regressietests en eventueel testautomatisering.
• Publicatie: voorbereiding van appstores, release-instellingen en controle op verschillende apparaten.

Een offerte zonder urenverdeling maakt vergelijken lastig. Vraag daarom per bouwblok welke aannames gelden, wat binnen de oplevering valt en welke werkzaamheden later terugkomen.

UX-onderzoek en testautomatisering zijn geen decoratie. Ze verkleinen de kans dat gebruikers na de lancering vastlopen of dat een koppeling pas in productie onbetrouwbaar blijkt.

De ontwikkelsom is het startpunt, niet de totale rekening. Hosting, monitoring, beveiligingsupdates, afhankelijkheden en kleine verbeteringen blijven na oplevering nodig. Kijk daarom naar de kosten over drie jaar, inclusief onderhoud en compliance. De eerste factuur vergelijken zonder die posten is alsof je alleen de aanschafprijs van een auto bekijkt, zonder brandstof, onderhoud en verzekering.

Ook de planning beïnvloedt het budget. Een middelgrote app met meerdere rollen, koppelingen en beheerfuncties vraagt vaak 6 tot 16 weken voor een MVP en 3 tot 8 maanden voor een standaard webapp. Integraties, regressietests en releases bepalen mede de doorlooptijd. Faseer daarom van MVP naar volwassen app, zodat je eerst de noodzakelijke werking financiert en latere uitbreiding bewust plant.

Een app kan met hetzelfde idee toch een heel ander budget krijgen. Het verschil zit in keuzes die extra ontwerp-, ontwikkel-, test- en beheerwerk veroorzaken. Voor MKB- en B2B-projecten bepalen vooral zes kostendrivers de rekening.

Een app voor alleen iOS vraagt een andere aanpak dan een oplossing voor iOS, Android en web. Cross-platformontwikkeling kan code hergebruiken, maar moet passen bij prestaties, apparaatfuncties en beheer. Elk extra platform vraagt controle, publicatie en later ook onderhoud.

Het aantal schermen zegt weinig zonder de onderliggende logica. Een informatiescherm is eenvoudiger dan een scherm met filters, bestanden, rollen, offline gedrag en foutafhandeling. Kijk daarom niet alleen naar schermen, maar naar het aantal beslissingen en uitzonderingen dat achter elk scherm schuilgaat.

Een bestaand ontwerpsysteem of template kan de start versnellen. Maatwerkdesign past wanneer de gebruikerservaring onderscheidend moet zijn of een proces veel uitzonderingen kent. De grootste besparing komt vaak door functies te schrappen die niet bijdragen aan het kernprobleem, niet door alleen kleuren of iconen te vereenvoudigen.

Login, betalingen, chat, notificaties en dashboards verhogen de complexiteit. Functies met meerdere statussen vragen extra logica en tests. Een aanvraag die kan worden goedgekeurd, afgewezen, teruggestuurd en opnieuw ingediend, werkt als een kleine beslisboom. Elke route moet correct worden gebouwd en gecontroleerd.

Een koppeling met een ERP, CRM of boekhouding lijkt op een technische aansluiting. Het team moet ook vastleggen welke gegevens leidend zijn, wanneer synchronisatie plaatsvindt, hoe fouten worden afgehandeld en wat er gebeurt als een externe API verandert.

Daarom kunnen integraties bij zakelijke apps meer werk opleveren dan losse schermen. Achter één knop kunnen meerdere datastromen, controles en autorisaties zitten. Een vroege keuze voor de belangrijkste koppelingen helpt om de MVP klein te houden en latere uitbreiding planbaar te maken.

Een medewerker, manager, klant en beheerder hebben vaak verschillende rechten. Die autorisaties moeten niet alleen in de interface zichtbaar zijn, maar ook in de backend worden afgedwongen. Anders kan een gebruiker buiten de app alsnog gegevens opvragen.

Toegankelijkheid, privacy-by-design, logging en beveiligingsupdates vragen vanaf het begin aandacht. Wie deze eisen pas na de bouw toevoegt, kan delen van de app opnieuw moeten ontwikkelen. Neem ze daarom mee in de scope en in de kosten voor de periode na de lancering.

Een hoger uurtarief kan samengaan met minder uren door betere voorbereiding en relevante ervaring. Een lager tarief kan duurder uitpakken wanneer aannames onduidelijk zijn en herstelwerk ontstaat. Vergelijk offertes daarom op aanpak, aannames en oplevering, niet alleen op het tarief. De genoemde Nederlandse kostenindicatie is eerder in het artikel al gebruikt. Kijk voor een realistisch budget bovendien naar bouw én de kosten van onderhoud en beheer over drie jaar.

Een ondernemer met een idee voor een app kan hetzelfde budget heel anders inzetten. Begin je met één kernprobleem, dan test je sneller wat gebruikers nodig hebben. Bouw je direct een compleet platform, dan betaal je ook voor rollen, koppelingen, beheer en toekomstige groei. De volgende indeling maakt dat verschil concreet.

De MVP-bandbreedte van €15.000–€40.000 past bij een eerste versie met één platform, vijf tot acht kernschermen en basislogin. Voeg je meerdere rollen, API-koppelingen, push-notificaties en storepublicatie toe, dan groeit niet alleen het aantal functies. Ook ontwerp, testen en beheer worden uitgebreider. Zie de bedragen als een oriëntatiepunt, niet als een vaste offerte.

Een standaard B2B-app of klantportaal ondersteunt meestal een volledig proces. Denk aan beheerfuncties, autorisaties, gegevensuitwisseling en controles. De range van €40.000–€120.000 geeft richting aan het budget, terwijl de precieze scope bepaalt waar je binnen die bandbreedte uitkomt.

Een complex SaaS-platform lijkt eerder op een digitale infrastructuur dan op één losse app. Schaalbaarheid, uitgebreide rechten, analytics, meerdere koppelingen en beheerprocessen moeten vanaf het begin op elkaar aansluiten. Daarvoor worden bandbreedtes van €150.000–€500.000+ genoemd, afhankelijk van de technische en organisatorische complexiteit.

Een MVP is geen afgewerkte versie met minder knoppen. Het is een bewuste keuze om eerst de belangrijkste aanname te testen.

Wie die eerste fase zorgvuldig wil afbakenen, kan de aanpak verdiepen met deze uitleg over een MVP ontwikkelen. Reserveer naast het eerste bouwbudget ook ruimte voor onderhoud, hosting, compliance en de volgende iteratie. Zo wordt een lage instapprijs geen hoge totale kostenpost.

Na de lancering blijft een app werk vragen. Besturingssystemen veranderen, bibliotheken en API's krijgen updates en gebruikers melden fouten. Onderhoud, hosting en compliance horen daarom vanaf het begin in het budget, niet pas nadat de eerste versie live staat.

Voor onderhoud en updates wordt vaak 5–15% van de bouwkosten per jaar gerekend. Bij complexere B2B- of SaaS-oplossingen kan dat oplopen tot 15–25% per jaar, bijvoorbeeld door beveiligingspatches, dependency-updates en kleine verbeteringen. Ook hosting en beheerposten horen bij deze raming, zoals toegelicht in deze Nederlandse uitleg over de kosten van een app laten maken.

Bij bouwkosten van €40.000 betekent 15–25% onderhoud ongeveer €6.000–€10.000 per jaar. Hosting en doorontwikkeling zijn daarin nog niet opgenomen. Over drie jaar komt onderhoud alleen al neer op ongeveer €18.000–€30.000, volgens deze TCO-uitleg voor appontwikkeling.

Operationele kosten bestaan onder meer uit hosting en PaaS van circa €20–€500+ per maand, monitoring en logging van ongeveer €20–€150+ per maand, en domeinen en certificaten van ongeveer €10–€200 per jaar. Het bedrag hangt samen met gebruik, datavolume, beschikbaarheidseisen en support.

Een bruikbare driejaarsbegroting bestaat uit drie lagen:

• Bouw: productontwikkeling, design, backend, frontend, tests en release.
• Beheer: beveiligingsupdates, bugfixes, afhankelijkheden, app-store-updates en regressietests.
• Exploitatie: hosting, monitoring, logging, certificaten en wijzigingen aan koppelingen.

Een API-wijziging kan een bestaande functie breken. Een nieuwe iOS- of Android-versie kan opnieuw testen en publiceren nodig maken. Feedback uit de praktijk kan ook aanleiding geven om een workflow aan te passen.

Lees voor de beheerzijde ook de uitleg over onderhoud van maatwerksoftware. De bouwprijs is slechts het startpunt. Door eerst een MVP te bouwen en daarna gericht uit te breiden, houd je de totale kosten over drie jaar beter bestuurbaar.

Budgetcontrole begint voordat een ontwikkelaar een urenraming maakt. Een idee moet eerst worden teruggebracht tot een duidelijke gebruikersgroep, een kernprobleem en een eerste resultaat. Zonder die afbakening wordt elk gesprek een opsomming van extra functies.

Een bruikbare backlog verdeelt functies in drie groepen:

• Must-haves: zonder deze functies lost de eerste versie het kernprobleem niet op.
• Nice-to-haves: waardevol, maar geschikt voor een volgende iteratie.
• Onbesliste opties: ideeën die eerst met gebruikers of data moeten worden getoetst.

Een eerste versie kan bijvoorbeeld bestaan uit accountbeheer, één hoofdworkflow en een eenvoudig overzicht. Chat, uitgebreide analytics of meerdere externe koppelingen kunnen wachten wanneer ze niet nodig zijn om de belangrijkste aanname te testen.

Vraag elk team om dezelfde informatie. Een bedrag zonder onderliggende aannames zegt weinig.

Onderhandel bij voorkeur op scope en oplevering, niet alleen op uurtarief. Een lager tarief helpt weinig als een belangrijke integratie buiten de opdracht valt. Vaste mijlpalen en transparante sprints maken afwijkingen eerder zichtbaar, waardoor een product owner tijdig kan kiezen tussen versoberen, uitstellen of extra budget vrijmaken.

Een kostenraming moet niet alleen een totaal tonen, maar ook de aannames achter dat totaal. Een kostenraming-template voor softwareontwikkeling kan helpen om functies, uren, tarieven, mijlpalen en terugkerende kosten naast elkaar te zetten.

Een praktische volgorde is:

1. Beschrijf het probleem: wie gebruikt de oplossing en welk proces moet verbeteren?
2. Teken de kernflow: welke stappen doorloopt een gebruiker van start tot resultaat?
3. Maak de eerste backlog: scheid noodzakelijk werk van uitgestelde ideeën.
4. Bepaal de technische randvoorwaarden: platformen, koppelingen, rollen, data en beveiliging.
5. Plan de exploitatie: neem onderhoud, hosting, monitoring en wijzigingen mee.
6. Laat meerdere teams dezelfde scope ramen: zo ontstaat een echte vergelijking.

Een transparante offerte maakt niet alleen de prijs zichtbaar, maar ook de keuzes die de prijs veroorzaken.

Voor een eenvoudige eerste versie past een MVP van €15.000–€40.000 vaak beter dan een volledig platform. Een standaard B2B-app met rollen, beheer en koppelingen hoort eerder bij €40.000–€120.000+. Een complex SaaS-platform vraagt een afzonderlijke fasering en kan richting €150.000–€500.000+ gaan.

De juiste keuze hangt af van het risico dat de organisatie eerst wil toetsen. Een MVP past wanneer de kernwaarde nog gevalideerd moet worden. Een volwassen app past wanneer processen, gebruikersrollen en integraties al duidelijk zijn. In beide gevallen moet het budget ook onderhoud, hosting, beveiliging, compliance en drie jaar exploitatie bevatten.

Voor een scherpe offerte zijn een procesbeschrijving, doelgroepen, gewenste platformen, kernschermen, rollen, koppelingen en beheerbehoeften nodig. Een iteratieve werkwijze met directe lijnen naar developers, zoals bij MG Software uit Haarlem, maakt voortgang zichtbaar en laat teams sneller bijsturen wanneer aannames veranderen.

MG Software bouwt maatwerkapps, klantportalen, webapplicaties, API-koppelingen en AI-integraties met duidelijke scope, vaste mijlpalen en onderhoud na oplevering. Bespreek het idee en de gewenste fasering via MG Software en vraag een raming die niet alleen de bouwprijs, maar ook de totale kosten over drie jaar inzichtelijk maakt.