App laten bouwen kosten: wat bepaalt de prijs?

Een eerste maatwerkoplossing kost in Nederland doorgaans €15.000 tot €75.000. Een beperkte MVP ligt meestal op €15.000 tot €40.000, terwijl een volwassen B2B-app kan oplopen tot €120.000 of meer.

De ondernemer die naar app laten bouwen kosten zoekt, zit vaak met een concreet probleem. Een klantenportaal moet eindelijk van Excel af, een buitendienstteam heeft een mobiele workflow nodig of een startup wil een eerste versie van een digitaal product lanceren. De eerste offertes vallen vervolgens uiteen, terwijl elke leverancier beweert hetzelfde te bouwen. Het verschil zit meestal niet in het aantal schermen, maar in wat er achter die schermen moet gebeuren.

Wie alleen naar design en schermen kijkt, mist de duurste onderdelen. Backend-logica, integraties, autorisaties, datamigratie, foutafhandeling, testen en onderhoud bepalen samen de werkelijke investering. Een lage prijs op papier kan daardoor snel veranderen in een duur traject zodra bestaande systemen, legacy-code of extra gebruikersrollen in beeld komen.

Een ondernemer start met een helder doel: een klantenportaal moet van Excel af, een buitendienstteam heeft een mobiele workflow nodig of een startup wil een eerste productversie lanceren. Daarna komen offertes binnen die sterk uiteenlopen. Dat verschil ontstaat zelden door het aantal schermen. De kosten zitten vooral in de techniek achter de interface.

De Nederlandse markt kent daarom geen vaste standaardprijs voor “een app”. De concrete budgetzones per type app staan in de volgende sectie. Voor uw begroting telt vooral hoeveel bedrijfsprocessen, systemen en uitzonderingen de applicatie betrouwbaar moet afhandelen. Die Nederlandse marktindicaties zijn ook uitgewerkt in de analyse van app-ontwikkelingskosten.

Een app met enkele schermen kan duurder uitvallen dan een grotere informatieve toepassing. Dat gebeurt zodra gebruikersgegevens moeten synchroniseren, bestaande software moet worden gekoppeld of complexe bedrijfsregels moeten worden afgedwongen.

De zichtbare interface is slechts één onderdeel. Backend-logica, integraties, autorisaties, datamigratie, foutafhandeling, testen en onderhoud bepalen de werkelijke investering. Vooral een koppeling met ERP, CRM of boekhouding vraagt meer dan een API aansluiten. U heeft ook logging, foutafhandeling, monitoring en afspraken nodig voor wijzigingen aan het bronsysteem.

Legacy maakt die rekening minder voorspelbaar. Oude code en inconsistente data moeten eerst worden onderzocht, opgeschoond of gemigreerd. Zonder die voorbereiding lijkt een offerte aantrekkelijk, totdat uitzonderingen tijdens de bouw extra werk veroorzaken.

Ook doorlopend onderhoud hoort in het financiële plan. Updates van iOS en Android, beveiligingspatches, wijzigingen in gekoppelde systemen en nieuwe releases vragen tijd, zelfs wanneer de functionaliteit nauwelijks verandert.

Vraag daarom bij elke offerte:

• welke systemen worden gekoppeld;
• welke data wordt gemigreerd;
• welke rollen en uitzonderingen zijn inbegrepen;
• wie testen, monitoring en updates uitvoert;
• welke werkzaamheden buiten de prijs vallen.

Een lage aanneemsom zegt weinig als deze verantwoordelijkheden ontbreken. Beoordeel de offerte op de totale technische verantwoordelijkheid, niet op het aantal schermen.

De snelste manier om offertes te beoordelen, is het project eerst in een complexiteitsniveau te plaatsen. Een beperkte MVP is bedoeld om een kernprobleem werkend te testen. Een volwassen B2B-app ondersteunt een bedrijfsproces. Een enterprise-oplossing moet meerdere organisaties, platformen, datastromen en uitzonderingen betrouwbaar afhandelen.

Deze indeling sluit aan bij de Nederlandse prijsindicaties voor apps. De bedragen zijn geen productprijzen, maar budgetzones voor verschillende technische verantwoordelijkheden.

Een goede MVP bevat alleen wat nodig is om de kernwaarde te testen. Dat betekent niet dat kwaliteit overbodig is. Authenticatie, gegevensopslag, foutmeldingen en een beheersbare technische basis blijven noodzakelijk wanneer echte gebruikers de software inzetten.

De fout ontstaat wanneer een startup meteen alle gewenste functies laat bouwen. Chat, betalingen, uitgebreide rapportages, meerdere rollen en koppelingen lijken afzonderlijk kleine toevoegingen. Samen veranderen ze het project in een systeem met meer staten, uitzonderingen en testcombinaties.

