App laten maken: wat kost het?

De kosten van een app laten maken hangen eerst af van het soort app dat je nodig hebt. Er zijn drie manieren om je dienst op een telefoon te krijgen, en ze verschillen in prijs, in wat ze kunnen en in hoeveel onderhoud ze vragen.

• Web-app of PWA (progressive web app): een website die zich gedraagt als een app. Hij draait in de browser op elk apparaat, kan op het beginscherm worden gezet en meldingen sturen, maar staat niet in de App Store of Google Play.
• Cross-platform app: één codebase, geschreven met een framework als Flutter, React Native of Kotlin Multiplatform, waaruit zowel een iPhone- als een Android-app komt.
• Native apps: een aparte app per platform, geschreven in Swift voor iPhone en in Kotlin, de taal die Google aanbeveelt, voor Android. De meest directe toegang tot de telefoon en tot nieuwe systeemfuncties op de dag dat ze verschijnen, met als prijs twee codebases.

Native is niet altijd beter, en cross-platform is niet altijd goedkoper. Cross-platform bespaart het meest als beide apps er hetzelfde uitzien en vooral bestaan uit schermen, formulieren en gegevens. Native loont als de app leunt op Bluetooth, locatie op de achtergrond, widgets, een horloge-app of vloeiende graphics, of als maar één platform er voor je klanten toe doet.

Een web-app kan ook de eerste stap zijn; onze gids over webapplicatie laten maken zet die route met prijzen op een rij. Je test het idee met echte gebruikers voor minder geld, en als de stores of de hardware nodig worden, gaan de backend en het ontwerp mee. Een website in een dun app-jasje is overigens geen kortere weg: volgens de richtlijnen van Apple wordt een app geweigerd die weinig meer is dan een verpakte website.

Twee apps met evenveel schermen kunnen in prijs een veelvoud van elkaar zijn. Het verschil zit in wat er achter de schermen gebeurt: wie er inlogt, welke gegevens waarheen gaan, en met welke andere systemen de app praat.

1. 1

   Schermen en flows

   Elk scherm wordt ontworpen, gebouwd en getest op kleine en grote telefoons. Een flow zoals aanmelden, afrekenen of reserveren loopt over meerdere schermen en moet elke fout onderweg opvangen.

2. 2

   Accounts en rollen

   Inloggen betekent wachtwoorden herstellen, e-mailadressen controleren en, in de App Store, een manier om het account in de app te verwijderen. Elke extra rol, zoals klant, medewerker of beheerder, brengt eigen schermen en regels mee.

3. 3

   Gegevens en een backend

   Zodra gegevens moeten synchroniseren tussen apparaten of gebruikers, heeft de app een server nodig met een database en een koppelvlak dat de app aanroept. Dat is vaak de helft van het werk. Een app met alleen content heeft veel minder nodig.

4. 4

   Betalingen

   Fysieke producten en diensten reken je af via een betaalprovider zoals Mollie of Stripe. Digitale content die je in de app verkoopt, loopt meestal via de eigen betaalsystemen van Apple en Google, met hun commissie.

5. 5

   Koppelingen

   Verbindingen met je reserveringssysteem, CRM, boekhoudpakket of de API van een andere leverancier. Elke koppeling kost meer als de documentatie mager is of er geen testomgeving is.

6. 6

   Beheeromgeving en ontwerpdiepte

   Iemand moet content, gebruikers en bestellingen beheren, meestal in een webdashboard. En een eigen ontwerp met eigen animaties kost meer dan een strak ontwerp op de standaardonderdelen van elk platform.

De goedkoopste functie is de functie die je uit de eerste versie laat. Alles hierboven kan later worden toegevoegd, en een app die klein begint, leert van echte gebruikers voordat je aan de rest geld uitgeeft.

Dit zijn onze richtprijzen voor een eerste versie op iPhone en Android, exclusief btw. Je offerte is een vaste prijs voor een afgesproken omvang, dus de bandbreedte wordt één bedrag voordat er gewerkt wordt.

Ter vergelijking: dit publiceren vier andere bureaus in Nederland en Duitsland. Hun bedragen liggen in elke categorie hoger dan de onze. Ook de definities verschillen: sommigen rekenen een gebruikersrol of een koppeling tot een eenvoudige app, en die valt bij ons in de tweede categorie.

Welke offertes je ook vergelijkt, kijk bij elke offerte of de backend, de beheeromgeving, testen op echte toestellen en de keuring door de stores erin zitten voordat je totalen vergelijkt. Twijfel je tussen een app en online verkopen? Onze gids over wat een webshop kost zet dezelfde cijfers op een rij voor een webwinkel.

Een app in de stores zetten kost weinig: het ontwikkelaarsprogramma van Apple kost 99 dollar per jaar, afgerekend in lokale valuta, en Google Play vraagt eenmalig 25 dollar. De echte vaste lasten zitten ergens anders. Een app hangt af van twee besturingssystemen die elk jaar veranderen, en van een backend die online en veilig moet blijven.

