App laten maken kosten in 2026: prijzen, factoren en voorbeelden

De app laten maken kosten liggen in 2026 voor een eerste werkende versie meestal tussen de 10.000 en 40.000 euro, en de doorlooptijd van zo’n MVP is 4 tot 16 weken. Waar je precies in die range valt, hangt af van vijf dingen: het type app, de complexiteit, het design, de backend en wie er bouwt. Gaat het om een ERP-achtig platform met meerdere integraties, dan praat je over 75.000 tot 150.000 euro of meer.

We krijgen deze vraag bijna elke week. Niet zo gek, want online vind je prijzen van 3.000 tot een half miljoen, en dat helpt je geen stap verder. Hieronder lees je wat wij in onze eigen MKB-projecten zien, welke keuzes het meeste invloed hebben op je budget, en wanneer een app laten maken eigenlijk niet de slimste beslissing is.

Zoek je geen prijzen maar wil je weten hoe wij werken? Dan is onze pagina over app laten maken het betere startpunt.

App laten maken kosten in 2026: de snelle indicatie

Een kleine interne tool of medewerkersportaal bouwen we tussen de 10.000 en 20.000 euro. Een klant- of leveranciersportaal zit tussen de 20.000 en 75.000 euro. Een native app kost 20.000 tot 40.000 euro per platform, dus reken bij iOS én Android op twee keer dat bouwwerk. Hieronder staan de ranges waar wij zelf mee werken, per producttype.

Wij werken met vaste prijzen per onderdeel in plaats van uurtjes, zodat je vooraf weet waar je aan toe bent. Waar je op moet letten: bij lage prijzen sneuvelt meestal het ontwerp, het testwerk of de beveiliging. Dat merk je pas na drie maanden, en dan ben je het dubbele kwijt om het recht te trekken.

Wil je snel een richtbedrag voor jouw idee? Dat kan met onze app kosten calculator, in een paar minuten.

De vijf factoren die je prijs bepalen

Type app, complexiteit, design, backend en de partij die bouwt bepalen samen bijna je hele budget. Iedereen die zegt dat een app “gewoon een vaste prijs” heeft, verkoopt je een standaardoplossing. Een app die past bij jouw bedrijf vraagt maatwerk, en het budget volgt uit de keuzes die je onderweg maakt.

Factor 1: Type app

Je keuze tussen native, hybride of een progressive web app is de eerste knop die je omzet. Native apps gebruiken de volledige hardware van het toestel, zoals de camera, GPS of NFC-chip. Web apps draaien in de browser en hoeven niet door de appstore, wat enorm scheelt in releasesnelheid. Een progressive web app zit daartussenin en is vaak interessant voor MKB-budgetten die op twee platformen tegelijk live willen.

Ons omslagpunt is concreet. Zodra de app iets met de hardware moet doen dat verder gaat dan camera en GPS, gaan we native. Denk aan NFC, bluetooth, achtergrondprocessen, sensoren uitlezen, of een video- en audiolaag die echt moet blijven staan. Zit je daar niet, en gaat het vooral om schermen, formulieren en data uit een backend, dan is Flutter, het cross-platform framework van Google, meestal de snellere en goedkopere route.

Het tweede omslagpunt is levensduur. Een app waar we jaren op blijven doorbouwen en waar platformgedrag telt, wil je native. Een app die vooral snel in de markt moet, niet. En dan de mening die we hardop uitspreken: wij geloven niet in “native first” als principe. Wij bouwen beide, met Swift en Kotlin voor native en Flutter voor cross-platform, en kiezen per geval. Wat vaak fout gaat, is dat die keuze op gevoel valt in plaats van op wat de app technisch echt moet kunnen.

