Bouwen & Productontwikkeling

    Wat een app kost hangt af van één vraag die de meeste mensen niet stellen

    2026-04-24·6 min·Bouwen & Productontwikkeling

    "Wat kost het om een app te bouwen?" is de meest gestelde vraag in onze eerste gesprekken. Het eerlijke antwoord: dat hangt ervan af. Niet om de vraag te ontwijken, maar omdat het afhangt van keuzes die op dat moment nog niet gemaakt zijn.

    Een team bespreekt scope en budget voor een app-traject
    Scope bepaalt budget. Alles daarna is rekenen.

    Complexiteit bepaalt de orde van grootte

    Een eenvoudige app met inlog, een lijst en een paar formulieren is iets fundamenteel anders dan een app met realtime synchronisatie, offline-modus, betaalintegraties en een eigen backend. Het verschil zit niet alleen in de tijd om te bouwen, maar in de hoeveelheid samenhang die je moet ontwerpen, testen en onderhouden.

    Complexiteit groeit niet lineair. Een tweede gebruikersrol verdubbelt niet het werk, hij verdrievoudigt het. Elke nieuwe functie raakt bestaande onderdelen, vraagt om extra teststates en introduceert nieuwe foutpaden. Wie de scope vooraf scherp afbakent, betaalt minder dan wie onderweg blijft toevoegen.

    De vraag is dus niet "wat kost een app", maar "wat moet de eerste versie kunnen, en wat kan in een volgende fase". Dat onderscheid alleen al kan een budget halveren of verdubbelen.

    Platform: native of cross-platform

    Een native app voor iOS én Android betekent in de praktijk twee codebases, twee teams, twee releasecycli. Cross-platform frameworks zoals React Native of Flutter laten je één codebase onderhouden voor beide platformen, met een prestatie die voor de meeste zakelijke apps niet te onderscheiden is van native.

    Native is alleen verdedigbaar als je platformspecifieke functies nodig hebt die in cross-platform niet of slecht beschikbaar zijn. Voor de overgrote meerderheid van zakelijke toepassingen is cross-platform de verstandige keuze: lagere bouwkosten, lager onderhoud, sneller bij beide platformen tegelijk.

    Design is geen kostenpost, het is een investering

    Slecht ontworpen apps worden niet gebruikt. Dat is geen mening, dat is wat retentiedata laat zien. De besparing op design wordt drie keer terugbetaald aan herontwerp, herstelwerk en gemiste adoptie.

    Goed design begint vóór de eerste regel code: gebruikersonderzoek, wireframes, een doordachte informatie-architectuur, prototypes die je toetst voordat je ze laat bouwen. Reken op vijftien tot twintig procent van het ontwikkelbudget voor design dat zijn werk doet. Minder is meestal vals besparen.

    Onderhoud is geen optie

    Een app die je lanceert en daarna laat liggen, is binnen een jaar verouderd. Besturingssystemen krijgen updates, dependencies worden onveilig, devices veranderen. Onderhoud is geen luxe, het is de prijs van blijven werken.

    Reken op vijftien tot twintig procent van de initiële ontwikkelkosten per jaar voor realistisch onderhoud: bugfixes, OS-updates, security-patches, kleine verbeteringen. Wie dat niet inplant, ontdekt na een jaar dat de app stilstaat terwijl de wereld doorloopt.

    Team en locatie

    Een uurtarief van vijfendertig euro klinkt aantrekkelijk tot je de werkelijke kosten optelt: communicatieoverhead, kwaliteitscontrole, herwerk, vertraging door tijdzones. Wat goedkoop lijkt op offerte-niveau, is zelden het goedkoopst op projectniveau.

    Een ervaren team in West-Europa kost meer per uur, maar levert vaak in de helft van de tijd, met minder revisierondes en een product dat na oplevering werkt. Vergelijk niet op uurtarief, vergelijk op totale eigendomskosten over drie jaar. Dan ziet de rekening er anders uit.

    MEER WETEN?

    Benieuwd wat jullie app-idee realistisch kost en hoe je het slim faseert?

    We denken graag mee over scope en aanpak.