Wat kost een app (die snel winst maakt)?

Wat kostte een app laten maken ook alweer?

Veel lezers bleken erg geïnteresseerd in de geschatte kosten van een app laten maken. Het blijkt behoorlijk onbekend terrein voor mensen met een app idee, zeker wanneer je niet eerder in de wereld van de apps hebt verkeerd. Het antwoord is echter vrij concreet, zoals ik hier eerder uitlegde:

Tijd is geld, en een app maken kost best wat tijd. Je mag uitgaan van maanden werk, als je het laat doen door een bureau. Daar zit tenslotte de expertise om jouw idee goed te verwezenlijken tot een mooie eerste versie app die de store in kan. En zoals ik in het eerdere artikel al zei: 

“Hoe je het ook wendt of keert; kwaliteit, expertise, software, tijd en fases in je project – die dingen kosten geld."

Nog iets concreter. Een paar maanden werk, een team van professionals: reken maar op “startkosten die tussen de 10k en de 25k liggen, omdat goede software nu eenmaal duur is” (rechtstreekse quote van Tweakers). 

Starten én (door)gaan!

In de (correcte) quote van Tweakers over de kosten van een app hierboven zie je namelijk nog iets opvallends, naast het bedrag waar het om draait… Ze spreken ook van “startkosten”. En ook daar hebben ze gelijk.

Want een app laten maken is geen kwestie van één keer €10.000 er tegenaan gooien. Dat zijn de startkosten. Omdat een app maken geen kwestie is van één keer bouwen en live zetten. Het gaat dóór, na de start. 

Een app kost meer geld

En dat is goed nieuws. 

Want meer investeren in je app levert meer op, en je uitgaven worden ook nog eens netjes uitgesmeerd over de tijd. Om dat te vatten, moeten we even terug naar het proces van een app laten maken. De werkwijze van software engineers en developers. 

Onze lean of agile werkwijze bedoel ik dan; die betekent dat je een app bouwen in fases doet. 

Wat je laat maken met je startkosten is namelijk een “Minimum Viable Product” (MVP). En zoals de naam al zegt: het is de meest minimale versie van het eindproduct. De kern van het totaalconcept. Het allerbelangrijkste zit erin, de rest is (nog) weggelaten. Het minimale dat je nodig hebt om het te kunnen lanceren als bruikbare app. 

Niet om jou minder te geven dan je nodig hebt, maar om je precies te geven dat je nodig hebt om te beginnen. Zodat je snel live kan met je app, om te zien hoe hij valt bij gebruikers. Om data driven verder te werken, in plaats van blind verder te werken aan je app. Omdat hij daar beter van wordt. 

Een paar goede redenen om eerst zo’n MVP versie van je app te lanceren is namelijk:

• De eerste kosten voor het bouwen van je app zijn relatief laag.
• Je kunt snel live met je app.
• Je kunt al snel geld verdienen met je app, in gewonnen tijd of klinkende euro’s.
• Je gebruikers kunnen er snel mee aan de slag.
• Je gebruikers kunnen je snel (via gebruikersdata) laten zien wat er goed gaat en wat er beter kan.
• Foutjes en problemen kom je in een vroeg stadium tegen, wanneer ze nog snel en gemakkelijk op te lossen zijn.

In plaats van dat je een klein jaar investeert in ontwikkelkosten, alleen om er dan achter te komen dat de app in een eerder stadium al anders ingericht had moeten worden, omdat blijkt dat gebruikers er nu niet goed mee overweg kunnen, of er nieuwe kansen ontdekt worden die zijn blijven liggen en je achteraf niet meer flexibel kunt inbouwen. 

Flexibiliteit is wat je wint. Lean en agile werken is dat, letterlijk vertaald. De beste manier om te werken aan een app.

Dat is dus je MVP. Fase één. De basis, om op dóór te bouwen. Met structuur.

Gestructureerd app ontwikkelen (voor snellere winst)

Je gaat dóór. Want een app ontwikkelaar is nooit klaar. En ook dat is een goede zaak. Want hier begint het echt leuke gedeelte pas, voor ons. En het meest interessante gedeelte voor jou, als klant met bepaalde KPI’s en een bepaald business model. Dat is waarop je het doorbouwen namelijk baseert, voor maximale en zo snel mogelijk opbrengsten uit je app. 