Een zakelijke app wordt duurder zodra de software rekening moet houden met verschillende gebruikersgroepen. Een planner mag bijvoorbeeld opdrachten aanpassen, een medewerker mag alleen eigen taken zien en een klant mag uitsluitend de voortgang van de eigen dossiers bekijken.

Elke rol beïnvloedt:

• Datatoegang, zodat gebruikers geen informatie van anderen zien.
• Workflowregels, omdat acties per rol kunnen verschillen.
• Meldingen, die op het juiste moment en aan de juiste persoon moeten verschijnen.
• Rapportages, die per account, team of klant kunnen variëren.
• Regressietests, omdat een wijziging voor de ene rol een andere rol kan raken.

Realtime data, betalingen en multi-tenant architectuur verhogen niet alleen de bouwinspanning. Ze maken ook de gevolgen van fouten groter. Een tijdelijke API-storing, dubbele betaling of verkeerde tenantfiltering vraagt om logging, herstelprocedures en gerichte tests.

Daarom moet een leverancier niet alleen een lijst met schermen prijzen. De offerte moet aangeven welke gegevensstromen, rollen, integraties en uitzonderingssituaties worden meegenomen. Een overzicht van de technische factoren achter Nederlandse app-kosten maakt duidelijk waarom extra integraties en autorisaties zowel ontwikkelwerk als onderhoudslast toevoegen.

Een offerte van €90 per uur kan goedkoper uitvallen dan een offerte van €120 per uur. Het verschil zit in de scope, de teammix en de hoeveelheid herstelwerk. Nederlandse softwarebureaus werken doorgaans met uurtarieven van €90 tot €160 per uur. De eindprijs volgt uit uren maal tarief, verdeeld over de rollen die uw app nodig heeft.

Een app wordt zelden door één persoon gebouwd. Een frontenddeveloper maakt de interface, een backenddeveloper verwerkt gegevens en bedrijfslogica, een UX-designer werkt gebruikersstromen uit en een tester controleert gedrag op apparaten en scenario's. Bij een klein project kunnen teamleden rollen combineren. Analyse, testen, integraties en deployment verdwijnen daardoor niet uit de planning.

Vraag minimaal om deze onderdelen:

1. Aannames over de scope. Welke gebruikers, platformen, schermen en processen zijn inbegrepen?
2. Een urenverdeling. Hoeveel tijd gaat naar analyse, ontwerp, frontend, backend, testen en deployment?
3. De teamopbouw. Welke werkzaamheden voert een senior uit en welke door andere teamleden?
4. Uitsluitingen. Zijn datamigratie, store-publicatie, hosting en onderhoud opgenomen?
5. Wijzigingsregels. Wat gebeurt er wanneer tijdens de bouw een functie wordt toegevoegd?

Kijk ook naar werk buiten de schermen. Een CRM-, ERP- of betaalintegratie vraagt om foutafhandeling, logging en tests. Bij legacy-migratie komen datakwaliteit, conversieregels en controles op oude gegevens erbij. Een offerte die alleen schermen opsomt, laat juist deze kosten snel buiten beeld.

De platformkeuze beïnvloedt de uren. Native iOS- en Android-apps bieden per platform veel controle, maar vragen afzonderlijke implementatie en tests. Cross-platform ontwikkeling kan code delen. Een webapplicatie of progressive web app volstaat soms, vooral wanneer browsertoegang belangrijker is dan toestelfuncties.

Een freelancer biedt directe communicatie, maar vergroot de afhankelijkheid van één persoon. Een bureau brengt bredere expertise, terwijl u moet controleren hoeveel contact u met ontwikkelaars heeft. Een nearshoreteam kan financieel aantrekkelijk zijn, maar overdracht, communicatie en productkennis moeten strak worden georganiseerd.

Beoordeel de offerte op voorspelbaarheid. Een goedkoop team dat verkeerde aannames codeert, kan uiteindelijk meer uren maken dan een duurder team dat scope, integraties en migratie vooraf scherp vastlegt.

Een app is niet af wanneer de eerste versie in de stores staat. Vanaf dat moment draait de software in een omgeving die blijft veranderen. Hosting moet beschikbaar blijven, externe API's kunnen wijzigen en iOS, Android, browsers en beveiligingscomponenten krijgen nieuwe versies.

Doorlopende werkzaamheden vallen meestal in vier groepen:

• Hosting en infrastructuur: servers, databases, opslag, back-ups en monitoring moeten blijven functioneren.
• Technisch onderhoud: bugs, beveiligingsupdates en compatibiliteit met nieuwe platformversies vragen opvolging.
• Koppelingen: een ERP- of CRM-leverancier kan een API aanpassen, waardoor synchronisatie opnieuw getest moet worden.
• Doorontwikkeling: gebruikersfeedback leidt tot nieuwe functies, verbeterde workflows en aanvullende rapportages.