Een voorbeeld uit onze eigen praktijk. Voor CLS LED hebben we bewust native gekozen, omdat technici via een NFC-tap LED-armaturen configureren en sensordata uitlezen, offline en zonder server. Dat bouw je niet handig met een extra laag tussen je code en het toestel. Voor een doorsnee MKB-app met schermen, formulieren en een API-koppeling wint hybride juist op snelheid en onderhoudskosten, omdat je één codebase onderhoudt voor beide platformen.

Factor 2: Complexiteit en functies

Een menukaart-app en een logistiek dashboard met realtime tracking zijn technisch twee verschillende werelden. Hoe meer schermen, gebruikersrollen, rekenlogica en live data je app nodig heeft, hoe meer ontwikkeltijd erin gaat zitten. We zien vaak dat klanten onderschatten hoe duur een “kleine” feature als notificaties of een betaalmodule is. Notificaties zijn namelijk niet één schermpje, maar backend-werk, testen op beide platformen en omgaan met randgevallen.

De truc is klein beginnen. Een MVP die één probleem echt oplost, kost een fractie van een volwaardige app en leert je binnen 8 tot 16 weken wat gebruikers werkelijk doen. Lees onze uitleg over wat een MVP precies is als je daar nog niet scherp in zit.

Factor 3: Design en maatwerk

Een los designtraject kost 4.000 tot 12.000 euro, inclusief wireframes en interactieve prototypes. Design is geen cosmetica, het is het verschil tussen een app die dagelijks gebruikt wordt en eentje die na twee weken in de map “overige” belandt. Wat je betaalt hangt af van het aantal schermen, het aantal iteraties, en of je een bestaande huisstijl hebt of vanaf nul begint.

Daar hoort een UX-check bij, want een mooi scherm dat gebruikers niet begrijpen is weggegooid geld. Hoe wij dat aanpakken lees je op onze pagina over UX/UI design, en het verschil tussen die twee begrippen leggen we uit in UI en UX design.

Factor 4: Backend, koppelingen en hosting

Een losse backend kost 4.000 tot 15.000 euro, afhankelijk van het aantal koppelingen. De backend is het deel dat je niet ziet maar dat alles laat werken: database, API’s, authenticatie en de verbindingen met systemen die je al gebruikt, zoals Exact of je eigen ERP. Eén database zonder externe koppelingen zit aan de onderkant van die range, realtime data-uitwisseling met vijf systemen aan de bovenkant.

Vergeet de hosting niet. Een MKB-app draait bij ons meestal op Microsoft Azure en kost in de praktijk 100 tot 400 euro per maand, afhankelijk van gebruikers en datavolume. Dat lijkt weinig, maar het is een doorlopende post in je businesscase.

Factor 5: Wie je inschakelt

Je kunt kiezen tussen een Nederlands bureau, een freelancer of een offshore team. De goedkoopste optie is zelden de goedkoopste op lange termijn. Bij freelancers betaal je minder, maar draag je zelf het projectrisico en de continuïteit. Offshore kan flink schelen in prijs, maar je betaalt dat terug in communicatietijd, tijdzoneverschillen en extra kwaliteitscontroles.

Wij horen regelmatig van bedrijven die eerst hebben uitbesteed aan een team op afstand en er duurder mee uitkwamen. Niet omdat die ontwikkelaars slecht zijn, maar omdat je op afstand minder grip hebt op kwaliteit, architectuurkeuzes en voortgang. Wat je normaal op een vrijdagmiddag even uitpraat, wordt dan twee weken vertraging en een vervelende factuur.

Prijsvoorbeelden: drie projecttypes waar we vaak mee werken

We noemen hier bewust geen klantbedragen, want offertes blijven tussen ons en onze klanten. Wat we wél delen zijn drie projectprofielen die we regelmatig bouwen, met de bijbehorende range. Zo krijg je een gevoel voor waar jouw idee in valt.

Profiel 1: interne tool of productiviteits-app (10.000 tot 20.000 euro)

