Wie vraagt wat een app laten maken kost, krijgt antwoorden die uiteenlopen van een paar duizend tot een paar ton. Beide kunnen kloppen: de prijs van een app is uren × uurtarief, en die uren worden vooral bepaald door één keuze die veel ondernemers overslaan — het type app. Dit artikel is voor mkb-ondernemers die een app overwegen en legt uit waar het geld precies in gaat zitten, welke vaste kosten elke app heeft en hoe je offertes eerlijk naast elkaar legt.
De prijs van een app = uren × uurtarief. De uren worden bepaald door:
- Type app: web-app (voordeligst), cross-platform of native (duurst)
- Schermen en functies: elk scherm is ontwerp-, bouw- en testwerk
- Gebruikers en rollen: inloggen, rechten en beheer
- Koppelingen: boekhouding, betalingen, CRM of eigen systemen
- Beheer: heb je een beheeromgeving en rapportages nodig?
Begin met een MVP (de kernfunctie, niets meer) en vraag een vaste totaalprijs vooraf. Studio's die met AI bouwen leveren een eerste werkende versie meestal binnen twee weken op.
Web-app, cross-platform of native: de keuze die de prijs bepaalt
Een "app" kan drie technisch verschillende dingen zijn, en het verschil in bouwwerk is groot. Een web-app draait in de browser en werkt daarmee op elk apparaat met één codebase. Een cross-platform app (gebouwd met bijvoorbeeld Flutter of React Native) heeft ook één codebase, maar wordt wél als echte app geïnstalleerd via de App Store en Google Play. Een native app wordt per platform apart gebouwd: Swift voor iOS en Kotlin voor Android — twee codebases, dus bijna dubbel bouwwerk.
| Type app | Codebases | In de app-stores? | Wanneer logisch |
|---|---|---|---|
| Web-app / PWA | 1 | Nee (werkt via de browser) | Interne tools, portalen, dashboards, MVP's |
| Cross-platform (Flutter, React Native) | 1 | Ja | Consumentenapps die in de stores moeten staan |
| Native (Swift + Kotlin) | 2 | Ja | Intensieve hardware-toegang, maximale prestaties |
Voor de meeste mkb-toepassingen — een klantportaal, een planningstool, een bestelapp voor vaste klanten — is een web-app de nuchtere keuze: één codebase, geen reviewprocedure van Apple of Google, en elke update staat direct bij al je gebruikers. Native wordt pas logisch als je diepe hardware-toegang nodig hebt of als vindbaarheid in de app-stores een commercieel doel op zich is.
De vijf factoren die de uren bepalen
Binnen het gekozen type app maken vijf factoren het verschil tussen een lage en een hoge offerte:
- Aantal schermen en functies. Elk scherm is ontwerp-, bouw- en testwerk. Een app met 5 schermen is wezenlijk ander werk dan een app met 25 schermen. Maak vooraf een lijst en streep alles weg wat niet in versie één hoeft.
- Gebruikers, rollen en inloggen. Eén type gebruiker is overzichtelijk. Klanten, medewerkers en beheerders met elk eigen rechten betekent extra schermen, extra logica en extra testwerk.
- Koppelingen. Moet de app praten met je boekhouding (Exact), betalingen (Mollie), CRM (HubSpot) of een eigen systeem? Elke koppeling is werk, maar bespaart daarna structureel handwerk.
- Design. Een strak, functioneel ontwerp op basis van bewezen patronen is sneller gebouwd dan een volledig eigen visuele identiteit met animaties en illustraties.
- Beheer en rapportage. Gebruikers zien de app; jij wilt erachter kunnen kijken. Een beheeromgeving met statistieken en exportmogelijkheden is in feite een tweede, kleinere app.
De vaste kosten die elke app heeft
Naast het bouwwerk zijn er kosten die je niet kunt wegonderhandelen. Ze zijn klein vergeleken met de bouw, maar hoor je vooraf te kennen:
- Apple Developer Program: 99 dollar per jaar om apps in de App Store te mogen publiceren (developer.apple.com).
- Google Play Console: eenmalig 25 dollar registratiekosten (play.google.com).
- Store-commissie: verkoop je digitale diensten ín de app, dan rekenen Apple en Google 15 tot 30% commissie over die omzet.
- Hosting en database: de server waar je app op draait, maandelijks afgerekend naar gebruik.
Kies je voor een web-app, dan vervallen de eerste drie posten volledig — nog een reden waarom dat voor veel mkb-toepassingen de voordeligste route is.
Begin met een MVP: de grootste besparing die er is
Een MVP (minimum viable product) is de kleinste versie van je app die het kernprobleem oplost: één doelgroep, één hoofdfunctie, niets erbij. Alles wat je daarna toevoegt, bouw je op basis van feedback van echte gebruikers in plaats van aannames.
De klassieke fout is een jaar bouwen aan alle denkbare functies en er daarna achter komen dat gebruikers iets anders willen. Wie klein begint, betaalt alleen voor wat bewezen nodig is — en heeft binnen weken iets in handen om mee te testen. Hoe dat traject eruitziet lees je op de pagina app laten maken.
Kosten ná de lancering
Een app is geen eenmalige aankoop. Reken na de livegang op drie terugkerende posten: hosting en database (maandelijks), de developer-accounts als je in de stores staat (jaarlijks), en onderhoud — updates van onderliggende software, back-ups, monitoring en kleine verbeteringen. Veel ondernemers regelen dat met een onderhoudscontract, zodat er één partij verantwoordelijk is.
Het belangrijkste is niet hóé je het regelt, maar dát het vooraf op papier staat: welke lopende kosten zijn er, wat wordt daarvoor gedaan, en wat kost een extra wens later?
Waarom bouwen met AI de rekensom verandert
Omdat de prijs van een app vooral uit uren bestaat, verandert alles wat de uren verkort ook de prijs. Studio's die met AI bouwen — zoals VibeCodex met Claude Code als bouwpartner — doen het bouwwerk drie tot vijf keer sneller dan traditionele bureaus: de AI schrijft de code, de developer stuurt bij en bewaakt de kwaliteit. Een eerste werkende versie staat daardoor meestal binnen twee weken, waar hetzelfde traject traditioneel drie tot zes maanden kost.
Sneller is hier niet hetzelfde als slordiger: het traject is gelijk (ontwerp, bouw, test, livegang), alleen het handwerk is korter. Wil je zien wat dat in de praktijk oplevert, bekijk dan het portfolio — bijvoorbeeld het dealerportaal voor Protektis. En werkt je toekomstige app vooral als bedrijfssysteem met klantenlogin, lees dan ook het artikel over maatwerk software versus standaard software.
Checklist: zo vergelijk je offertes voor een app
Leg offertes naast elkaar op deze zes punten, niet alleen op het eindbedrag:
- Is het een vaste totaalprijs, inclusief testen, bugfixes en livegang?
- Welk type app wordt er gebouwd (web-app, cross-platform of native) en waarom?
- Van wie is de broncode na oplevering?
- Wat zit er in versie één, en wat is bewust doorgeschoven?
- Wat zijn de lopende kosten per maand en per jaar, uitgesplitst?
- Hoe snel staat de eerste werkende versie live, en zie je tussentijds mee?
Wil je weten hoe zo'n traject stap voor stap verloopt? Bekijk de werkwijze van VibeCodex: binnen een dag een plan met vaste prijs en tijdlijn.
Veelgestelde vragen over de kosten van een app
Weten wat jouw app zou kosten?
Leg je idee voor in een vrijblijvend gesprek. Je hoort eerlijk wat de kern van je idee is, wat het kost en hoe snel het live kan staan — binnen een dag een offerte met vaste prijs.
Leg je app-idee voor