In dit artikel

App ontwikkelen doorloop je in zes stappen: idee, wireframe, prototype, bouw, testen en lanceren. Een eerste werkende versie, een MVP, staat bij ons altijd binnen 8 tot 16 weken live. Dat is sneller dan de meeste ondernemers denken, mits je de scope klein houdt en op tijd kiest tussen native en hybride.

Qua budget: een native MVP kost per platform 20.000 tot 40.000 euro, een PWA 15.000 tot 30.000 euro. Hieronder lopen we het hele proces door, met de plekken waar het in de praktijk misgaat. Geen theorie, maar wat we zelf tegenkomen in projecten.

Waarom bedrijven een app laten ontwikkelen

Een app geeft je een directe lijn naar je gebruikers: pushmeldingen, offline gebruik, toegang tot camera, NFC en locatie. Dat kan een website niet, of niet goed. Voor sommige bedrijven is de app niet een extraatje naast de site, maar het systeem waar de dagelijkse operatie op draait.

Bij Met WA Beveiliging in Zeist is dat precies het geval. Honderden beveiligingsmedewerkers gebruiken de native app dagelijks in het veld voor dienstrapporten, urenregistratie en werkinstructies, ook op tablets bij centrale posten. Wij bouwen en onderhouden die app sinds 2021.

Met WA app op iPhone met dienstrapporten en planning

Meer over die bouw en de keuzes daarin lees je in de Met WA app case. Een ander voorbeeld uit de andere hoek: de VETTS-app voor videoconsulten met dierenartsen staat op 5,0 sterren uit 155 beoordelingen en is inmiddels ruim vier jaar live. Consumenten-app of interne bedrijfsapp, het proces eronder is grotendeels hetzelfde.

De 6 stappen van app ontwikkelen

App ontwikkelen verloopt in zes stappen: idee scherp krijgen, wireframe, prototype, bouwen, testen en lanceren. Elke stap bouwt op de vorige. Sla je er een over, dan betaal je dat later terug in herbouwwerk.

Onze ervaring: de stappen die klanten het liefst overslaan, wireframe en prototype, zijn juist de goedkoopste plekken om van mening te veranderen. Een knop verplaatsen in Figma kost minuten. Een navigatiestructuur omgooien in een halfgebouwde app kost weken.

Stap 1: je app-idee scherp krijgen

Begin klein en met één duidelijk doel. Beantwoord eerst welk probleem je oplost, voor wie, en wat de simpelste versie is die dat probleem al oplost. Dat laatste is je MVP. Features komen daarna.

Vier vragen die we in een eerste gesprek altijd stellen: welk probleem los je op, wie heeft dat probleem, bestaat er al een oplossing, en hoe verdien je eraan of wat bespaart het. Kun je die niet in twee minuten beantwoorden, dan is het idee nog niet klaar om te bouwen. Hoe je zo’n idee verder uitwerkt, beschrijven we op idee voor een app. En als je toch bezig bent: een goede app-naam bedenken kost minder tijd vroeg in het traject dan vlak voor de storelancering.

Stap 2 en 3: wireframe en prototype

Een wireframe is het skelet van de app: waar staan knoppen, teksten en schermen. Een prototype is de eerste visuele versie waar je echt doorheen kunt klikken, met kleuren en huisstijl. Samen voorkomen ze dat je pas tijdens de bouw merkt dat de navigatie niet logisch voelt.

Wij ontwerpen in Figma en laten klanten zelf door het prototype klikken voordat er één regel code wordt geschreven. Dat levert bijna altijd nog twee of drie aanpassingen op. Lees ook wat een wireframe is, wat een prototype is en het volledige proces van app ontwerpen.

Stap 4: de app bouwen, zelf of laten doen

Je hebt drie routes: zelf programmeren, een no-code builder gebruiken, of een ontwikkelaar inschakelen. Voor een bedrijfskritische app met eigen logica of koppelingen is die laatste route vrijwel altijd de betere keuze. No-code werkt prima voor een simpele catalogus of formulieren-app, maar loopt vast zodra je een API-koppeling met je ERP, rolgebaseerde rechten of hardware-toegang nodig hebt. Dan kom je uit bij een maatwerk app.

