Stel je voor dat je naar de winkel gaat om een tv, een auto, een mobiele telefoon, of iets anders te kopen. Hoeveel gaan die producten je kosten?
Neem bijvoorbeeld een TV. Je kunt er een kopen voor misschien €200,- tot €500,-, wat een tv zou zijn zonder veel geavanceerde functies en een lagere resolutie. Of je kunt er een kopen van €1000,- tot €5000,-, wat een veel betere set functies, een top resolutie en de beste kijkervaring op de markt zou garanderen.
Een auto kopen? Hetzelfde verhaal. Het basismodel is verkrijgbaar vanaf €30.000,-. Zodra je naar wens opties begint toe te voegen, kun je dat totaal gemakkelijk richting de €45.000,- tot €60.000,- krijgen. Wanneer je voor een duurder merk kiest, zullen die prijzen zelfs nog meer stijgen.
Hoe dan ook, ik denk dat je mijn punt begrijpt. Hoe meer je wilt, hoe meer het gaat kosten.
Deze regel geldt ook wanneer je een app wil laten maken. De prijs is echter nooit zo in steen geschreven zoals bij de hierboven genoemde producten. Bij het ontwikkelen van software zijn er zoveel variabelen en onzekerheden waarmee rekening moet worden gehouden.
Een knop is zelden zomaar een knop, er zit logica achter de knop om deze te laten werken. Die logica kan voor elke knop weer anders, en mogelijk complexer zijn. Dit betekent dat het moeilijk is om vaste prijzen te bepalen voor verschillende onderdelen/functies van een applicatie*.
* Dit is ook gelijk waarom online calculators niet werken.
Laten we teruggaan naar de knop als voorbeeld. De visuele knop zelf is misschien vrij eenvoudig te bouwen, ja dat klopt. Die knop activeert echter een actie. Voor elke knop kunnen de acties anders zijn. Eén knop kan het uploaden van een formulier activeren, en de andere knop kan een heel proces voor een bezorgsysteem activeren.
Het is niet de tastbare knop die het meeste kost, het is wat er gebeurt wanneer een eindgebruiker op de knop drukt dat het grootste deel van de kosten bepaalt.
Bovendien zit er achter een applicatie van de hoogste kwaliteit een heel team bestaande uit meer dan enkel de ontwikkelaars. Dan hebben we het over een team met een projectmanager, een bedrijfsanalist, een UX/UI-ontwerper, meerdere ontwikkelaars en een QA-specialist.
Hoewel het moeilijk te voorspellen is, zijn hier enkele niets verbloemende indicaties om je in ieder geval een idee te geven:
Houd er rekening mee dat deze cijfers indicatief zijn en kunnen variëren afhankelijk van jouw use case.
Hoewel er geen vaste prijs is voor features en/of onderdelen van een applicatie, is het wel mogelijk om in kaart te brengen welke factoren de kosten van jouw applicatie bepalen.
Als het gaat om de ontwikkeling van een applicatie komen er natuurlijk veel technologische keuzes bij kijken. Welke programmeertalen zijn er mogelijk voor jouw use case? Zijn er andere systemen waarmee de app moet communiceren? Wil je iOS, Android, Windows, Web of allemaal?
Allereerst is er altijd de keuze welke programmeertaal/platform te gebruiken.
Wil je jouw kosten beperken, je flexibiliteit vergroten en de time-to-market verkorten? Overweeg dan een platformonafhankelijke (cross platform) technologie (zoals React Native). Hiermee kun je voor meerdere platforms tegelijk ontwikkelen.
Hoewel je bij cross-platform ontwikkeling niet alles kunt gebruiken wat je wel kan bij native ontwikkeling (lees hieronder), is het ruim voldoende voor de meeste applicaties die we tegenkomen.
Ben je van plan om een complexe en data-intensieve applicatie te ontwikkelen? (bijvoorbeeld applicaties die zware technologie gebruiken zoals AR/VR.) Dan zit je eigenlijk vast aan een native applicatie. Dit betekent een applicatie met afzonderlijke codebases voor verschillende platforms en geschreven in platform specifieke programmeertalen (bijvoorbeeld Swift voor iOS en Kotlin voor Android).
Native ontwikkeling kost meer omdat er voor twee of meer platformen tegelijkertijd ontwikkeld wordt. Als gevolg hiervan duurt de ontwikkeling langer en vereist het meestal meer onderhoud. Aan de andere kant presteert een native applicatie altijd beter dan een cross-platform app en zorgt het voor de beste gebruikerservaring die er te bieden valt.
Als je erachter bent welke programmeertaal of platform je moet gebruiken, moet je een duidelijk beeld krijgen van andere systemen en verbindingen die geïntegreerd moeten worden om je product te laten functioneren.
In de meeste gevallen zijn er meerdere systemen die verbonden moeten worden met jouw applicatie. Ook hier geldt weer, hoe meer verbindingen en integraties er moeten worden geïmplementeerd, hoe meer het gaat kosten. Welke systemen zijn vaak verbonden met applicaties, vraag jij je misschien af?
Contentmanagementsystemen (CMS): CMS wordt gebruikt om content die in jouw applicatie moet worden weergegeven eenvoudig te beheren, te bewerken en te publiceren. Deze systemen zijn meestal intuïtief in gebruik en stellen jou in staat om de inhoud in de applicatie te beheren zonder dat daarbij ontwikkelaars nodig zijn.
Databases: de meeste bedrijven willen de gegevens die de applicatie genereert opslaan. Vaak moet je dit willen om de gegevens vervolgens te kunnen gebruiken voor analyses. Hoe gedraagt mijn gebruiker zich? Zijn er optimalisaties te maken in de gebruikerservaring? Wie zijn mijn gebruikers? Antwoorden op deze vragen leiden tot datagedreven beslissingen die cruciaal kunnen zijn voor een positieve return on investment (ROI).
Ook het hosten van je applicatie en het opslaan van de data gaat een groter deel van de kosten uitmaken dan je denkt.
Interne software: heeft jouw bedrijf nog andere interne programma's die essentieel zijn om de app goed te laten functioneren? Denk bijvoorbeeld aan een ERP/CRM-systeem. Misschien wil je een app waarmee jouw mensen in het veld offertes kunnen opstellen of een bestelling kunnen plaatsen. Deze acties moeten terug te vinden zijn in het ERP/CRM-systeem om de financiële feiten af te handelen en het verkoopproces te ondersteunen. Of is er misschien een koppeling nodig met jouw bedrijfswebsite?
Hardware: Mogelijk heb jij een software product dat een uitbreiding is van jouw hardware product. Denk bijvoorbeeld aan een slimme verwarming die je met een app aan- en uitzet, monitort en configureert. De gegevens moeten worden overgedragen van de kachel naar de app en vice versa. Er is dan dus een verbinding tussen die twee nodig.
Natuurlijk vormen de features en ontwerpen een groot deel van de kostenstructuur. Je kent misschien niet elk detail van de functies en ontwerpen die jij nodig hebt. Dat is geen probleem. Door een aantal vragen te beantwoorden krijg je een duidelijk beeld van wat jouw wensen inhouden.
Wat moet jouw product (minimaal) doen om de problemen van de eindgebruiker op te lossen? Als je daar eenmaal een duidelijk beeld van hebt, kun je een lijst te maken met functies die nodig zijn om dat te ondersteunen. Hier zijn enkele functies waar je aan kunt denken:
De grootste fout die je kunt maken, is het maken van ontwerpen die jij mooi vindt. Het gaat niet om jou. Het gaat om de mensen die het gebruiken. Je moet ze iets geven dat ze graag gebruiken en, nog belangrijker, graag blijven gebruiken.
Beantwoord de volgende vragen zeer gedetailleerd om een startpunt te definiëren voor jouw gewenste ontwerpen. Wie is jouw gebruiker? Wat vinden ze leuk? Welke andere apps gebruiken ze?
Welke beslissingen moet jij nemen als het gaat om het ontwerp?
Kleuren: de manier waarop je kleuren gebruikt in uw mobiele applicatie hoeft niet alleen te worden afgestemd op de merkidentiteit. Verschillende kleuren wekken verschillende emoties op bij jouw gebruikers. Zwarte ontwerpen geven mensen bijvoorbeeld het gevoel van hoge kwaliteit en verfijning, terwijl oranje en geel vaak als leuk worden ervaren.
Lettertypen: welke lettertypen gebruik je? Welke grootte moeten ze zijn? Is je doelgroep wat ouder? Maak het lettertype groter en kies er een die gemakkelijk te lezen is (zoals Arial of Helvetica). Is jouw doelgroep van een jongere generatie en dol op een moderne stijl? Kies een modern lettertype (zoals Work Sans), maar overdrijf het niet. Als het moeilijk te lezen is, is de kans groot dat zelfs jouw modernste gebruikers niet blijven plakken.
Afgerond of rechthoekig: ga je voor een moderne en speelse applicatie, dan kun je overwegen om te gaan voor knoppen met afgeronde hoeken en wat afgeronde vormen door de gehele app heen. Is de gebruiker meer gewend aan een formele stijl? Dan zijn rechthoekige hoeken meer geschikt.
Lay-out: hoe wil je dat de gebruiker door jouw applicatie navigeert? Kruip hierbij in het hoofd van je gebruiker. Wat moet de gebruiker bereiken bij het gebruik van de app? Hoe krijg ik ze daar het meest effectief? Neemt de voorgestelde lay-out de gebruiker echt bij de hand en brengt de layout ze precies daar naartoe waar jij ze wil hebben?
Iconen versus tekst: het gebruik van iconen is behoorlijk populair binnen ontwerpen. Je moet er echter wel zeker van zijn dat jouw gebruiker de iconen begrijpt wanneer je geen ondersteunende tekst toevoegt. Je kunt bijvoorbeeld een optie tonen om in te loggen met je Google account, door middel van een knop die alleen het Google-logo laat zien. Je zou ook een knop kunnen gebruiken die zegt: ‘inloggen met Google’, met het Google-logo ernaast. Zou jouw gebruiker de knop zonder tekst begrijpen? Dan is dat de beste optie om het ontwerp minimalistisch te houden. Gebruik anders altijd een ondersteunende tekst.
Schermen: Hoeveel schermen heb je nodig? Te veel schermen kan verwarrend zijn, maar te veel informatie op één pagina kan ook verwarrend zijn. Zolang de informatie op één pagina een logische samenhang heeft met al het andere, kun je het in principe op hetzelfde scherm plaatsen.
Het belangrijkste om te onthouden als het gaat om functies en design, is dat je altijd klein moet beginnen. Vaak zul je zien dat je maar een fractie van de vooraf opgestelde functies nodig hebt om het grootste probleem van je gebruikers op te lossen.
Nadat je een lijst hebt opgesteld, stel jezelf de volgende vraag: wat is de kern van jouw waardepropositie (wat is het grootste probleem dat jouw app zal oplossen?)?
Ga dan terug naar je lijst en kijk welke functies daadwerkelijk direct bijdragen aan het oplossen van dat probleem. Als je echt eerlijk bent, zul je snel zien dat een groot deel van de functies niet in de eerste versie van jouw product hoeft.
Zelfs als je het budget hebt om de hele applicatie in één keer te laten bouwen, doe het dan niet. De eerste versie die het grootste probleem aanpakt, gaat je zoveel inzichten geven. Het opdelen in kleine stappen gaat je helpen om erachter te komen wat jouw gebruikers graag willen van jouw applicatie. Deze inzichten kunnen de plannen die je voor ogen had compleet veranderen.
Een ander groot deel van de kosten komt op rekening van het team dat wordt ingezet om jouw app te realiseren. Een goede applicatie wordt niet alleen door ontwikkelaars gebouwd. Het team achter een applicatie is meestal veel groter en diverser dan je denkt. Een volwaardig productontwikkelingsteam ziet er als volgt uit:
Developers: front-end developers om de mensen te geven wat het oog begeert. Back-end developers om ervoor te zorgen dat alles achter de schermen werkt.
Een UX/UI Designer: designers kruipen in het hoofd van jouw eindgebruikers. Ze gebruiken best practices om de gebruiker bij de hand te nemen vanaf het moment dat ze de applicatie voor het eerst openen.
Een QA-specialist: dit zijn de mensen die er zijn om jou gemoedsrust te geven op de lanceringsdag. Ze zorgen ervoor dat je app zonder bugs wordt gelanceerd en garanderen vanaf het begin voor een optimale gebruikerservaring.
Een bedrijfsanalist: Bedrijfsanalisten zijn degenen die ervoor zorgen dat alle belanghebbenden op dezelfde lijn zitten. Zij vertalen jouw wensen naar ontwikkelbare feature beschrijvingen voor ontwikkelaars en vertalen technische eisen/complexiteiten op een manier die ook voor niet technische mensen begrijpelijk zijn.
Een projectmanager: de projectmanager zorgt ervoor dat de planning, het budget en de teamspirit op pijl blijft en jouw app op tijd naar de markt kan.
Als je succesvol wil zijn op de markt, moet je applicatie van de hoogste kwaliteit zijn. Goede mensen leveren deze kwaliteit. Goede ontwikkelaars kosten echter ook geld. Dat is iets wat je niet mag onderschatten.
Nadat jouw applicatie de markt op is gegaan, stopt de ontwikkeling niet zomaar. Je moet jouw mobiele/web applicatie blijven verbeteren, bijwerken en vernieuwen om deze up-to-date te houden en aan de verwachtingen van uw gebruikers te voldoen.
Als het een app is die complementair is aan jouw bedrijf, is dit misschien een minder groot deel van de kosten. Dit kan bijvoorbeeld een app zijn waarmee jouw mensen in het veld formulieren, aanbiedingen en foto's over een specifieke opdracht kunnen uploaden. Deze app moet werken zoals de gebruikers dat willen en moet worden verbeterd waar de app niet past bij de wensen van de gebruikers.
Als jouw hele bedrijf draait op het bestaan van uw applicatie, ben je hoe dan ook aanzienlijke bedragen kwijt aan continue ontwikkeling. Het verbeteren, bijwerken en updaten van uw applicatie is op dit moment jouw core business.
Het eerste dat je waarschijnlijk wil ontvangen wanneer je aan jouw onderzoek begint, is een kosteninschatting voor de applicatie die je wil laten bouwen. Dat is logisch. Om je een nauwkeurige schatting te kunnen geven, moet jouw software partner zoveel mogelijk informatie hebben om een zogenaamde rough order of magnitude (ROM) te maken.
De ROM geeft u een ruwe schatting van de kosten en tijd die nodig zijn om uw applicatie te ontwikkelen. Een ROM is echter zo nauwkeurig als maar kan op dat moment. Vaker wel dan niet, zal deze schatting aan de lagere of hogere kant van de uiteindelijke kosten liggen. 100% accuraat zal deze in de praktijk nooit zijn.
Informatie die nodig is om zo'n ROM te maken variëert van wireframes, gebruikersverhalen, prototypes, stijlgidsen, functielijsten, prioriteiten, persona's, enz. Eigenlijk alles waar we het hierboven over hadden komt van pas.
Maak je geen zorgen als je deze materialen niet hebt. Je bent zeker niet de enige. Het is mogelijk om wat hulp te krijgen bij het maken van die materialen. De meeste software bedrijven bieden zogenaamde discovery workshops/sessies aan. Hier wordt jij begeleid door een team van ontwikkelaars, analisten en verkoopspecialisten om je te helpen de best mogelijke technologische beslissingen te nemen voor jouw applicatie en jouw bedrijf.
Zoals je kunt lezen, komt er best wat kijken bij de ontwikkeling van een app. Hoe je het ook bekijkt, je gaat waarschijnlijk meer uitgeven dan je aanvankelijk dacht.
Door gebruikersgericht te zijn, kun je de behoeften van jouw gebruikers echt leren begrijpen en de ontwikkelingsplannen aan de hand daarvan ontwerpen. Je bereikt dit door uit te zoeken wat het grootste probleem is dat je applicatie oplost en je markt een kleine versie van je product te geven die dat probleem daadwerkelijk oplost. Vervolgens kun je hiermee gebruikersfeedback genereren om erachter te komen welke problemen je nog meer kunt/moet oplossen met nieuwe versies van je product.
Ja, je zult geld uitgeven. Echter, door klein te beginnen en de gebruiker centraal te stellen in jouw ontwerpproces, kun je de kosten tot het minimum beperken en wordt het geld dat je wel uitgeeft besteed aan het bouwen van features die daadwerkelijk de juiste problemen oplossen.
-cropped.png)