Ook publicatie in appstores vraagt beheer. Certificaten, store-eisen en releases moeten worden opgevolgd. Bij zakelijke apps komt daar vaak support bij, zodat incidenten niet blijven liggen tot de volgende geplande sprint.

Een onderhoudscontract of strippenkaart voorkomt dat elk probleem opnieuw als spoedproject wordt behandeld. De afspraken moeten duidelijk maken wie monitoring uitvoert, hoe incidenten worden gemeld, welke responstijd geldt en welke werkzaamheden onder regulier onderhoud vallen.

Meer achtergrond staat in de uitleg over onderhoud van maatwerksoftware. De relevante vraag is niet of onderhoud geld kost, maar hoeveel operationeel risico ontstaat wanneer niemand structureel verantwoordelijk is.

Een app zonder onderhoudsafspraak is geen afgerond product. Het is een bedrijfskritisch systeem zonder eigenaar.

Goede logging verlaagt de tijd die nodig is om incidenten te analyseren. Een schaalbare architectuur maakt uitbreidingen voorspelbaarder. Heldere documentatie voorkomt bovendien dat een nieuwe ontwikkelaar eerst de volledige codebase moet reconstrueren voordat een kleine wijziging veilig kan worden uitgevoerd.

De totale eigendomskosten bestaan daarom uit meer dan de bouwfactuur. Een lage initiële prijs met slechte logging, onduidelijke code en geen onderhoudsplan kan later duurder uitvallen dan een degelijk opgebouwde eerste versie.

Voor veel MKB-bedrijven is de app geen zelfstandig product. De app vormt een nieuwe toegangspoort tot een ERP, CRM, boekhoudpakket, webshop of planningssysteem. De interface is zichtbaar voor gebruikers, maar de financiële risico's zitten vaak in de gegevensstromen erachter.

Een koppeling moet bepalen welke bron leidend is, wanneer gegevens worden opgehaald, hoe wijzigingen worden verwerkt en wat er gebeurt wanneer een systeem tijdelijk niet beschikbaar is. Bij een bestelling kan bijvoorbeeld de webshop de verkoop registreren, het ERP de voorraad beheren en de boekhouding de facturatie afhandelen. Zonder duidelijke afspraken ontstaat dubbele data of handmatig herstelwerk.

De kosten van een integratie zitten niet alleen in het aanroepen van een API. Een betrouwbare koppeling heeft ook nodig:

• Datamapping: velden uit verschillende systemen moeten logisch op elkaar aansluiten.
• Validatie: onvolledige of ongeldige gegevens mogen de workflow niet stilleggen.
• Foutafhandeling: tijdelijke storingen moeten herkenbaar zijn en veilig opnieuw kunnen worden verwerkt.
• Synchronisatie: het systeem moet omgaan met wijzigingen, vertragingen en dubbele berichten.
• Monitoring: beheerders moeten kunnen zien welke transacties gelukt of mislukt zijn.

Een praktische verdieping staat in de uitleg over API-koppelingen. De meerwaarde zit niet in het verbinden van twee systemen op zichzelf, maar in een gegevensstroom die onder normale én afwijkende omstandigheden correct blijft werken.

Bij verouderde software is de bestaande documentatie vaak beperkt. Databases kunnen historische uitzonderingen bevatten, businessregels kunnen verspreid staan over oude modules en medewerkers kunnen workarounds gebruiken die nooit formeel zijn vastgelegd.

Daardoor zegt het aantal schermen weinig over de migratie-inspanning. Een modern scherm kan snel worden gebouwd, maar de onderliggende vraag blijft: welke gegevens moeten behouden blijven, welke regels mogen veranderen en hoe kan de operatie tijdens de overgang doorgaan?

Een volledige herbouw is aantrekkelijk wanneer de bestaande code onvoldoende te testen of te onderhouden is, de architectuur nieuwe functies blokkeert of de organisatie structureel veel tijd besteedt aan herstelwerk. Doorbouwen is verstandiger wanneer de kern stabiel is, de data goed begrepen wordt en onderdelen gecontroleerd kunnen worden vervangen.

Een gefaseerde aanpak beperkt het risico. Eerst wordt de bestaande situatie onderzocht, daarna worden gegevensstromen en kritieke processen vastgelegd. Nieuwe onderdelen kunnen vervolgens naast het oude systeem draaien totdat gebruikers en data gecontroleerd zijn overgezet.

De belangrijkste budgetvraag luidt daarom niet “hoeveel schermen krijgt de app?”, maar “welke onzekerheid zit in de bestaande systemen?” Wie die onzekerheid niet onderzoekt, krijgt vaak pas tijdens de bouw te maken met verborgen regels, ontbrekende gegevens en onverwachte afhankelijkheden.