Zelf bouwen vraagt full-stack kennis: frontend, backend en database. Dat kan, maar reken op een lange leercurve en een app die je later zelf moet blijven onderhouden. De routes naast elkaar staan in zelf een app maken of uitbesteden. Meer over de grenzen van tools zonder code lees je in wat is no-code, en over de tussenvorm met beperkt programmeerwerk in wat is low-code.

Gaat het om meer dan de app alleen, bijvoorbeeld een portaal of backoffice erachter, dan valt het onder breder software laten ontwikkelen.

Onze eigen stack: native bouwen we in Swift (iOS) en Kotlin (Android), hybride in Flutter, met een .NET-backend op Microsoft Azure. Voor de web-frontend is Next.js in meerdere projecten onze vaste keuze.

AI-codegeneratie gebruiken we zelf veel, en het maakt het werk makkelijker. Met één harde afspraak erbij: we lopen alle code regel voor regel na. Wie een pull request indient, moet elke regel kunnen uitleggen, ook de regels die een model heeft geschreven. Reviews blijven net zo kritisch als bij volledig handgeschreven code. Anders schuif je je eigen werk door naar de collega die jouw PR reviewt.

Wat het oplevert: we werken er zeker sneller door dan voorheen. Dat zie je terug in onze offertes.

Native of hybride: welke keuze past bij jouw app

Wij bouwen beide en kiezen per project. Native geeft de beste prestaties en volledige toegang tot hardware en sensoren. Hybride met Flutter betekent één codebase voor iOS en Android, dus sneller bouwen en goedkoper onderhouden. Het idee dat hybride “beperkt” is, klopt niet meer; het hangt af van wat de app moet doen.

Bij CLS LED in Wijchen was native de enige serieuze optie. Hun LumiTaG-app configureert professionele LED-armaturen via een NFC-tap, met haptische feedback en visuele bevestiging zodat een technicus in een donker theater zeker weet dat de instelling is geschreven. Dat zit zo dicht op het NFC-protocol en het apparaat dat we het in Swift en Kotlin hebben gebouwd. Resultaat: configuratietijd van uren terug naar minuten.

LumiTaG app die via NFC een LED-armatuur uitleest op een iPhone

De volledige CLS LED case laat zien hoe die app offline werkt, zonder server. Draait je app vooral op formulieren, lijsten, dashboards en API-calls, dan is Flutter meestal de slimmere keuze: één team, één codebase, twee stores. De afweging staat uitgebreid in native app vs cross-platform.

Stap 5 en 6: testen en lanceren

Test vroeg, niet pas als de app “klaar” is. Wij testen per opgeleverde functie, met daarnaast een stresstest waarin we de app bewust proberen te breken: rare invoer, wegvallende verbinding, snel achter elkaar tappen. Bij de Met WA-app testen we standaard ook op tablet, omdat de centrale posten daarop werken en dat gedrag afwijkt van telefoons. Wat een bug precies is en welke soorten je tegenkomt, leggen we uit in wat is een bug.

Daarna volgt publicatie in de App Store en Google Play. Voor iOS heb je een Apple Developer account nodig en een review die aan de App Review Guidelines van Apple moet voldoen. Reken op een paar dagen. Wat je daarvoor in je test- en lanceerplan zet, beschrijven we op app testen en app lanceren.

Een lancering is trouwens geen eindpunt. Zonder plan om je app te promoten blijft ook een goede app onzichtbaar, zeker bij publieksapps. Bij interne bedrijfsapps speelt dat minder, daar zit de winst in uitleg en begeleiding op de werkvloer.

Hoe lang duurt het om een app te ontwikkelen

Een MVP staat bij ons altijd binnen 8 tot 16 weken live, of het nu een app, een portaal of een platform is. De doorlooptijd hangt af van de scope, niet van het aantal stores waar je lanceert. Met Flutter kost een tweede platform bijna geen extra tijd; native bouw je twee keer, wat vooral op het budget drukt.

