Onze app-trajecten starten vanaf €1.500. Dat startpunt geldt voor een gerichte, functionele app: een paar schermen, een duidelijk doel, en een koppeling met een backend of bestaande API. Complexere apps met veel schermen, realtime data of zware integraties kosten meer, in lijn met de extra ontwikkeltijd.
Native, of één codebase voor beide platformen
De grootste prijsknop is niet het aantal schermen, maar de keuze tussen native ontwikkeling (apart voor iOS en Android) en cross-platform met bijvoorbeeld React Native. Cross-platform betekent één codebase voor beide platformen, wat de bouwtijd en dus de prijs flink omlaag brengt zonder in te leveren op gevoel of snelheid. Wij adviseren native alleen wanneer een app functionaliteit nodig heeft die dat écht vereist.
Wat vaak wordt vergeten in een prijsinschatting
De publicatie in de App Store en Play Store, inclusief store-vermeldingen, screenshots en de review-aanvraag bij Apple en Google, hoort standaard bij een traject. Datzelfde geldt voor pushnotificaties en basis analytics: functionaliteit die een app pas echt bruikbaar maakt na de lancering.
Wat een MVP kost versus een volwaardige app
Een MVP (minimum viable product) bevat alleen de kernfunctionaliteit die nodig is om je idee bij echte gebruikers te testen: geen uitgebreide instellingen, geen edge cases, geen polijstlaag die pas relevant wordt bij schaal. Dat is bewust: een MVP is bedoeld om te leren of je aanname klopt, niet om meteen compleet te zijn. Daardoor valt de prijs van een MVP doorgaans in de onderkant van onze bandbreedte.
Een volwaardige app met accountbeheer, betalingen, offline-ondersteuning en uitgebreide edge-case-afhandeling kost aanzienlijk meer, simpelweg omdat elk van die onderdelen eigen ontwerp-, bouw- en testwerk vraagt. Wij adviseren de meeste startende ondernemers om met een MVP te beginnen: sneller live, minder risico, en de volgende bouwfase kun je onderbouwen met echte gebruiksdata in plaats van aannames.
De rol van backend en API's in de prijs
Een app die alleen lokaal op het toestel werkt (zoals een rekenmachine of een offline notitie-app) is relatief goedkoop, omdat er geen server, database of API bij komt kijken. Zodra een app gegevens moet opslaan, gebruikers moet kunnen laten inloggen, of moet synchroniseren tussen meerdere toestellen, is een backend nodig: een server die data verwerkt en bewaart. Het bouwen en beveiligen van die backend is vaak minstens zo veel werk als de app zelf.
Moet de app koppelen met een bestaand systeem, zoals een CRM, boekhoudpakket of voorraadbeheer? Dan hangt de prijs sterk af van hoe goed gedocumenteerd en toegankelijk de API van dat systeem is. Een moderne, goed gedocumenteerde API is een kwestie van dagen om te koppelen; een verouderd of slecht gedocumenteerd systeem kan de bouwtijd flink verlengen.
Onderhoud na de lancering
Een app is nooit "klaar" na de lancering, ook niet als er geen nieuwe functionaliteit bij komt. Apple en Google brengen regelmatig nieuwe OS-versies uit, en een app die daar niet op wordt getest en bijgewerkt, loopt het risico op crashes of zelfs verwijdering uit de store. Reken op doorlopend onderhoud, vergelijkbaar met websites: bij TechGents valt dit onder dezelfde onderhoudsabonnementen, afhankelijk van hoe actief de app gebruikt wordt.
Houd ook rekening met de jaarlijkse kosten van de developer-accounts zelf: Apple rekent een jaarlijkse bijdrage voor de App Store, Google een eenmalig bedrag voor de Play Store. Klein in verhouding tot de bouwkosten, maar wel een terugkerende post die makkelijk wordt vergeten in een eerste budgetinschatting.
Hoe je jouw eigen budget kunt inschatten
Voordat je een offerte aanvraagt, helpt het om drie dingen scherp te hebben: wat het kernprobleem is dat de app moet oplossen (in één zin), welke twee of drie functies daar echt voor nodig zijn, en welke functies "leuk om te hebben" zijn maar niet essentieel voor de eerste versie. Bureaus die dit onderscheid met je doorlopen vóór het opstellen van een offerte, geven je meestal een realistischer beeld dan bureaus die meteen met een compleet functieoverzicht komen.
Ontwerp: waarom dit vaker wordt onderschat
Een app die er "gewoon oké" uitziet, wordt sneller verwijderd dan een app die vertrouwd en doordacht aanvoelt, ongeacht hoe goed de onderliggende techniek is. Gebruikers vergelijken je app onbewust met de apps die ze dagelijks gebruiken, ook als die van compleet andere bedrijven zijn met veel grotere budgetten. Dat betekent niet dat je datzelfde budget nodig hebt, wel dat UX-ontwerp (hoe een gebruiker door de app navigeert, waar knoppen staan, hoe fouten worden getoond) geen sluitpost mag zijn in de planning.
Wij reserveren daarom altijd een apart deel van elk apptraject voor ontwerp en een klikbaar prototype, vóórdat er code wordt geschreven. Dat voorkomt dat er wordt gebouwd op basis van een idee dat in de praktijk niet prettig gebruikt, en het is aanzienlijk goedkoper om een ontwerp aan te passen dan om werkende code te herschrijven.
Testen op echte apparaten
Een app die perfect werkt op de simulator van de developer, kan op een ouder toestel of een andere schermgrootte alsnog problemen geven. Grondig testen op een reeks echte apparaten, verschillende schermformaten en beide besturingssystemen is geen overbodige luxe maar standaard onderdeel van een zorgvuldig traject. Bureaus die dit overslaan om sneller te kunnen opleveren, verschuiven het probleem naar na de lancering, wanneer een bug live gaat en gebruikers er als eerste tegenaan lopen.
Wat een goede technische keuze je later bespaart
De keuze voor een moderne, goed onderhouden technische stack (bijvoorbeeld React Native met een gestructureerde backend) betaalt zich pas echt uit bij de eerste grote uitbreiding: nieuwe functionaliteit toevoegen aan een schone, goed opgezette codebase kost een fractie van de tijd die het kost om diezelfde functionaliteit in een verouderde of rommelig opgebouwde app te proppen. Vraag daarom bij een offerte niet alleen naar de prijs van de eerste versie, maar ook hoe onderhoudbaar en uitbreidbaar de gekozen technologie is voor wat je op de langere termijn wilt bouwen.
Freelancer, bureau of eigen ontwikkelaar in dienst
Voor een eerste app is een freelancer soms de goedkoopste optie, maar brengt risico met zich mee: bij ziekte, drukte elders of vertrek is er niemand die het overneemt zonder zich eerst in te werken in andermans code. Een bureau met meerdere developers is duurder per uur, maar biedt continuïteit: als iemand uitvalt, kan een collega het overnemen omdat de manier van werken en documenteren gedeeld is. Een eigen ontwikkelaar in dienst nemen is pas rendabel vanaf een schaal waarbij je structureel, het hele jaar door, ontwikkelcapaciteit nodig hebt, wat voor de meeste startende app-ideeën nog niet het geval is.
Voor de meeste MKB-ondernemers is een klein, vast team bij een bureau de praktische middenweg: de directheid van een freelancer, met de continuïteit van meerdere mensen die het project kennen.
De eerste maanden na lancering
De periode direct na lancering is vaak drukker dan verwacht: gebruikers vinden manieren om de app te gebruiken die niet volledig zijn voorzien, kleine bugs komen pas met echt gebruik aan het licht, en feedback van de eerste gebruikers geeft vaak direct aanleiding tot kleine aanpassingen. Reserveer hier bewust ruimte voor in je planning en budget, in plaats van ervan uit te gaan dat het project na livegang direct is afgerond.