Wat kost een app laten maken? Wat het bedrag niet zegt

U bereidt een financieringsronde voor, of een financieringsaanvraag, om uw app te laten ontwikkelen. U hebt een bedrag nodig. Uw investeerders vragen erom, uw financieringsplan ook.

De vraag “hoeveel?” is terecht. Toch is ze maar een deel van het antwoord. Met hetzelfde bedrag kunt u een app financieren die niemand gebruikt, of een app waar uw klanten al maanden mee werken. Het verschil zit niet in de som. Het zit in de manier waarop de app met die som wordt gebouwd.

Hoe het budget voor een app meestal wordt bepaald

De artikelen die uitleggen “wat kost het om een app te laten ontwikkelen” volgen bijna allemaal dezelfde methode. Je zet de functionaliteiten op een rij. Je kent elke functionaliteit een aantal dagen toe: eenvoudig, gemiddeld of complex. Je telt er een marge voor onvoorziene zaken bij op, en daarna het onderhoud van het eerste jaar. Daar komt een bandbreedte uit.

Die methode steunt op twee pijlers: een schatting en een lijst met functionaliteiten. Wij steunen op geen van beide.

Waarom een schatting een gok blijft, lichten we toe in ons artikel over budgetoverschrijdingen. Hier gaat het ons om de lijst. Het probleem ervan is minder zichtbaar. Ze verlegt de aandacht.

Martin Fowler heeft deze verschuiving een naam gegeven: FeatureDevotion. Dat is de toestand waarin het afvinken van functionaliteiten meer waarde krijgt dan wat het project werkelijk oplevert. Een budget dat regel voor regel op basis van een lijst wordt opgebouwd, leidt daar bijna vanzelf naartoe, want elke afgevinkte regel wordt het bewijs dat het geld goed is besteed.

Een doel bereiken, geen functionaliteiten opleveren

Daar zit de meest gemaakte fout. Het doel wordt verward met de dingen die gebouwd moeten worden. De gedachte is dat het doel bereikt is zodra de geplande functionaliteiten zijn opgeleverd.

Maar een lijst met functionaliteiten is niet meer dan een hypothese over de weg ernaartoe. Dave Farley wijst op wat de cijfers uit de sector zeggen: zelfs bij de beste softwarebedrijven ter wereld leveren twee op de drie ideeën geen waarde op, of negatieve waarde (Modern Software Engineering, p. 51). Niemand weet van tevoren welke. Bij Microsoft komen Ronny Kohavi en zijn collega’s tot dezelfde conclusie (“Online Experimentation at Microsoft”, 2009): slechts ongeveer een derde van de ideeën die een indicator moeten verbeteren, verbetert hem ook.

Allen Holub zegt het in één zin: “Building the wrong thing on time and in budget doesn’t buy you much.” Het verkeerde bouwen, op tijd en binnen budget, levert weinig op.

Waar het dus om gaat, is weten of het doel bereikt is. Niet weten welke functionaliteiten zijn opgeleverd.

Een app die vanaf de eerste maand werkt

Het weinige dat u bouwt, moet raak zijn. Vanaf de eerste maand van de ontwikkeling werkt de app. Ze doet weinig. Maar wat ze doet, levert waarde op waar het echt om draait voor de mensen aan wie u haar wilt verkopen.

Daarna blijft ze werken, op elk moment. Daar dient Continuous Delivery voor: elke wijziging wordt gecontroleerd voordat ze in de app terechtkomt, zodat wat gisteren werkte, vandaag nog steeds werkt.

Het gaat er niet om veel te doen. Elke dag is de vraag dezelfde: wat is vandaag het nuttigste om te doen? Dat maakt de adaptieve aanpak mogelijk. Die gaat snel naar de kern. En houdt daarna elke dag de aandacht bij de waarde die die dag wordt verwacht.

De app bouwen samen met de mensen aan wie u haar wilt verkopen

De mensen aan wie u de app wilt verkopen, weten wat de kern is. Als u het ze vooraf vraagt, kunnen ze dat niet altijd zeggen. Ook Farley stelt dat vast: zelfs als je gebruikers vraagt wat ze willen, weten ze het niet (p. 51). Zet een werkende app voor ze neer, en ze reageren wel.

De feedbackloop begint dus zo vroeg mogelijk. De app komt in hun handen. U luistert naar wat ze erover zeggen. U stuurt bij. En u begint opnieuw.

Nog voordat er iets gebouwd wordt, kan een idee trouwens al getest worden: daar is een MVP voor.

Zes maanden wachten op de eerste feedback

Stel dat de loop pas na zes maanden ontwikkeling op gang komt. Dan is het geen loop meer. Dan zijn het meerdere loops tegelijk.

De feedback komt in één keer binnen: wat ontbreekt, wat in de weg zit, wat niet gebruikt wordt. Elk punt vraagt om een wijziging. Je weet niet meer waar je moet beginnen. En zes maanden ontwikkeling op een lijst die vooraf vastlag, hebben een flink deel van het budget opgemaakt.

