Heb je een budget van ruwweg €10.000 tot €40.000 voor een app? Dan heb je de meeste keuze, en kun je dus ook het makkelijkst de verkeerde partij kiezen. Voor dat bedrag kun je terecht bij een freelancer, een student, een klein ontwikkelteam, een groot bureau, een team in het buitenland of een no-codeplatform. Elke optie ruilt iets in: snelheid, zekerheid, prijs of de kans dat je app over twee jaar nog te onderhouden is. In dit artikel zetten we die afwegingen naast elkaar, laten we zien wat realistische doorlooptijden zijn en leggen we uit wanneer een vaste prijs wel en niet werkt.

De korte versie

  • Kies op risico, niet alleen op prijs. De goedkoopste offerte is duur als de app half af blijft of niemand de code nog durft aan te raken.
  • Met een middelgroot budget past een kleine, ervaren studio meestal het best. Groot genoeg om een complete app op te leveren, klein genoeg om je budget niet aan overhead op te maken.
  • Een vaste prijs werkt alleen met een vaste scope. Vraag dus niet alleen wat het kost, maar ook wat er precies in zit en wat er gebeurt als je iets wilt veranderen.
  • Reken op 4 tot 8 weken voor een eerste versie. Duurt het veel langer, dan is die eerste versie waarschijnlijk te groot.

Wat koop je met een middelgroot budget?

Met €10.000 tot €40.000 bouw je geen tweede Uber, maar wel een volwaardige eerste versie van een serieus product. Denk aan een app met accounts, meerdere gebruikersrollen, betalingen, een beheeromgeving en een paar koppelingen met systemen die je al gebruikt. Bij ons valt zo'n complete app meestal tussen de €10.000 en €15.000; in Wat kost een app laten ontwikkelen? lees je hoe die bedragen zijn opgebouwd.

Waar je binnen die bandbreedte uitkomt, hangt minder af van het aantal schermen dan van wie het bouwt. Hetzelfde plan kan bij de ene partij €12.000 kosten en bij de andere €40.000, omdat er meer mensen, meer overleg en meer overhead meedraaien. Dat maakt de keuze van je partner minstens zo belangrijk als de keuze van functies.

Vijf soorten partijen naast elkaar

Freelancer of student

  • Sterk in: laagste prijs, direct contact.
  • Let op: Eén persoon is een single point of failure: ziek, vakantie of een vaste baan en je project ligt stil. Ontwerp, backend en de app zelf zijn zelden allemaal één persoon zijn sterkste kant.
  • Past bij: kleine, afgebakende klussen of een prototype.

Klein ontwikkelteam of studio

  • Sterk in: complete app met één aanspreekpunt, korte lijnen, weinig overhead.
  • Let op: Beperkte capaciteit: vraag hoeveel projecten ze tegelijk doen en wie er echt aan jouw app werkt.
  • Past bij: een complete eerste versie binnen een middelgroot budget.

Groot bureau

  • Sterk in: capaciteit, vaste processen, meerdere specialisten.
  • Let op: Accountmanagers, projectmanagers en overleg zitten in je prijs. Je budget gaat sneller op, en je project is bij hen relatief klein.
  • Past bij: grote budgetten, meerdere teams, langlopende trajecten.

Offshore team

  • Sterk in: lage uurtarieven.
  • Let op: Tijdsverschil, taal en communicatie kosten tijd. Je moet zelf veel sturen en testen, wat in de praktijk vaak de besparing opeet.
  • Past bij: opdrachtgevers die zelf technisch sterk zijn en tijd hebben om te sturen.

No-code of AI-bouwer

  • Sterk in: snel een eerste versie, zelf aan te passen.
  • Let op: Je loopt tegen grenzen aan bij complexere logica, koppelingen en schaal. Overstappen naar maatwerk betekent vaak opnieuw beginnen.
  • Past bij: een idee valideren of een interne tool met weinig gebruikers.

Geen van deze opties is altijd fout. Een student kan prima een prototype bouwen, en voor een bank met vijf productteams is een groot bureau logisch. Het gaat erom welk risico jij kunt dragen. Bij een middelgroot budget wil je meestal één ding: een app die af komt, werkt en later uitgebreid kan worden, zonder dat je zelf projectmanager hoeft te spelen.

De afweging: scope, tijd en geld

Bij elk softwareproject trekken drie dingen aan elkaar: wat er gebouwd wordt (scope), wanneer het af is (tijd) en wat het kost (geld). Wie belooft dat alle drie tegelijk flexibel blijven, belooft iets wat niet kan. Bij een goed project leg je twee daarvan vast en wordt de derde bewust gekozen.

  • Vaste prijs en deadline, scope gekozen. Je bepaalt vooraf precies wat er in de eerste versie komt. Wil je iets toevoegen, dan schuift er iets anders uit of komt het in een volgende versie. Dit geeft de meeste zekerheid.
  • Vaste scope, prijs en tijd open. Je krijgt alles wat je bedacht hebt, maar betaalt per uur tot het af is. Prettig als de scope echt vaststaat, riskant als die nog in beweging is.
  • Vast budget per maand, scope groeit mee. Je huurt eigenlijk een team in. Geschikt als je product al draait en je continu wilt doorontwikkelen, minder geschikt voor een eerste versie.