Wat de planning in de praktijk vertraagt, is zelden de code. Het is wachten op content, op een beslissing over een proces, of op toegang tot een systeem waar we mee moeten koppelen. Ons advies: regel die drie dingen voordat de bouw begint. Meer over planning staat in hoe lang duurt het om een app te ontwikkelen.

Een app in gedachten? In een uur kijken we samen naar aanpak, planning en budget.

Wat kost het om een app te ontwikkelen

De kosten hangen af van het type app en het aantal platforms. Een native MVP kost 20.000 tot 40.000 euro per platform. Een PWA-MVP zit tussen 15.000 en 30.000 euro. Bredere MVP-trajecten vallen in de range van 10.000 tot 40.000 euro, afhankelijk van hoeveel er in versie één moet zitten.

Losse onderdelen kunnen ook apart: een cloud-backend bouwen we voor 4.000 tot 15.000 euro, een los UI/UX-designtraject voor 4.000 tot 12.000 euro. Wij werken met vaste prijzen per ontwikkelblok, niet met een open urenrekening. Zo weet je vooraf waar je aan toe bent.

Reken daarnaast op onderhoud: 15 tot 20 procent van het bouwbudget per jaar. Dat is geen verkooptruc maar simpele werkelijkheid, want iOS en Android brengen elk jaar nieuwe versies uit. De volledige opbouw van een begroting staat op app ontwikkelen kosten.

Veelgestelde vragen

Waarom krijg ik pas een vaste prijs als de scope vaststaat?

Omdat we ons niet vastleggen op iets dat nog niet scherp is. De drie vragen die we in een eerste gesprek het vaakst krijgen zijn: wat kost het, hoe lang duurt het en wat worden mijn maandlasten. Op alle drie is ons antwoord hetzelfde: een grove indicatie geven we meteen, maar we committeren ons pas als de scope duidelijk is.

Dat is geen ontwijkende houding. Het beschermt je tegen scope creep: het geleidelijk uitdijen van de wensenlijst tijdens de bouw, waardoor planning en budget meeschuiven zonder dat iemand een besluit voelt nemen. Eerst scope vastzetten, dan een vaste prijs per ontwikkelblok.

Kun je beginnen met alleen een Android-app?

Ja, en soms is dat het slimste. Als je doelgroep intern is en je het toestelpark zelf beheert, bouw je voor één platform en bespaar je de helft van het native budget. Bij publieksapps adviseren we meestal wel meteen twee platforms, en dan is Flutter de goedkopere route.

Wat als een ander bureau mijn app heeft gebouwd en niet meer onderhoudt?

Dan kunnen we hem overnemen. Dat deden we bij Gifwijzer: de codebase liep achter op de actuele SDK-versies, waardoor Apple en Google geen nieuwe releases meer accepteerden. Wij hebben de stack bijgewerkt, functionaliteit toegevoegd en draaien sindsdien het structurele onderhoud. Wel eerlijk: zo’n achterstandstraject kost altijd meer dan doorlopend onderhoud had gekost.

Moet mijn app een eigen backend hebben?

Niet altijd. De LumiTaG-app van CLS LED werkt volledig offline, zonder server, omdat alle data in het armatuur zelf zit. Zodra je gebruikers, gedeelde data, pushmeldingen of koppelingen met je ERP nodig hebt, heb je wel een backend nodig.

Zo brengen we jouw app-idee verder

Heb je een app-idee en wil je weten of het in 8 tot 16 weken haalbaar is? Leg het ons voor. In een gesprek van een uur kunnen we meestal al zeggen of native of hybride past, hoe je de scope het beste knipt en welke range realistisch is. Bekijk wat we doen bij een app laten maken, plan direct een afspraak of neem contact op en kom langs in Nijmegen. De koffie is op ons.

Klaar om te sparren? Plan een uur met ons team, of bel +31 (0)24 202 24 35.