Vijf tot acht schermen, één koppeling met een extern systeem en login voor gebruikers. Denk aan een interne tool voor medewerkers, een formulier-app voor de buitendienst of een eenvoudige klantapp om statussen te volgen. Meestal hybride gebouwd, zonder ingewikkelde hardware-integraties. Doorlooptijd: 8 tot 16 weken, zoals bij elk MVP-traject dat we doen.

Profiel 2: bedrijfsapp of portaal met eigen backend (20.000 tot 75.000 euro)

Meerdere gebruikersrollen, een eigen backend en koppelingen met bestaande systemen zoals een ERP of CRM. Rechten, beveiliging en data-consistentie spelen hier een grote rol, en dat vertaalt zich in meer design- en ontwikkeltijd.

Een concreet voorbeeld. Voor Met WA Beveiliging bouwden we een leveranciersportaal waar leveranciers hun medewerkersdocumenten uploaden, certificaten vernieuwen en hun compliance-score bijhouden, met automatische alerts bij documenten die binnen 90 dagen verlopen en een directe AFAS-koppeling. Eindeloos e-mailverkeer met gevoelige documenten? Verleden tijd.

Dit is het dashboard uit de case van Met WA: zo ziet een portaal in deze prijsklasse er in de praktijk uit.

Profiel 3: hardware-gedreven native app (20.000 tot 40.000 euro per platform)

Een app die direct met fysieke apparaten praat, via NFC, bluetooth of sensoren. Hier bouw je native, en reken je per platform: iOS en Android zijn elk hun eigen bouwwerk, met eigen code en eigen testronde. Wil je beide, dan zijn het dus twee trajecten naast elkaar. Het verschil met een gewone native app zit bij ons vooral in het testen op echte apparatuur, niet in een hogere basisprijs.

Onze samenwerking met CLS LED valt in dit profiel: technici configureren daar armaturen die eerder uren kostten, nu in minuten.

Wat deze drie profielen laten zien: de prijs is altijd terug te leiden naar scope en complexiteit. Als wij een offerte maken, breken we het project op in blokken met elk hun eigen prijs, zodat je kunt kiezen wat je nu doet en wat later komt.

Wat je NA de lancering betaalt

Reken op 15 tot 20 procent van je bouwbudget per jaar aan onderhoud: monitoring, kleine updates en releases. Daar bovenop komt de hosting van 100 tot 400 euro per maand. Een app is niet klaar als hij in de store staat, hij begint dan pas.

Wat we zien bij klanten die onderhoud overslaan is steeds hetzelfde patroon. Na een jaar of anderhalf loopt de codebase zo ver achter dat Apple of Google geen nieuwe releases meer accepteert, tenzij de app eerst naar de actuele SDK-versies wordt getrokken. Dan is de keuze: een inhaaltraject inkopen, of de app laten sterven.

Dat hebben we bijvoorbeeld opgepakt voor Gifwijzer, een informatieplatform over giftige stoffen voor huisdieren. Die app was eerder elders gebouwd en kreeg al een tijd geen updates, terwijl er wél nieuwe content nodig was. Wij zijn ingestapt, hebben de codebase weer actueel gemaakt en draaien sindsdien het onderhoud. Zo’n overname kost altijd meer dan consistent onderhoud, alleen al omdat wij ons eerst moeten inlezen in het werk van een ander.

Onderhoud is meer dan brandjes blussen. Apple en Google brengen jaarlijks updates uit die je app kunnen breken, gebruikers ontdekken bugs die jij nooit had bedacht, en je Apple Developer Program moet actief blijven (99 dollar per jaar). Plan dat budget in vanaf het begin, niet achteraf.

Hoe je voorkomt dat het project ontspoort

Scope-uitloop ontstaat bijna altijd door een te vage intake vooraf. Een project start op 40.000 euro en eindigt op 70.000, omdat niemand aan het begin streng genoeg was. Als je intake oppervlakkig is, krijg je een offerte die veel laat openstaan, en elke vraag onderweg kost extra. Een stevige product discovery is meestal de goedkoopste uitgave van het hele traject.