Vaste prijs of uurtje-factuurtje?

Een vaste prijs geeft rust: je weet vooraf wat je kwijt bent. Maar hij werkt alleen als de scope concreet is. Een offerte met een vaste prijs en een vage omschrijving ("een app voor het boeken van afspraken") verschuift het risico naar later, in de vorm van meerwerk.

Een goede vaste prijs herken je aan drie dingen:

  1. Een concrete scope. Welke schermen, welke gebruikersrollen, welke koppelingen, welke platforms. Hoe specifieker, hoe minder discussie achteraf.
  2. Een duidelijke regel voor wijzigingen. Wat gebeurt er als je halverwege iets anders wilt? Wordt het geruild tegen iets anders, of komt er een nieuwe prijs?
  3. Een vaste opleverdatum. Een vaste prijs zonder deadline geeft de bouwer weinig reden om op tijd te leveren.

Uurtje-factuurtje is eerlijker als je nog niet precies weet wat je wilt, maar dan moet je wel elke week zien waar je uren naartoe gaan. Bij een eerste versie raden we bijna altijd een vaste prijs aan: het dwingt beide kanten om vooraf scherp te kiezen, en dat maakt de app meestal beter.

Realistische doorlooptijden

Hoe lang het duurt, hangt vooral af van hoeveel er in de eerste versie zit. Bij ons duurt een eerste versie 4 tot 8 weken: een MVP met alleen de kernfunctie zit aan de korte kant, een complete app met meerdere rollen, betalingen of koppelingen aan de lange kant.

Reken daar nog bij: een week of twee vooraf om de scope scherp te krijgen, en een paar dagen voor de beoordeling door Apple en Google voordat de app in de stores staat. Hoor je een planning van zes maanden of langer voor een eerste versie, vraag dan wat er uit kan. Hoe langer je bouwt voordat echte gebruikers iets zien, hoe groter de kans dat je het verkeerde bouwt. Daarom beginnen we vaak met een MVP.

Acht vragen voor je eerste gesprek

  1. Wie bouwt mijn app echt? De persoon in het verkoopgesprek, een collega of een onderaannemer?
  2. Kan ik apps zien die jullie gebouwd hebben? Niet alleen screenshots, maar apps die je kunt downloaden en gebruiken.
  3. Wat zit er precies in de prijs, en wat niet? Denk aan ontwerp, beheeromgeving, publicatie in de stores, hosting en de eerste maanden na lancering.
  4. Hoe zie ik de voortgang? Een werkende versie per week of twee is beter dan een demo aan het eind.
  5. Wat gebeurt er als ik iets wil veranderen? Vraag naar een concreet voorbeeld van hoe ze dat eerder oplosten.
  6. Van wie zijn de code en de accounts? Zorg dat je App Store- en Google Play-accounts op naam van je eigen bedrijf staan, en spreek af wat er met de broncode gebeurt.
  7. Wat gebeurt er na de lancering? Wie lost bugs op, wie doet updates voor nieuwe iOS- en Android-versies, en wat kost dat?
  8. Waarom zou ik het níet bij jullie doen? Een eerlijke partij kan je vertellen voor welke projecten ze niet de juiste keuze zijn.

Rode vlaggen

  • Een prijs binnen een uur, zonder dat er vragen over je gebruikers en je doel zijn gesteld.
  • "Alles kan" en geen enkel voorstel om iets te schrappen voor de eerste versie.
  • Geen werkende versie tot vlak voor de deadline.
  • Onduidelijkheid over wie de accounts, de code en de data bezit.
  • Je praat steeds met iemand anders, en niemand weet precies hoe ver het project is.

Tip: vraag twee of drie partijen om een voorstel op basis van dezelfde korte beschrijving, en vergelijk niet alleen de prijs maar vooral wat ze voorstellen te schrappen. Daar zie je wie er echt over je product heeft nagedacht.

Hoe wij het aanpakken

Gain Impact is een klein softwareteam dat precies voor dit budget werkt. Na een gratis intake leggen we de scope vast en krijg je één vaste prijs en een vaste deadline. Je hebt één aanspreekpunt, ziet elke week een werkende versie, en we bouwen de app voor iOS en Android vanuit één codebase. Na betaling is de broncode van jou, zodat je nooit vastzit aan ons. Zo bouwden we onder meer het bestelplatform van Tapp voor festivals, de app van Roof Connect voor dakdekkers en Spichaser, een app met kentekenherkenning.

Benieuwd of jouw idee binnen je budget past? Lees meer over een app laten maken, bekijk ons proces of plan een gratis intake.