Wat kost een app laten maken?

Wat bepaalt de kosten van een app laten maken?

De vraag "wat kost een app?" is ongeveer net zo concreet als "wat kost een huis?". Een tiny-house op een veld is iets anders dan een gracht-pand met monumentale status, en hetzelfde geldt voor apps. Een interne tool voor twintig medewerkers is een ander beest dan een consumenten-app die de tweede week na launch piekbelasting moet aankunnen. Wat we wel in beeld kunnen brengen, zijn de knoppen die de kosten van een app maken: techniek-keuze, scope, features, design, doorlopend beheer en de mate waarin u zelf meeschrijft aan het ontwerp.

De volgende factoren wegen in onze ervaring het zwaarst:

• Techniek-keuze: native, cross-platform, web-app of hybride — elk model heeft een eigen kostenprofiel.
• Scope: hoeveel schermen, hoeveel rollen, hoeveel use-cases moet de eerste release dekken.
• Custom design vs. component-library: hoe meer pixel-perfect afwijkend van standaardpatronen, hoe meer ontwerp- en bouwtijd.
• Backend en data: alleen een schil over bestaande API's, of moet er ook nieuwe backend-logica en database-modellering komen?
• Integraties: hoeveel externe systemen moeten meepraten — denk aan boekhouding, CRM, payment, push, identity, analytics.
• Compliance en security: verwerkt de app persoonsgegevens, betalingen, medische data of inloggegevens op enterprise-niveau.
• Beheer: wie houdt 'm draaiend nadat versie 1 in de stores staat.

Wij werken met vaste sprintbudgetten en spreken vooraf een scope per sprint af, zodat u op elk moment kunt bijsturen. Een gedetailleerde uitsplitsing voor uw specifieke geval bespreken we graag in een kennismaking. Voor een breder beeld van wat softwareontwikkeling typisch kost, kunt u ook onze pagina over maatwerk software kosten lezen — veel principes overlappen met app-budgetten.

Native of cross-platform: de grootste kostenknop

De eerste serieuze beslissing is bijna altijd techniek-keuze. Globaal hebben we drie smaken: native, cross-platform en mobile web. Elk hebben ze hun thuiswedstrijd.

Native (Swift / Kotlin)

Voor iOS bouwt u in Swift, voor Android in Kotlin. Twee codebases, twee disciplines, twee teams of dubbele expertise. Native geeft u de absolute best mogelijke prestaties, volledige toegang tot platform-features en de meest verfijnde gebruikerservaring. De prijs is dat u feitelijk twee keer bouwt. Voor heavy graphics-, camera- of sensor-apps blijft native de eerste keuze.

Cross-platform (Flutter, React Native)

Eén codebase die zowel iOS als Android oplevert. Flutter (van Google) en React Native (van Meta) zijn beide volwassen volwaardige frameworks die in 2026 vrijwel alles aankunnen wat een native app ook kan. Voor de meeste B2B-apps, MVP's en consumenten-apps zonder zware grafische workload is dit de pragmatische keuze: ongeveer één codebase die het bouwwerk in zijn geheel ongeveer een derde tot de helft scheelt.

Mobile web / progressive web app

Een web-app die op een telefoon werkt — geen store-installatie nodig. Goedkoper en sneller te lanceren, maar geen toegang tot push notifications op iOS (Apple beperkt dat fors), geen rijke offline-mode, en gebruikers vinden 'm niet via de app-stores. Voor interne tools of B2B-portals een prima keuze; voor consumenten-apps zelden de winnende route. Lees ook onze guide over build vs buy als u twijfelt of u sowieso zelf moet bouwen.

iOS, Android of allebei?

Een vraag die we vaker krijgen dan u zou denken: moet de eerste versie echt op beide platforms staan? Het antwoord hangt af van uw doelgroep, niet van uw voorkeur.

Voor consumenten in Nederland is het marktaandeel grofweg fifty-fifty Android/iOS — een consumenten-app op één platform laten staan betekent de helft van uw markt missen. Voor zakelijke gebruikers in Nederland is iOS oververtegenwoordigd, vooral bij directie-, sales- en marketingfuncties. Voor logistiek, magazijn en buitendienst is Android dominant omdat de hardware goedkoper en robuuster is.

Een legitieme strategie is om met cross-platform te starten en beide stores tegelijk te bedienen — dat is precies waarom Flutter en React Native zo populair zijn geworden voor MVP's. Wilt u native gaan maar het budget temmen, dan kunt u één platform eerst lanceren en op basis van vroege gebruikersinzichten beslissen of platform nummer twee de moeite waard is. Bij app-ontwikkeling doen we beide trajecten — we adviseren op basis van uw doelgroep, niet op basis van wat technisch het leukst is om te bouwen.