Ten eerste, toegelicht: je hebt je KPI’s, voor structurele groei. 

Doelen die je wil behalen met je app. De pijlen op die doelen richten doe je meteen vanaf het begin, zodat je altijd de juiste weg naar die doelen blijft volgen. Met als indicatoren van de juiste weg: de data die uit je app komen rollen, en de reacties van gebruikers. 

Ten tweede hebben we het over: je business model, voor structurele groei. 

Dat is het concept waarin je je app zo winstgevend mogelijk maakt, zo snel mogelijk. Iets dat dus juist op deze manier gebeurt. Je begint met een vast startkapitaal: de startkosten voor de MVP versie van je app. Die versie gaat online en zorgt er direct voor dat je de beoogde winst al gaat boeken (volgens je KPI’s). De kosten die je terugverdient, kun je opdelen: een deel voor jou, en een deel om de app door te ontwikkelen. Of alles om de app door te ontwikkelen, als de situatie dat toelaat, afhankelijk van hoe snel en hard je vooruit wil en kan. 

Die investering op basis van geboekte winst schuift zo steeds verder op: je app verdient steeds meer en percentueel hoef je steeds minder in de app te steken. Wat betekent: meer winst voor jou(w organisatie). Dat is waar je naartoe werkte. 

Maar hoe?

3x hoe je je MVP app doorontwikkelt

Als app ontwikkelaars gaan we precies daarom na de lancering van het MVP door naar de volgende fase(s), in deze 3 varianten:

1. Optimalisatie

Terwijl de app draait en er telkens nieuwe features bij komen, blijf je ook in de gaten houden wat al die functionaliteiten doen. Hoe ze presteren. Hoe ze in de smaak vallen bij gebruikers. En of je app de gebruiker daar brengt waar jij hem wil hebben, volgens je KPI’s. (“Key Performance Indicators”: vooraf opgestelde indicaties om te bepalen of de app doet wat hij moet doen.)

Voornamelijk op basis van gebruikersdata bepaal je wat goed werkt en wat beter kan. Wat er mist, misschien zelfs. Of wat echt overbodig is en weggelaten kan worden in de app. Data driven werken; doen we graag. Omdat het werkt. Je gist niet naar wat er beter kan of anders moet, je weet het, doordat de feiten voor je neus liggen. Bovendien is op deze manier de gebruiker van de app leidend. Zijn of haar ultieme tevredenheid over het gebruik van app is tenslotte wat je wil bereiken. 

Echter: de gebruiker mag leidend zijn, en wij kunnen adviseren wat we willen op basis van onze data… De klant – of “product owner” in onze werktermen – bepaalt uiteindelijk wat er wel en niet geoptimaliseerd wordt, vaak op basis van het budget. Precies waar we het hier over hebben. Wie betaalt, bepaalt ;)

2. Doorontwikkeling

“Het allerbelangrijkste zit erin, de rest is (nog) weggelaten” noemde ik net bij het omschrijven van de MVP-fase. De rest, dat is de doorontwikkeling. Het zijn de features die later, volgens een zorgvuldig aangebrachte prioritering in de zogenaamde “roadmap” – het doorontwikkelingsplan – telkens op hun beurt worden toegevoegd aan de app. Elke nieuwe fase waarin een of meerdere nieuwe features worden toegevoegd, noemen wij een “iteratie”: een periode van bijvoorbeeld 2 weken die in dienst staat van een vooraf bepaalde doorontwikkeling, die aan het einde van die 2 weken staat.

Bijvoorbeeld:

In de MVP versie van je app kun je foto’s maken van werkbonnen en uploaden naar een server. In de doorontwikkeling voeg je daar de feature toe dat je de foto in een bepaalde map in de server kan plaatsen. En vervolgens de feature om er een notitie aan toe te voegen voor een collega. Vervolgens… –

Zo gaat het door. Totdat alle bedachte en gekozen features uit de “backlog” – de verzameling features om ooit toe te voegen aan de app – zijn ontwikkeld. 

Dat is doorontwikkeling. Noodzakelijk voor een app die niet alleen de broodnodige basics in z’n systeem heeft (de MVP versie), maar die steeds een beetje beter werkt en de gebruiker steeds een beetje beter bedient.

3. Onderhoud