Geldgebrek is trouwens bijna nooit de oorspronkelijke oorzaak. CB Insights onderzocht 385 startups met durfkapitaal die sinds 2023 zijn gestopt. Bij 70 % raakte het geld op. Het rapport benadrukt dat dit bijna altijd de laatste oorzaak van het stoppen is, niet het probleem waar het mee begon. Bij 43 % vond het product zijn markt niet (CB Insights, maart 2026).

Wat codekwaliteit betekent

Wie maanden heeft gebouwd aan dingen waar niemand behoefte aan had, blijft zitten met een les die niemand heeft getrokken. Dat vinden wij het meest zonde. Niemand heeft uitgelegd wat goede code is, of wat ze waard is.

Goede code is code die je makkelijk kunt aanpassen.

Farley zegt het op zijn manier: vaak ontdek je pas of een ontwerp goed of slecht is op het moment dat je het probeert aan te passen (p. 108). Hij wijst ook op de ondertitel die Kent Beck koos voor zijn boek over Extreme Programming: Embrace Change, verandering omarmen. Volgens Farley volgt al het andere uit dat idee: het vermogen behouden om van mening, van code, van technologie te veranderen, naarmate je meer leert (p. 155).

Voor een app die wordt gebouwd op basis van de feedback van haar gebruikers, is dat vermogen doorslaggevend. Elke reactie vraagt om een wijziging. Als elke wijziging duur is, of iets anders kapotmaakt, vertraagt de loop, en gaat het budget op aan reparaties. Farley vat het zo samen: op de lange termijn kies je niet tussen betere software en software die sneller klaar is, je kiest tussen “better software faster” en “worse software slower” (p. 154).

Met welk budget moet u dan rekenen om een app te laten maken?

Voor een financieringsronde hebt u toch een bedrag nodig. Dat bedrag krijgt u niet door functionaliteiten op te tellen. U krijgt het door te bepalen wat u elke maand investeert, en hoeveel maanden u van uw gebruikers wilt kunnen leren voordat u de volgende beslissing neemt.

Holub redeneert net zo. Als het team elke maand hetzelfde bedrag uitgeeft, vallen budget en datum samen. Ligt het budget vast, dan blijft de scope de enige variabele. Martin Fowler komt op hetzelfde uit: een vaste prijs kan, een vaste scope niet. De nuttigste functionaliteiten kiezen we samen, onderweg.

De adaptieve aanpak voorspelt wat voorspelbaar is: het maandbudget en de ontwikkeldagen per maand. Hij probeert niet te voorspellen wat onvoorspelbaar is: wat uw gebruikers met een functionaliteit zullen doen voordat ze die in handen hebben.

Zo werken wij. Wij ontwikkelen uw app op maat voor een vast budget, aan het eind van elke maand gefactureerd voor het geleverde werk. Ze is binnen een maand bruikbaar. Bruikbaar betekent niet af: uw teams gebruiken haar vanaf de eerste maand. Wat het gebruik ons over een functionaliteit leert, passen we nog dezelfde dag toe.

Wat vastligt, is het budget en het op te lossen probleem. Met uw budget koopt u werk dat dit probleem voortdurend kleiner maakt, vanaf de eerste ontwikkeldag. We streven ernaar het volledig op te lossen, maar kunnen dat niet garanderen en er geen datum op zetten. U hoeft niet op die dag te wachten tot het probleem kleiner wordt. Elke maand ziet u wat het oplevert, en beslist u of u doorgaat.

Verder lezen

De prijs én de lijst met functionaliteiten vastleggen, of betalen voor de bestede tijd: wie het risico draagt als de behoefte verandert, is het onderwerp van ons artikel over vaste prijs en regie.

Haalt u geld op om uw app te laten ontwikkelen, of zoekt u het juiste budget? Zullen we kennismaken?

Bronnen

• M. Fowler, “PurposeOfEstimation”, martinfowler.com (FeatureDevotion).
• M. Fowler, “FixedPrice”, martinfowler.com (vaste prijs zonder vaste scope).
• A. Holub, “NoEstimates, An Introduction”, holub.com (“Building the wrong thing on time and in budget doesn’t buy you much”; vast budget, scope als enige variabele).
• D. Farley, Modern Software Engineering, Addison-Wesley, 2021: p. 51 (twee op de drie ideeën zonder waarde; gebruikers weten niet wat ze willen), p. 108 (de kwaliteit van een ontwerp blijkt als je het aanpast), p. 154 (“better software faster” en “worse software slower”), p. 155 (Embrace Change, het vermogen behouden om te veranderen).
• CB Insights, “The top 9 reasons startups fail”, 5 maart 2026 (431 bedrijven gestopt sinds 2023, redenen bekend voor 385).
• R. Kohavi, T. Crook, R. Longbotham, B. Frasca, R. Henne, J. Lavista Ferres, T. Melamed, “Online Experimentation at Microsoft”, Microsoft ThinkWeek, 2009, p. 8 (ongeveer een derde van de ideeën verbetert de beoogde indicator).