App-types: niet elke app is een app

"Een app laten maken" is een paraplu-term. Onder die paraplu vallen heel verschillende projecten met heel verschillende prijskaartjes. Een handvol scenario's die we regelmatig zien:

Consumenten-app (B2C)

Voor het brede publiek, in beide app-stores, met onboarding, accounts, push, in-app payments en strenge eisen aan polish en performance. De duurste categorie omdat alles moet kloppen: design, copy, edge cases, App Store reviews, ondersteuning voor oude toestellen. Hier is een MVP een serieus risico — een matige consumenten-app krijgt direct lage reviews en is moeilijk te redden.

B2B-app voor klanten of partners

Een app voor uw bestaande klanten of leveranciers. Bekende gebruikers, vaak gekoppeld aan uw bestaande backend, minder afhankelijk van virale onboarding-trucs. De business case is meestal helder: efficiency, retentie, of een extra service-laag bovenop een bestaand product. Cross-platform is vrijwel altijd de juiste keuze.

Interne app voor eigen medewerkers

Bijvoorbeeld een buitendienst-app voor monteurs, een orderpick-app voor magazijn of een rapportage-tool voor managers. De gebruikersgroep is bekend en getraind, de hardware kunt u zelf voorschrijven, de eisen aan design zijn lager. Dit is bijna altijd de meest kosten-efficiënte categorie. Een progressive web app is hier vaak goed genoeg.

MVP / pilot

Een doelbewust afgeslankte eerste versie om een hypothese te testen. Niet hetzelfde als "een goedkope app" — een MVP is een leerinstrument, niet een productie-systeem. De waarde zit in wat u leert in de eerste maanden, niet in wat u oplevert in week één. Hier zien we de meeste verspilling: teams die een MVP bouwen alsof het een productie-app is, of teams die een productie-app bouwen onder de noemer MVP.

Productie-app

De volwassen versie. Robuust, gemonitord, getest, schaalbaar, met een release-pijplijn. Het is geen toeval dat de stap van MVP naar productie-app vaak duurder is dan de MVP zelf — alles wat u in de MVP voor lief hebt genomen, moet nu structureel geregeld worden.

Welke features drijven het budget op?

Niet elke feature kost evenveel. Een handvol categorieën die in praktijk het meest impact hebben op het budget:

• Real-time functionaliteit: chat, live-updates, multi-user editing. Vereist websockets of dedicated infrastructuur, fors meer backend-werk.
• Offline-mode: apps die ook zonder verbinding moeten werken en later synchroniseren. Concept van data-consistentie wordt ineens een hoofdpijndossier — reken op significant meer testing.
• Custom UI vs. component-library: als elk scherm uniek getekend is en niet uit een design-system bestaat, neemt de bouwtijd snel toe. Een goed component-library is uw beste budget-vriend.
• In-app payments: Apple en Google nemen 15-30% commissie op digitale goederen in hun stores. Daarnaast moet u Apple's In-App Purchase API of Google Play Billing implementeren, met restore, refunds en family sharing-edge cases.
• Push notifications: basic push is goedkoop, gerichte segmentatie met rich content en deep-linking is een eigen sub-project.
• Camera, scanner, sensoren: QR scannen is bijna gratis, productfoto's met machine learning-classificatie is een serieus traject.
• Integraties: elke externe API die u koppelt, kost ontwerp, bouw, foutafhandeling en monitoring. Lees wat een API-integratie precies inhoudt als u daar dieper op in wilt.
• Authenticatie: simpele e-mail + wachtwoord is goedkoop. Single sign-on met Microsoft, Google, Apple of een enterprise-IdP is een aanzienlijke uitbreiding.
• Locatie en maps: standaard kaartjes zijn betaalbaar; routing, geofencing en kaarten met veel custom layers worden snel duur — zowel in bouw als in maandelijkse map-tile-kosten.
• Backend-API's: als de app de schil is over een bestaand systeem dat al een goede API heeft, scheelt u veel werk. Moet er nieuwe backend-logica gebouwd worden, dan komt daar een heel apart project bij kijken.

Een nuttige vuistregel: streep elke feature waarvan u niet zeker weet dat 'm in versie één moet. Versie twee is een betere plek voor twijfelgevallen, als u 'm tenminste binnen handbereik houdt.

Verborgen kosten waar mensen op stuiten

De bouwkosten zijn vaak slechts de helft van het totale verhaal. Wat u na lancering blijft uitgeven aan een app, wordt structureel onderschat. De belangrijkste posten:

App-store accounts

Een Apple Developer Account kost jaarlijks een vast bedrag. Voor Google Play Developer betaalt u eenmalig een registratie. Klinkt klein, maar zonder die accounts gebeurt er niets — en bij Apple loopt het verlengingsproces meer dan eens stuk.

App Store review-proces

Elke release moet door Apple's review-team. Meestal binnen een paar dagen rond, soms wordt 'm geweigerd op grond van Apple's Human Interface Guidelines of regels rond payments. Dat is geen kosten-post in euro's, maar wel in doorlooptijd — en als uw release iets corrigeert dat live in productie kapot is, voelt elke dag wachten erg lang.

Releases per jaar

Een app die "af" is, bestaat niet. Iedere release kost ontwerp, bouw, testen en het hele review-proces opnieuw. Reken op een paar grotere releases per jaar plus losse fixes. Apps die nooit een update krijgen, vallen op den duur uit de markt — gebruikers zien dat aan de release-historie.

OS-updates en device-fragmentatie

Apple brengt elk najaar een nieuwe iOS uit; Android volgt eigen tempo. Soms breekt zo'n update iets in uw app. Het onderhouden van compatibiliteit met de laatste twee iOS- en Android-versies hoort bij doorlopend beheer. Op Android komt er bovendien de variatie aan toestellen, schermformaten en fabrikant-eigen rom-aanpassingen bovenop.

Security updates en library-onderhoud

Mobile apps gebruiken tientallen open-source libraries. Daar zit elke maand wel ergens een security-patch tussen. Wie ze niet bijhoudt, eindigt na een paar jaar met een app die alleen nog door iemand met heel veel geduld te updaten is.

Backend hosting en SaaS-licenties

Backend draait ergens — cloud-hosting kost maandelijks. Push providers, error tracking (Sentry of Bugsnag), analytics (Mixpanel of Amplitude), authenticatie (Auth0 of Cognito), maps (Mapbox of Google), e-mail (Postmark of SendGrid): elk van die diensten is op zich betaalbaar, maar het stapelt op.

App Store en Play Store-commissie

Als u in-app aankopen verkoopt, gaat 15-30% naar Apple of Google. Voor SaaS-businesses een serieuze post om in uw pricing-model door te rekenen.

MVP versus productie-app: de echte trade-off

Veel teams worstelen met de keuze tussen "snel iets in de markt" en "het meteen goed doen". Beide standpunten hebben recht van bestaan, maar de keuze heeft enorm impact op het budget en op het succes van het traject.

Een goede MVP is een product met net genoeg functionaliteit om het kern-hypothese te valideren. Het is geen demo, geen klikbaar prototype, maar ook geen productie-app. De waarde van een MVP zit in wat u leert: gaan echte gebruikers iets dat ze beloofd hebben ook werkelijk doen? Klopt het pricing-model? Waar haken mensen af? Dat soort vragen kunt u alleen beantwoorden met software die mensen kúnnen gebruiken.

Een productie-app heeft een ander doel: schaalbaar werken, voor lange tijd, in een markt die u al begrijpt. Hier moeten zaken als observability, automatische tests, foutafhandeling, releaseprocessen en compliance vanaf dag één goed staan. Een productie-app bouwen ter grootte van een MVP is duurder en levert minder op dan beide trajecten apart.

De gevaarlijke middenweg: een team dat een MVP belooft, maar in praktijk een productie-app bouwt zonder de bijbehorende kwaliteits-laag. Dat is het slechtste van twee werelden — duurder dan een echte MVP, fragieler dan een echte productie-app. Wij bespreken in de eerste sessie expliciet welke van de twee u nodig heeft, en sturen daarop.

Wat bepaalt het uurtarief van een mobile developer?

Een uurtarief zegt niet zoveel zolang u niet weet wat u ervoor krijgt. Drie factoren die het meest spelen:

• Seniority en ervaring: een senior iOS-engineer die honderden apps in de stores heeft staan, levert meer in minder tijd dan een junior die de leercurve nog moet maken. Het uurtarief verschilt aanzienlijk, maar het totaal-budget vaak minder dan u denkt — seniors maken minder rework.
• Specialisme: reguliere app-bouwers zijn schaarser dan webdevelopers en daardoor duurder. Hele niches (AR/VR, complexe Bluetooth/BLE, low-level audio-processing) hebben weer eigen tariefniveaus.
• Locatie en model: Nederlandse bureaus hebben hogere tarieven dan offshore-teams. De vraag is wat u terugkrijgt op communicatie, tijdzone, juridische verankering en kwaliteit — die afweging is per project anders.

