Hieronder leggen we uit welke kosten voor het maken van een app er zijn, hoe we ze berekenen en waar je zelf op kunt sturen. Gemiddelden zeggen weinig over een specifiek project, maar een indicatie per type app geeft wel een beeld van wat je kunt verwachten bij app ontwikkeling.
Externe koppelingen
Functionaliteit en externe koppelingen werken door in de prijs: hoe meer er gebouwd moet worden, hoe duurder het wordt. Elke koppeling met een extern systeem moet worden ontworpen (dus, is er goede API-documentatie?) gebouwd, getest en gedocumenteerd.
Complexe functionaliteiten
Ook de complexiteit van de functionaliteit telt. Een app met lijsten en formulieren is aanzienlijk eenvoudiger dan een app met real-time communicatie, betalingen of een koppeling met hardware via Bluetooth. Hetzelfde geldt voor automatisering: worden bepaalde stappen handmatig door de beheerder uitgevoerd, dan is dat vaak budgetvriendelijker dan alles automatiseren, zeker in een eerste versie.
Doorlooptijd
De doorlooptijd speelt een kleinere maar niet te onderschatten rol. Hoe sneller de app klaar moet zijn, hoe duurder het traject, omdat er dan meer mensen tegelijk aan het project moeten werken. Tegelijkertijd creëert een groter team een grotere overhead, hoe meer developers er tegelijk aan een project werken, hoe meer communicatie er vereist is.
Wensen ná oplevering
Bij veel projecten wordt er volgens de MVP (Minimum Viable Product) gedachte gewerkt, waardoor het vanzelfsprekend is dat er nog veel wensen overblijven om door te ontwikkelen ná deze fase. Daarnaast zijn er na nog kosten voor beheer, ondersteuning en onderhoud; daar komen we verder op deze pagina op terug.
Wet- en regelgeving
Bij elke app houden we rekening met de AVG en de cookieregels uit de Telecommunicatiewet en andere gangbare wetten en regels. Voor sommige apps geldt strengere regelgeving en die werkt door in de kosten.
Twee veelvoorkomende voorbeelden. Apps voor consumenten, zoals webshops, bankieren en vervoer, moeten sinds juni 2025 voldoen aan de European Accessibility Act. Voor de overheid gold die toegankelijkheidseis al. En een app die medische gegevens verwerkt, zeker als daar adviezen of diagnoses aan hangen, valt al snel onder de Medical Device Regulation en moet dan als medisch hulpmiddel gecertificeerd worden. Beide vragen extra ontwerp-, bouw- en testwerk van ons en extra verantwoordelijkheid van jou als uitgever.
Eenvoudige app / MVP
Een eerste versie met basisfunctionaliteit voor een snelle eerste release, waarmee van echte gebruikers geleerd kan worden. Het gaat om één duidelijke use-case, een beperkt aantal schermen en weinig of geen koppelingen.
Budgetrange: €20.000 – €35.000
Gemiddeld complexe app
Een maatwerk app met beheeromgeving en koppeling met een extern systeem, zoals een CRM, ERP of betaalprovider via bestaande API's.
Budgetrange: €35.000 – €75.000
Complex maatwerk platform
Een platform met geavanceerde functionaliteit, een uitgebreide backend en bijvoorbeeld AI-integraties.
Budgetrange: €75.000 – €100.000+
Ondersteunde platformen
Ter illustratie: alleen een Android app laten maken kost minder dan een app die ook op iOS devices moet werken. Voor beide platformen zijn er grofweg twee routes: twee losse Native apps of één Flutter-app.
Native apps
Bij Native app ontwikkeling bouwt een native app ontwikkelaar voor iOS en Android elk een eigen app, met de tools van Apple en Google zelf. Dat geeft maximale controle over hardware, prestaties en nieuwe functies van het besturingssysteem. Qua kosten rekenen we dan ongeveer twee keer de kosten van één app platform.
Flutter apps
Een Flutter app ontwikkelaar bouwt één codebase die op beide platformen draait. Qua kosten rekenen we dan ongeveer een derde (33%) extra bovenop één platform. Dat scheelt aanzienlijk in de kosten maar het hangt af van de functionaliteit of Flutter development veel tijd scheelt. Cross-platform ontwikkeling lost niet alles op: bij complexe hardwarekoppelingen, zoals Bluetooth, kan alsnog veel platformspecifiek werk nodig zijn waardoor soms een Native app logischer is. Het blijft dus een afweging tussen het beschikbare budget en wat de app technisch moet kunnen.
App ontwikkeling is als het bouwen van een huis
We vergelijken app ontwikkeling wel eens met het laten bouwen van een huis. Ook daar hangt veel af van grote vraagstukken: waar komt het huis te staan, welk fundament is er nodig en aan welke eisen moet het voldoen? Maar ook de details zijn cruciaal: hoeveel kozijnen, welke deurklinken, en waar komen de lichtpunten en stopcontacten?
Voor apps geldt hetzelfde. Waar een architect en een aannemer samen met de opdrachtgever bouwtekeningen maken, stellen wij gezamenlijk de specificaties en randvoorwaarden van de app op. Hoe meer we weten over de randvoorwaarden, het doel, de gebruikers, de systemen waarmee gekoppeld moet worden en de bestaande ontwerpen of specificaties, hoe gerichter we een inschatting kunnen geven.
Waterval of agile: vaste prijs of flexibele scope?
Bij waterval ontwikkeling leggen we alle specificaties vast voordat we gaan ontwikkelen. Dat geeft vooraf een helder budget, maar wijzigingen halverwege zijn soms complexer en aannames kunnen pas achteraf worden gevalideerd. Bij agile ontwikkeling werken we in iteraties naar een eindproduct en wordt er na iedere stap bepaald wat de volgende stap wordt. Dat is flexibeler, maar er is minder duidelijkheid over het exacte eindresultaat en het eindbedrag. Dat kan betekenen dat de app nog niet naar verwachting is, terwijl het budget verbruikt is.
Welke aanpak goed past hangt vooral af van hoe concreet de plannen momenteel zijn.
Aandachtspunt bij de keuze voor een app bureau
Let bij de bureaukeuze op wat er uiteindelijk aangeboden wordt: wordt er een fixed-price budget neergelegd met een bijbehorende scope (waterval)? Of zit er flexibiliteit in de scope of kosten (agile).
Design sprint
Heb je wel een visie voor de app maar op functioneel niveau nog geen idee wat de app exact moet kunnen? Of heb je juist moeite met het concreet maken van de specificaties? In die gevallen stellen we vaak een design sprint voor, een goede tussenoptie om tot concrete specificaties te kunnen komen. We starten in een kort en betaald traject gezamenlijk met de uitwerking van functionaliteit en het ontwerp, zodat de daaropvolgende app ontwikkeling concreet in te schatten is.
Voorafgaand aan de design sprint bepalen we met elkaar een realistisch budget voor ontwikkeling, zodat we gedurende de design sprint kunnen sturen op dit budget. App developers en app designers zullen dan ook aangeven wanneer bepaalde functionaliteit wel / niet mogelijk is binnen de kaders en vervolgens meedenken over eventuele alternatieven. Na de design sprint (en concrete begroting) kunnen we bepalen om het ontwikkeltraject voort te zetten als waterval of meer agile.
Verschillende werkzaamheden
Een ontwikkelproces bestaat uit veel verschillende taken, ook veel taken die weinig met de daadwerkelijke app development te maken hebben. Iedere taak begroten we los en tezamen vormen ze de offerte.
Onderdelen die terugkomen in offertes
Het start met UX/UI design: hoe de app eruitziet en werkt. Daarna volgt de development, die uit meerdere onderdelen kan bestaan. Denk aan: de backend (inclusief API), de frontends (zoals een content management systeem en een bijbehorende website).
Vervolgens uiteraard de app zelf, een iOS app, Android app en soms een webapp. Daarnaast begroten we project management, testen en QA (quality assurance), en tot slot de oplevering en nazorg (hypercare) voor de periode ná de livegang, om alles goed te begeleiden
Hoeveel van deze onderdelen nodig zijn, verschilt per project. Een app zonder CMS of website is logischerwijs goedkoper dan een app met beide.
Gefaseerd ontwikkelen
Een goede eerste stap is een kleine eerste versie met alleen de kernfunctionaliteit. Daarmee komt de app sneller bij echte gebruikers en kan daarna worden bepaald wat de moeite waard is om bij te bouwen. Nice-to-haves schuiven we daarom bewust door naar een latere fase.
Een goede voorbereiding is het halve werk
Ook een goede voorbereiding scheelt. Hoe concreter de wensen, de ontwerpen en de API-documentatie van eventuele koppelingen, hoe minder tijd er gaat naar uitzoeken en bijsturen. Zijn de wensen nog niet concreet, dan kan een design sprint helpen om gericht te kiezen wat er gebouwd wordt.
Automatiseren of niet?
Ook de keuze voor de ondersteunde platforms en mate van automatisering helpt. Starten met één platform is goedkoper dan beide tegelijk, en handmatige beheerstappen zijn in een eerste versie vaak voordeliger dan alles automatiseren.
Wil je een gerichte prijsopgave?
Van webapplicaties tot mobile apps, alle software ontwikkelen we op maat.
Vertel ons over het doel van de app, of er al ontwerpen en/of specificaties zijn en wat de app precies moet kunnen. Hoe meer we weten, hoe gerichter we een inschatting kunnen geven.
Kennis maken?