Ons advies: werk in vaste blokken, lever per blok op, en neem na elke oplevering een beslismoment of je doorgaat. Vraag je bureau om transparante facturatie en scope-documentatie, zodat je op elk moment weet wat er gebeurt. Zie ook hoe lang het duurt om een app te ontwikkelen voor een realistisch tijdpad.

En eerlijk: soms is een app niet de slimste keuze, en dan zeggen we dat ook. Een eigen app is pas interessant als je idee app-specifieke eisen heeft, zoals offline werken, push-notificaties, camera, GPS, NFC of een hardwarekoppeling. Heb je die niet, dan is een web app of progressive web app goedkoper, sneller live en simpeler in onderhoud. Een extra icoontje op het beginscherm is geen reden om een app te bouwen.

Het tweede signaal waar we op letten is de doelgroep. Is er geen helder beeld wie de app dagelijks gebruikt en waarom, dan wordt bouwen een gok. Wij vragen daarom altijd door naar verdienmodel, gebruikersprofiel en doel. Een mooie app zonder gebruikers is duurder dan geen app. Lees onze uitleg over verdienmodellen voor apps voordat je beslist, en bekijk wat een bedrijfsapp laten maken inhoudt als het om interne gebruikers gaat.

App laten maken kosten bij Appec: zo werken wij

Wij werken met vaste prijzen per blok, dus je weet vanaf dag één waar je aan toe bent. Een eerste discovery-gesprek is gratis, en daarin maken we samen een grove inschatting van scope en budget. Is er genoeg houvast, dan werken we een offerte uit per onderdeel: concept en design, backend, frontend, tests, oplevering. Je kiest zelf welke blokken je nu doet.

Een snelle indicatie haal je uit de app kosten calculator. Liever even sparren? Plan een afspraak of neem gewoon contact op, dan praten we je rustig door de opties heen. De koffie is op ons.

Veelgestelde vragen

Waarom is het zoveel duurder dan de offerte die ik elders kreeg?

Kijk eerst wat er in die andere offerte zit. Meestal ontbreken de backend, het design, het onderhoud en de publicatie in de App Store en Play Store. Wij zetten dat er wel in, omdat je het anders binnen een half jaar alsnog nodig hebt. Vergelijk dus op scope, niet op eindbedrag, en vraag bij elk bureau een opsplitsing per blok.

Wordt het duurder als ik iOS en Android allebei wil?

Bij native ja, want we rekenen per platform: 20.000 tot 40.000 euro per platform. Bij Flutter deel je de codebase en betaal je dat niet twee keer. Daarom kiezen we per project en niet per principe. Een vaste opslag voor iOS hanteren we niet; bij Android kost testen op veel verschillende toestellen vaak juist meer tijd. Het echte verschil bepaal je pas in de scope.

Waarom kun je geen prijs noemen voordat we gepraat hebben?

Omdat koppelingen de prijs bepalen, niet de schermen. Twintig schermen zonder integraties zijn goedkoper dan vijf schermen die live met je ERP praten. Bij Met WA zat de complexiteit in de AFAS-integratie, niet in de interface. In een gesprek van een uur weten we meestal genoeg om een range te noemen die klopt.

Klaar om te weten wat jouw app echt kost?

Een eerlijke prijsinschatting begint met een eerlijk gesprek. Vertel wat je voor ogen hebt, dan schetsen we samen scope en budget, zonder verplichtingen. Klikt het, dan werken we een offerte uit met vaste prijzen per blok. Wij bouwen geen apps die in een laatje verdwijnen, dus we zijn liever vooraf streng dan achteraf teleurgesteld.

Bekijk ook onze hoofdpagina over app laten maken voor meer achtergrond over ons proces, of plan een kennismaking als je klaar bent om te praten. Koffie staat klaar.