Wij zijn een Nederlands ontwikkelpartner met een vast team en werken met sprint-budgetten. Daar zit een transparant uurtarief onder, maar u stuurt op sprint-output: aan het einde van elke sprint krijgt u werkende functionaliteit, niet een urendeclaratie. Voor grotere of bedrijfskritische trajecten kunt u ook onze pagina over enterprise software laten ontwikkelen bekijken.

En no-code platforms zoals FlutterFlow en Glide?

Een eerlijk verhaal: no-code en low-code mobile-platforms zoals FlutterFlow, Glide, Bubble (web) en Adalo zijn de afgelopen jaren een stuk volwassener geworden. Ze zijn een legitieme keuze in een aantal scenario's, maar absoluut niet voor alles.

Waar no-code goed werkt: proofs of concept, interne tools voor een handvol gebruikers, gestandaardiseerde flows (formulieren, dashboards, eenvoudige CRUD-apps), of het valideren van een idee voordat er ontwikkelbudget op losgelaten wordt. We hebben klanten gezien die met FlutterFlow in een paar weken een eerste interne tool op tafel hadden die anders maanden had gekost.

Waar no-code stuk loopt: als de app structureel onderdeel wordt van uw business, bij groeiende complexiteit, bij rigide compliance-eisen, bij grote gebruikersaantallen, bij behoefte aan rijke offline-mode, of bij integraties die buiten het standaard-aanbod van het platform vallen. Vendor lock-in is een serieus thema: u kunt vrijwel niet zonder pijn migreren naar een eigen codebase.

Onze nuchtere lijn: gebruik no-code voor wat het is — een snelle, betaalbare manier om iets in de markt te zetten en te leren. Maar maak vooraf de afspraak dat u, als de app aanslaat en serieus wordt, opnieuw fundering legt met echte software. Dat is geen falen, dat is een normale levenscyclus.

Veelgestelde vragen over de kosten van een app

Wat is goedkoper: native of cross-platform?

Cross-platform is in vrijwel alle scenario's goedkoper als u beide platforms wilt bedienen — u onderhoudt één codebase in plaats van twee. Native wint qua kosten alleen als u één platform exclusief targeted, of als uw app een diepe afhankelijkheid heeft van platform-specifieke features waar Flutter of React Native onvoldoende grip op hebben.

Moet ik beginnen met een MVP of meteen een productie-app bouwen?

Dat hangt af van hoe zeker u bent over uw hypothese. Weet u nog niet of mensen het gaan gebruiken, doe een MVP en accepteer dat 'm beperkt en ruw is. Heeft u al bewijs dat de behoefte bestaat — bijvoorbeeld omdat u nu al ad-hoc workarounds ziet — dan kunt u direct een afgeslankte productie-app overwegen. De gevaarlijke middenweg is een "MVP" bouwen alsof het productie is.

Hoe lang duurt het om een app te laten maken?

Voor een eenvoudige cross-platform app praten we over een paar sprints; een productie-app voor consumenten is een traject van meerdere sprints. Maar de doorlooptijd hangt minder van de techniek af dan van hoe scherp uw scope is en hoe snel u kunt beslissen tijdens het traject. Onze ervaring: trajecten lopen vaker uit door besluitvorming dan door bouwwerk.

Wat moet ik met de App Store en Google Play?

U heeft een Apple Developer Account en een Google Play Developer Account nodig — die opent u op uw eigen bedrijfsnaam, niet op die van uw bureau. Wij begeleiden de eerste publicatie inclusief het schrijven van store-listings, screenshots en het reviewproces, maar u blijft de juridische eigenaar van de apps in de stores. Belangrijk voor exit-scenario's.

Kunnen we updates blijven doen nadat de app live staat?

Ja, en dat raden we ook aan. Apps die maandenlang stilliggen, scoren slecht in de stores en verliezen gebruikers. Wij werken met doorlopende sprint-cycli waarin we functionaliteit toevoegen, security updates verwerken en de app aangepast houden aan nieuwe iOS- en Android-versies. U kunt dat ook intern oppakken zodra uw team de codebase doorgrondt — we documenteren en draaien graag overdrachtssessies.

Kunnen we met een no-code platform beginnen en later overstappen?

Technisch kan het, maar onderschat de migratie niet. No-code apps hebben hun eigen data-modellen, eigen flows en eigen plek waar de business-logic woont. Een echte herbouw is bijna altijd nodig — u neemt vooral de gevalideerde requirements mee, niet de code. Dat is op zich geen probleem, zolang u dat moment vooraf in uw planning bouwt.