Onderhoud is de post die mensen vergeten. Sinds 28 april 2026 accepteert Apple alleen app-updates die met de tools van iOS 26 zijn gebouwd, en sinds 31 augustus 2026 eist Google Play dat nieuwe apps en updates Android 16 als doel hebben. Elk jaar komen er zulke deadlines bij, dus een app die niemand onderhoudt, kan zelfs geen kleine fix meer uitbrengen, en in Google Play bereikt hij steeds minder nieuwe gebruikers op nieuwere telefoons.

In deze voorbeelden komt er door drie jaar vaste lasten 70 tot 90% bij de bouwprijs bij. Reken ze vanaf het begin mee, en vraag elk bureau wat het onderhoud dekt en per jaar kost. Voor websites werkt het net zo; onze gids over de kosten van websiteonderhoud zet die post voor post op een rij.

Tools als Lovable en Bolt bouwen in een paar minuten een werkende app uit een geschreven beschrijving, voor een maandabonnement. Dat is een echte verandering, en voor sommige klussen zijn ze de juiste keuze.

Ze zijn goed in de eerste stap: een klikbaar prototype om een idee bij klanten te testen, een demo voor investeerders, of een kleine interne tool voor een paar collega's. Een werkend prototype maakt elke latere offerte ook nauwkeuriger, omdat iedereen naar hetzelfde kijkt.

Ze houden op waar een app een bedrijfssysteem wordt:

• Beveiliging. De tool schrijft de code, maar niemand controleert hem. In 2025 werd een lek vastgelegd (CVE-2025-48757) waarbij zwakke toegangsregels in de database buitenstaanders gegevens lieten lezen en wijzigen in apps die met Lovable waren gebouwd. Lovable betwist dat en zegt dat elke klant zelf verantwoordelijk is voor de gegevens in zijn app, en dat is precies het punt.
• Apps in de stores. Lovable bouwt alleen web-apps. Bolt kan via Expo code voor een mobiele app maken, maar accounts bij de stores, ondertekening, keuring en privacylabels blijven jouw werk.
• Eigendom van gegevens. De code kun je meestal exporteren, maar controleer waar de database draait, of je hem kunt verhuizen, en wat er met je gegevens gebeurt als je stopt met betalen.
• Onderhoud. Een app die met prompts is gebouwd, heeft nog steeds de jaarlijkse updates voor iOS en Android nodig. Wijzigingen via prompts in een grote codebase breken vaak andere onderdelen, en iemand moet de code begrijpen om dat te herstellen.

Een verstandige route voor veel bedrijven: maak een prototype met een AI-bouwer, test het met echte gebruikers, en laat daarna de versie waarmee je live gaat goed bouwen, met het prototype als specificatie. Bij een studio betaal je niet voor het typen. Je betaalt voor de ontwerpkeuzes, de controle, het testen en iemand die opneemt als er iets stukgaat.

Hoe preciezer je vraag, hoe scherper de offerte. Je hebt geen technische specificatie nodig. Je moet weten wie de app gebruikt en wat die mensen ermee moeten kunnen.

1. 1

   Beschrijf de gebruikers

   Klanten, medewerkers of allebei? Welke telefoons hebben ze, en hoe vinden ze je nu?

2. 2

   Schrijf user stories

   Eén zin per taak: "Als klant wil ik mijn afspraak verzetten, zodat ik niet hoef te bellen." Tien tot dertig van zulke zinnen beschrijven de meeste eerste versies.

3. 3

   Scheid must-haves van nice-to-haves

   Markeer wat de eerste versie niet kan missen. De rest gaat op een lijst voor versie twee.

4. 4

   Verzamel voorbeelden

   Schermafbeeldingen van apps die je goed vindt, en van wat je eraan ergert. Voorbeelden beslechten ontwerpvragen sneller dan beschrijvingen.

5. 5

   Zet je systemen op een rij

   Reserveringssoftware, webshop, CRM, boekhouding: alles waar de app mee moet praten, met een contactpersoon bij elke leverancier.

6. 6

   Noem de deadline en het budget

   Een beurs, een seizoen of een financieringsronde. Met een budgetindicatie kan een studio voorstellen wat past in plaats van te gokken.

Vraag daarmee elke studio om een vaste prijs voor dezelfde omvang, en vergelijk wat erin zit: ontwerp, backend, beheeromgeving, testen op echte toestellen, indienen bij de stores en ondersteuning na de lancering. Op onze prijzenpagina zie je hoe we vaste prijzen opbouwen, en bij Web- & appontwikkeling zie je wat we bouwen. Vraag ook van wie de code wordt: bij ons is die van jou zodra de facturen betaald zijn, zoals vastgelegd onder eigendom in onze voorwaarden.

Wil je dat iemand met je meekijkt? Beschrijf je app-idee, dan helpen we je de omvang scherp te krijgen en sturen we een vaste prijs en een planning.