Een app laten maken begint met een afgebakende taak voor een herkenbare gebruiker. Het type app volgt uit wat die persoon onderweg, op kantoor of zonder verbinding moet kunnen doen. Daarna kun je offertes vergelijken op dezelfde functies, platformen en beheerafspraken. De maatwerkgids behandelt het hele traject; de kostengids helpt je een begroting opbouwen.
Wat kost het om een app te laten maken?
Er is geen betrouwbaar standaardbedrag voor een app zonder afgebakende opdracht. Een afsprakenlijst voor medewerkers is iets anders dan een consumentenapp met abonnementen, mediaverwerking en klantenservice. Zelfs hetzelfde aantal schermen kan heel ander werk opleveren: een leesbaar overzicht vraagt andere logica dan een formulier dat zonder verbinding wijzigingen moet bewaren.
Laat de begroting daarom aansluiten op gebruikershandelingen. Wat gebeurt er bij aanmelden, invoeren, controleren, betalen en herstellen? Vraag welke onderdelen in de prijs zitten en welke nog onderzocht moeten worden. Een vaste prijs helpt pas bij vergelijken als de aannames, uitsluitingen en acceptatiecriteria ernaast staan.
Maak ook onderscheid tussen een klikbaar ontwerp en een werkend product. Een prototype kan laten zien of mensen de route begrijpen. Het bewijst nog niet dat een betaling wordt verwerkt of een koppeling de juiste gegevens teruggeeft.
Welk type app past bij de opdracht?
Vergelijk de routes op de functies die je nodig hebt. Een algemene uitspraak dat web altijd goedkoper is of native altijd beter presteert, helpt niet bij een concrete keuze.
| Route | Wat je bouwt | Wat je vooraf wilt toetsen |
|---|---|---|
| Webapp, eventueel als PWA | Een toepassing via de browser | Ondersteuning op de gebruikte browsers, installatie en offline taken |
| Cross-platform app | Gedeelde applicatiecode met uitgaven voor meerdere platformen | Beschikbare modules en eventueel eigen platformcode |
| Native app | Een toepassing gericht op een specifiek platform | Benodigde apparaatfuncties, onderhoud en distributie |
| Bestaand pakket of appbouwer | Inrichting op een bestaand platform | Functies, rechten, export, gebruikslimieten en abonnementskosten |
Cross-platform betekent niet dat ieder onderdeel automatisch op elk toestel hetzelfde werkt. Flutter ondersteunt bijvoorbeeld platformspecifieke code naast de gedeelde applicatie. Vraag hoe de bouwer ontbrekende functies opvangt en op welke toestellen die oplossing wordt getest.
Ook offline werken is geen exclusief kenmerk van native apps. Een webapp kan daarvoor worden ingericht. De uitleg over progressive web apps behandelt het verschil tussen een icoon op het startscherm en daadwerkelijk zonder verbinding doorwerken.
Wat moet je vastleggen voordat je offertes opvraagt?
Beschrijf een werkdag of gebruikersreis. Wie opent de app, met welk doel en welke gegevens zijn op dat moment beschikbaar? Neem de uitzonderingen meteen mee. Een gebruiker kan een wachtwoord vergeten, een upload onderbreken of dezelfde opdracht nogmaals verzenden.
Een bruikbare opdracht bevat:
- De belangrijkste handeling van de eerste versie en wat bewust later komt.
- De rollen: wie mag gegevens bekijken, veranderen of goedkeuren?
- De systemen die gegevens aanleveren en ontvangen, met beschikbare toegang.
- De toestellen en omstandigheden waarin de app moet werken.
- Een beschrijving van wat als geslaagde oplevering telt.
Laat de lastigste aanname vroeg aantonen. Bij een inspectie-app kan dat een foto-upload op een slechte verbinding zijn. Bij een abonnementendienst kan het gaan om toegang na een mislukte betaling. Dit zijn mogelijke proefscenario’s, geen uitspraken over een specifieke klant.
Welke onderdelen horen in de offerte?
Een offerte moet genoeg detail geven om het resultaat te beoordelen. Alleen een schermenlijst is daarvoor te mager. Gebruik bijvoorbeeld deze indeling en laat de leverancier per onderdeel het resultaat en de aannames beschrijven.
| Onderdeel | Wat je wilt terugzien |
|---|---|
| Onderzoek en ontwerp | Geteste gebruikersroute en open technische vragen |
| App en backend | Functies, rollen, opslag en bedrijfsregels |
| Koppelingen | Gegevensrichting, toegang, fouten en herstel |
| Testen | Toestellen, situaties en afgesproken acceptatiecriteria |
| Uitbrengen | Accounts, winkelvermelding of webdistributie en overdracht |
| Beheer | Verantwoordelijkheden, terugkerende kosten en wijzigingsafspraken |
Vraag bij elke koppeling wie bepaalt welke gegevens juist zijn. Als het CRM en de app beide een telefoonnummer kunnen wijzigen, moet de verwerking een keuze maken. Zo’n afspraak hoort bij de werking van de app, ook als de gebruiker er geen apart scherm voor ziet.
Spreek af hoe veranderingen na akkoord worden geprijsd. Een vaste prijs sluit meerwerk niet uit. Het verschil tussen een fout en een nieuwe wens moet tijdens de samenwerking bespreekbaar blijven.
Hoe plan je de bouw en de lancering?
Vraag om mijlpalen met aantoonbare resultaten. Een eerste werkende gebruikersroute zegt meer dan een percentage voortgang. Daarna kunnen koppelingen, uitzonderingen en beheer worden toegevoegd en getest. Reserveer tijd voor jouw eigen beoordeling; zonder inhoudelijke feedback kan een team wel doorbouwen, maar niet weten of het juiste probleem wordt opgelost.
Houd de technische oplevering en de publieke lancering uit elkaar. Accountverificatie, winkelbeoordeling, content en instructies voor gebruikers kunnen nog werk vragen nadat de app technisch klaar is. Laat de planning benoemen welke afhankelijkheden de bouwer beheerst en welke bij jou of een platform liggen.
De eerste versie hoeft niet elke toekomstige wens te bevatten. Ze moet wel de gekozen taak compleet afhandelen. Onze MVP-aanpak gaat verder in op die afbakening.
Wat kost publicatie in de appstores?
Prijzen gecontroleerd op 2026-09: Apple noemt voor het Apple Developer Program 99 USD per lidmaatschapsjaar. De lokale prijs kan per regio verschillen. Een Google Play Console-account heeft een eenmalige registratiebijdrage van 25 USD. Dit zijn accountkosten, geen totaalprijs voor publicatie of exploitatie.
Verder zijn er toelatingsvoorwaarden, accountverificatie en toepasselijke winkelregels. Google noemt aanvullende testvereisten voor bepaalde persoonlijke accounts. Apple beschrijft de beoordeling in zijn App Review Guidelines. Plan geen gegarandeerde goedkeuringsdatum op basis van alleen de betaaldatum van je account.
Betaalverwerking, abonnementen en eventuele winkelvergoedingen vragen een aparte beoordeling voor je product en afzetmarkt. Voeg ze niet samen tot een willekeurige vaste opslag. Een webapp die je via een URL verspreidt, heeft voor die distributieroute geen appstore-account nodig.
Wat regel je voor gebruik en onderhoud?
Maak onderscheid tussen de app op het toestel en de systemen erachter. Hosting, opslag, e-mail, kaartdiensten of AI-gebruik kunnen eigen kosten hebben. Onderhoud omvat bijvoorbeeld het herstellen van fouten en aanpassingen na wijzigingen in een besturingssysteem of koppeling. Nieuwe productfuncties zijn een andere begrotingspost.
Vraag hoe storingen worden opgemerkt en wie toegang heeft om ze te herstellen. Laat ook vastleggen hoe back-ups worden teruggezet en hoe een mislukte uitrol wordt afgehandeld. Koppel de afspraken aan de gevolgen voor jouw gebruikers; een interne weekrapportage vraagt iets anders dan een app waarmee klanten tijdens openingstijden bestellen.
Een echte appcase is Quantum Life. Daar bouwden we samen met Aery een Flutter-app en webportaal die account- en betalingslogica delen. De case laat zien waarom een mobiele app vaak meer omvat dan de schermen op de telefoon. De scope van dat project is geen prijsindicatie voor jouw idee.
Hoe beoordeel je eigendom en overdraagbaarheid?
Bij TopDevs is en blijft de code van jou. Leg daarnaast vast welke onderdelen van derden worden gebruikt en welke licenties of abonnementen daarbij horen. Codebezit alleen geeft nog geen werkende overdracht: ook accounts, configuratie, documentatie en toegang tot gegevens zijn nodig.
Laat de leverancier uitleggen hoe een ander team een versie kan uitbrengen en de dienst kan beheren. Onze gids over code-eigendom en vendor lock-in werkt dat verschil uit.
Hoe begin je concreet?
Schrijf de belangrijkste gebruikersroute op en verzamel voorbeelden van de gegevens die daarin voorkomen. Noteer de apparaten, benodigde koppelingen en de situatie die je het meeste zorgen geeft. Daarmee kun je een voorstel toetsen op werking en kosten in plaats van op het aantal getekende schermen.
Bekijk onze aanpak voor app-ontwikkeling of plan een gesprek. We helpen je de eerste versie afbakenen en bepalen welke aannames eerst een praktische proef nodig hebben.
