Apperium - Wat kost een app om te laten bouwen? (en waarom de manier waarop je het vraagt het antwoord bepaalt)
Tech
De duurste fout die ik in twaalf jaar app-bouwen heb gemaakt was een fixed price project.
Niet omdat dat ene project zo'n drama was. Omdat fixed price als constructie ervoor zorgt dat je als bureau óf te veel rekent óf te weinig levert. Allebei is slecht voor de klant. En allebei is precies wat klanten gegarandeerd krijgen als ze met een vraag om een vaste prijs op pad gaan.
Dit is een blog over wat een app kost. Maar het is vooral een blog over hoe je die vraag moet stellen, want de vraagstelling bepaalt het antwoord meer dan welk bureau dan ook.
Ik geef je verderop concrete bedragen per fase. Maar eerst moet ik uitleggen waarom de meest gestelde vraag in mijn vakgebied zelden een goed antwoord oplevert.
Waarom "wat kost een app" geen eerlijke vraag is om te stellen
Stel je gaat een huis bouwen. Je belt drie aannemers en vraagt: wat kost een huis.
Niemand zou daar een serieus antwoord op geven. Want het hangt af van het kavel, de grond, de afmetingen, het type fundering, het materiaal, de afwerking, de installaties, de regio. Een serieuze aannemer stelt eerst een paar uur lang vragen voor hij een bedrag noemt.
Bij apps gebeurt het tegenovergestelde. Klanten bellen drie bureaus, geven in tien minuten een korte uitleg, en verwachten een offerte. De bureaus die meedoen aan dat spel geven die offerte ook. Met een vast bedrag. Vaak in een powerpoint met fasen die scherp lijken.
Wat er dan gebeurt is voorspelbaar. Het bureau heeft de offerte gemaakt op basis van aannames die niet kloppen, want hij heeft de tijd niet gehad om er goed naar te kijken. Tijdens het project blijkt de werkelijkheid anders dan de offerte. Twee dingen kunnen er nu gebeuren.
Of het bureau bouwt door volgens de offerte en levert iets op dat niet matcht met wat de klant nodig heeft. Goedkoop op papier, duur in werkelijkheid, want de klant zit met een app waar hij niet mee verder kan.
Of het bureau komt halverwege met meerwerk. De klant baalt, want de prijs gaat omhoog. Het bureau baalt, want het voelt smerig om dat gesprek te voeren. En het project loopt vertraging op, want elk stukje meerwerk moet eerst onderhandeld worden voor het gebouwd kan worden.
Beide uitkomsten zijn slecht. En beide zijn het directe gevolg van de vraag aan de voorkant: wat kost een app, in een vaste prijs, vooraf vastgelegd.
Waarom serieuze app-bureaus niet meer in fixed price werken
Ergens in de afgelopen tien jaar is in de softwarewereld het inzicht doorgebroken dat je software niet bouwt zoals je een huis bouwt. Bij een huis kun je vooraf alles uittekenen, want het huis verandert niet meer als hij staat.
Een app verandert wel. Sterker nog, hij móet veranderen. Wat je in januari hebt bedacht, blijkt in maart anders te liggen omdat je gebruikers het anders gebruiken dan je dacht. Wat je voor de zomer wilde lanceren, schuif je naar het najaar omdat je iets belangrijkers tegenkomt onderweg. Dat is geen falen, dat is gezond bouwen.
Fixed price gaat ervan uit dat je in januari precies weet wat je in december wilt hebben. In ons vakgebied is dat een leugen. En een dure.
Daarom werken wij in sprints, met heldere bandbreedtes per fase. Je weet vóór elke sprint wat hij gaat opleveren en wat hij gaat kosten. Na elke sprint beslis je of je doorgaat, bijstuurt of stopt. Je betaalt voor wat je krijgt, niet voor wat ooit op een powerpoint stond.
Dat is geen marketingverhaal. Dat is gewoon hoe je software bouwt zonder achteraf spijt te hebben.
Wat een app kost: de eerlijke bedragen per fase
Goed. Nu de bedragen waarvoor je waarschijnlijk gekomen bent. Ik geef je bandbreedtes, omdat de werkelijkheid bandbreedtes is.
Discovery (ongeveer 2.500 euro)
Voor we ook maar één regel code schrijven, gaan we in een dag het hele idee scherp krijgen. Wat ga je bouwen, voor wie, met welk doel, welke fundering. Aan het einde van die dag heb je een helder concept en een realistische inschatting voor het vervolg.
Dit lijkt een uitgaaf, maar het is vrijwel altijd je goedkoopste investering. In die ene dag worden beslissingen genomen die je anders pas in maand vier had genomen, en dan tegen veel hogere kosten omdat er al dingen omheen gebouwd zijn.
Design sprint (ongeveer 6.000 euro)
In deze fase ontwerpen we hoe de app eruitziet en werkt. Niet als artistieke oefening, maar als blauwdruk waar daarna concreet op gebouwd wordt. Klikbare prototypes die je kunt voorleggen aan echte gebruikers voordat er code geschreven is.
Dit is de fase waarin bijsturen goedkoop is. Een knop verplaatsen in een ontwerp duurt vijf minuten. Hetzelfde doen in werkende code duurt een dag. Reken dus uit hoe waardevol het is om hier even goed te zitten.
Onboarding (in de design sprint inbegrepen)
Voordat we kunnen bouwen, moet alles aan onze kant geregeld zijn. Toegang tot systemen, integraties met je backend, accounts in de app stores, design assets, content. Dit gebeurt parallel aan het einde van de design sprint, zodat we direct door kunnen wanneer development start.
Development sprints (10.000 tot 25.000 euro per sprint)
Hier wordt de app gebouwd. Per sprint van een paar weken. Elke sprint eindigt met een werkende, geteste versie die je in handen krijgt. Geen maanden radiostilte gevolgd door een grote onthulling.
Voor een gemiddelde MVP heb je minimaal twee tot drie sprints nodig. Een eenvoudige app komt soms uit met twee, een complexere met meer. Wat het exact wordt hangt af van wat je wilt bouwen, hoeveel integraties er zijn, en hoeveel platformen je bedient.
Soms voegen we een sprint nul toe, een proof of concept. Dat doen we als er technisch iets onzeker is dat je vooraf wilt valideren voor je in de volledige bouw stapt. Bijvoorbeeld een complexe integratie die je eerst in het klein wilt testen.
Belangrijk om te weten: elke sprint eindigt met een livegang. Je hebt na sprint één al iets in handen dat werkt. Niet alle features, maar wel iets. Dat betekent dat je na elke sprint kunt beslissen of je verder gaat of stopt. Je zit nooit vast aan een traject van een jaar.
SLA en onderhoud (150 tot 500 euro per maand)
Een app heeft onderhoud nodig nadat hij live staat. Updates van iOS en Android, beveiligingspatches, kleine bugfixes, hosting van je backend, monitoring. Dat regelen we met een service level agreement vanaf 150 tot 500 euro per maand, afhankelijk van hoe complex je app is en hoe snel je wilt dat we reageren als er iets is.
Dit is geen optie maar een noodzaak. Een app waar je geen onderhoud op pleegt, werkt na een jaar of twee niet meer. Apple en Google brengen elk jaar nieuwe versies uit van hun besturingssystemen die kleine of grote aanpassingen vragen. Hou daar rekening mee in je business case.
Doorontwikkeling (10 tot 20 procent van je initiële kosten per jaar)
Naast onderhoud wil je vrijwel altijd doorontwikkelen. Nieuwe features, verbeteringen op basis van gebruikersdata, uitbreidingen omdat je business groeit. Reken op 10 tot 20 procent van je initiële investering per jaar als budget voor doorontwikkeling.
Apps die ROI opleveren, doen dat omdat er na livegang actief mee bezig wordt gebleven. De apps die stilstaan, leveren niets op.
Een rekenvoorbeeld
Even concreet. Voor een MVP-app van middelmatige complexiteit, twee platformen, met een degelijke fundering, ziet het er typisch zo uit:
Discovery: 2.500 euro. Design sprint: 6.000 euro. Drie development sprints van gemiddeld 17.500 euro: 52.500 euro. Totale initiële investering: ongeveer 61.000 euro.
Vervolgens jaarlijks: SLA op 300 euro per maand komt uit op 3.600 euro per jaar. Doorontwikkeling op 15 procent komt uit op ongeveer 9.000 euro per jaar. Jaarlijks vervolg: ongeveer 12.600 euro.
Dat is een eerlijk plaatje. Geen lokkertje, geen vaste prijs op een idee dat nog niet helder is. Een opbouw waarin je per fase weet wat je krijgt en wat je betaalt.
Voor sommige projecten is een bedrag als dit overschat. Voor andere fors onderschat. Daarom geven we vóór de discovery dag geen bedrag. Niet omdat we iets verbergen, maar omdat een eerlijk antwoord een uur of zes goed nadenken vraagt en dat is precies wat de discovery dag is.
Wat je hieraan hebt
Als je nadenkt over een app, kies dan een bureau dat in deze structuur werkt. Niet omdat wij de enigen zijn, dat zijn we niet. Maar omdat de bureaus die nog steeds met fixed price offertes de boer op gaan, structureel óf te duur óf onbetrouwbaar zijn. Allebei is duur.
En tweede tip: laat de hoogte van de offerte niet leidend zijn in je keuze. Het bedrag dat je in jaar één betaalt is zelden de bepalende factor in of een app slaagt. De vraag is: bouwt dit bureau iets dat over drie jaar nog meegroeit met je business, of bouwt het iets dat na een jaar tegen technische schuld aanloopt en herbouwd moet worden.
Goedkoop is duur als je twee jaar later opnieuw mag beginnen.
Wil je weten wat een app concreet gaat kosten in jouw geval? Bel ons en we plannen een discovery dag. Aan het eind van die dag heb je een helder concept én een eerlijk bedrag voor het vervolg. Geen offerte op aannames, maar een berekening op basis van wat we samen scherp hebben gekregen.