Budgetbeheersing begint vóór de eerste regel code. Een team dat een onduidelijk idee rechtstreeks laat bouwen, betaalt ontwikkelaars om beslissingen uit te zoeken die eerder met gebruikers, procesdeskundigen en technische analyse hadden kunnen worden genomen.

De MVP moet één kernprobleem oplossen voor een duidelijk omschreven gebruikersgroep. Een intern planningssysteem hoeft niet meteen alle rapportages, mobiele functies en uitzonderingsroutes te bevatten. Een klantportaal kan beginnen met authenticatie, de belangrijkste statusinformatie en één actie die klanten zelfstandig kunnen uitvoeren.

Gebruik vervolgens echte feedback om de volgende fase te bepalen. Features die intern belangrijk lijken, blijken in gebruik soms weinig waarde te leveren. Andere knelpunten komen pas naar voren zodra medewerkers dagelijks met de eerste versie werken.

Een bruikbaar projectplan benoemt niet alleen functies, maar ook beslismomenten. De volgende aanpak beperkt verrassingen:

• Scope vastleggen: beschrijf per functie wat de gebruiker doet, welke data nodig is en wanneer de functie klaar is.
• Mijlpalen koppelen aan resultaat: beoordeel een sprint op werkende functionaliteit, niet op het aantal gewerkte uren.
• Wijzigingen parkeren: plaats nieuwe ideeën op een backlog en bepaal later of ze in een volgende fase thuishoren.
• Integraties vroeg onderzoeken: controleer API-documentatie, datakwaliteit en toegangsrechten voordat de interface wordt uitgewerkt.
• Onderhoud vooraf bespreken: neem hosting, monitoring, updates en support mee in de totale begroting.

Een SaaS-oplossing is logisch wanneer een proces standaard is en een bestaand product het grootste deel van de behoefte afdekt. Maatwerk past beter wanneer medewerkers meerdere systemen combineren, handmatig gegevens overzetten of een bedrijfseigen proces niet in een standaardworkflow past.

Een hybride keuze is vaak rationeel. Boekhouding en e-mail kunnen in bestaande software blijven, terwijl een maatwerkportaal of workflowlaag de ontbrekende bedrijfslogica toevoegt. Zo hoeft een organisatie niet het volledige IT-landschap te vervangen om één knelpunt op te lossen.

Budgetadvies: bouw eerst wat omzet, tijd of operationele betrouwbaarheid direct beïnvloedt. Alles daarbuiten moet zijn waarde nog bewijzen.

De beste ontwikkelpartner verkoopt geen schermenpakket, maar helpt het bedrijfsprobleem afbakenen. Tijdens een eerste gesprek moet duidelijk worden welke processen veranderen, welke systemen gekoppeld moeten worden en welke risico's de leverancier vóór de bouw wil onderzoeken.

Vraag om een offerte die de volgende onderdelen afzonderlijk benoemt:

1. Analyse en scope: welke aannames zijn gecontroleerd en welke vragen staan nog open?
2. Technische architectuur: hoe worden frontend, backend, database, integraties en autorisaties ingericht?
3. Testaanpak: welke apparaten, rollen, foutscenario's en integraties worden getest?
4. Migratie: hoe worden bestaande gegevens gecontroleerd en hoe blijft de operatie beschikbaar?
5. Oplevering: wie verzorgt deployment, store-publicatie, documentatie en overdracht?
6. Nazorg: welke afspraken gelden voor hosting, monitoring, bugs en doorontwikkeling?

Directe toegang tot de developers maakt bijsturen eenvoudiger. Een moderne stack met bijvoorbeeld React, Next.js, Node.js of Python kan geschikt zijn, maar technologie is geen vervanging voor een goed ontwerp en heldere verantwoordelijkheden. De partner moet kunnen uitleggen waarom een bepaalde aanpak past bij de schaal, integraties en levensduur van de applicatie.

Lees ook hoe een organisatie een developmentpartner kiest. Een serieuze partij bespreekt niet alleen de eerste release, maar ook technische SEO voor webapplicaties, schaalbaarheid, logging en onderhoud na oplevering.

Controleer ten slotte of toegankelijkheid onderdeel is van de oplevering. Voor Nederlandse digitale diensten beschouwt het Dashboard DigiToegankelijk alleen status A als volledig toegankelijk. Dat maakt toegankelijkheid geen vrijblijvende ontwerpvoorkeur wanneer een organisatie onder publieke toegankelijkheidseisen valt.

MG Software bouwt maatwerk webapplicaties, mobiele apps, API-koppelingen en gefaseerde legacy-moderniseringen, met aandacht voor scope, onderhoud en technische SEO. Bespreek de bedrijfsprocessen en integratierisico's met MG Software voordat er een offerte wordt aangevraagd, zodat de prijs gebaseerd is op de werkelijke oplossing en niet alleen op het aantal schermen.