De derde en minst spannende factor die speelt na het lanceren van je app, is het onderhoud ervan. Meteen ook de variant doorontwikkeling die het minst investeringsintensief is. Er wordt hier namelijk niks toegevoegd of verbeterd, maar gewoon gezorgd dat wat er staat blijft functioneren zoals het hoort. De status quo behouden. 

Dat betekent niet dat je er van uit mag gaan dat features en functionaliteiten gaandeweg kapot gaan en gemaakt moeten worden. Zeker niet. Je moet bij deze categorie eerder denken aan algemene updates doen vanuit de open source software – de taal waarin de app gebouwd is – zodat je app blijft werken zoals bedoeld. 

Of denk aan koppelingen met andere software die bijgeschaafd moet worden omdat daar iets in de code veranderd is, waardoor hij niet meer vanzelf naadloos aansluit op de feature in de app. Je maakt bijvoorbeeld gebruik van een bankkoppeling voor iDeal-betalingen, en de Rabobank verandert iets in hun code. Dan moet je dat vaak even doorvoeren zodat alles netjes blijft werken. 

Dat is app onderhoud.

Dus, samengevat, de 3 vormen waarin je aan een app blijft werken na lancering:

• Optimalisatie – bestaande features verbeteren, op basis van KPI’s.
• Doorontwikkeling – app features uitbreiden, op basis van de backlog.
• Onderhoud – zorgen dat alle features blijven doen wat ze moeten doen.

Maar wat kost dat dan?

De cruciale vraag, waar je voor kwam. Je weet nu dat de kosten van het laten maken van de startversie van je app, slechts “startkosten” zijn. Je weet dat je daarna verder investeert, om een app te ontwikkelen die niet alleen blijft doen wat hij doet, maar ook telkens beter doet wat hij moet doen én steeds meer kan doen dan hij al doet. 

Dat is geen kwestie van méér kosten maken, maar je investering beter en slimmer verdelen. Met een deel vastgezet voor je initiële startkosten, om daarna zo snel mogelijk live te gaan en geld te verdienen met je app, zodat je met meer gemak verder investeert in de doorontwikkeling.

Zo bouw je niet één grote, complete app in één keer. Die enorme startkosten bedraagt én die niet meer flexibel (agile) genoeg is om bij te sturen in de juiste richting (van je KPI’s). Geen slim business model. Geen aanrader. 

Liever verdeel je je budget over de tijd, verzamel je gebruikersdata en -feedback voor verbetering, kun je netjes doorontwikkelen én houd je gaandeweg je app meteen up-to-date. Bovendien heb je in dit traject bij iedere stap de expertise en het inzicht van een creatieve strategische en technische club als Ketjapp tot je beschikking.

En in alle gevallen is de investering in een goede app een investering die je terugverdient. Want een betere app levert gewoonweg meer op. Hij bedient je klanten of je medewerkers – je app gebruikers – beter, wat meer conversie van je klanten of nog efficiënter werken door je werknemers betekent. In alle gevallen: winst (want tijdwinst is tenslotte ook geldwinst). 

Maar om bij die winst te komen, is een investering nodig. Lastig om concreet te benoemen, maar ik ga het toch proberen. Een richting geven, zodat je weet waar we het over hebben, als we het over kosten van een app na lancering hebben:

Houd rekening in je startbudget met 10% extra voor doorontwikkel-kosten, en daarna met 30% ontwikkelkosten van het initiële budget per jaar. Bij een app van €10.000 betekent dat dus €1.000 om te beginnen, en daarna zo’n €3.000 per jaar. 

(Lees hier hoe deze klant die investering telkens in no time terugverdient.)

Waar die euro’s naartoe gaan? Onze uren. Samen spreken we af hoeveel uren aan onderhoud, optimalisatie en doorontwikkeling gereserveerd worden. Denk aan een uur controle en 2 uur fix-tijd per maand, als we het over onderhoud hebben. Bij optimalisatie en doorontwikkeling werken we in sprints, van 2 weken – 10 werkdagen. 

Allemaal optioneel uiteraard, maar allemaal erg aan te raden, als je het mij vraagt. En dat zeg ik niet alleen omdat wij het verkopen. Hier spreekt mijn app-hart. Doe het goed, of doe het niet, is mijn motto. Doe ermee wat je wil :)