Design Wat kost het bouwen van een applicatie?
Prijzen van applicaties kunnen variëren van €10.000 tot €150.000, of zelfs buiten die range. Waarom is dat eigenlijk?
In de praktijk blijkt dat er veel onduidelijkheid bestaat over waarom de prijzen van applicaties zo kunnen variëren. Maar eigenlijk is het heel simpel te vergelijken met andere producten of diensten.
Neem bijvoorbeeld de kapper. Prijzen van kapsalons kunnen sterk variëren, zonder dat iemand hiervan opkijkt. Je gaat er gewoon vanuit dat de duurdere kapper betere werknemers in dienst heeft, betere materialen gebruikt en uiteindelijk waarschijnlijk een beter eindresultaat levert. Zo ook met schoenen. Sneakers zijn al te koop voor €15, maar toch kiezen echte sneaker-liefhebbers niet zelden voor een exemplaar van €150. Simpelweg omdat de duurdere variant (meestal) van duurder materiaal is gemaakt, langer meegaat en er flitsender uitziet.
Terug naar applicaties. Eigenlijk geldt hiervoor hetzelfde als bij andere producten en diensten. De prijs die je betaalt, zegt iets over wie je inhuurt en wat voor eindresultaat je uiteindelijk opgeleverd krijgt. Dit heeft dus te maken met de kwaliteit van de designers, developers en projectmanagers. Maar ook met ervaring en garanties op het eindresultaat.
Factoren die de prijs van een app bepalen
De prijs van een applicatie wordt voor een groot deel bepaald door de volgende hoofdfactoren, die hierna één voor één zullen worden besproken:
- Wat voor type applicatie je nodig hebt;
- Wie de gebruikers gaan zijn;
- Wie je inhuurt om de applicatie te bouwen;
- Hoe snel je online wilt met de applicatie;
- De scope van de applicatie.
Type applicatie
Bij het woord “app” denken de meeste mensen aan software die te downloaden is op je telefoon. Maar er zijn ook andere soorten applicaties. Welk type applicatie je nodig hebt, is sterk bepalend voor de prijs.
Waar de meeste mensen aan denken bij het woord “app”, is eigenlijk een native applicatie. Dit is het type applicatie dat je downloadt op je telefoon.
Het compleet tegenovergestelde hiervan is een web-applicatie. Deze apps hoef je niet te downloaden, maar kun je raadplegen via je webbrowser (zoals Google Chrome of Safari).
Daar tussenin bestaan nog hybride applicaties, Ionic applicaties en progressive web applicaties (voor een uitgebreid artikel over deze laatste soort, kijk hier). Zoals je waarschijnlijk begrijpt, heeft ieder type applicatie zijn eigen voor- en nadelen en is het ook sterk afhankelijk van je idee welk type applicatie je het beste kunt laten bouwen.
In het kort zou je het zo kunnen zien: native apps vertonen hogere performance en bieden meer mogelijkheden, maar duren langer om te maken en vergen meer onderhoud. Web apps vertonen lagere performance en kunnen geen gebruik maken van features zoals GPS, maar zijn wel sneller te bouwen en makkelijker te onderhouden.
Welk type applicatie je het best kunt kiezen, is vooral afhankelijk van de klanten voor wie je de applicatie bouwt. Daarover hieronder meer.
Voor wie laat je de app bouwen?
Heb je een goed idee voor een app? Heb je dan ook een duidelijk beeld van wie de gebruikers van jouw app worden?
Deze vraag bepaalt namelijk eigenlijk alle andere punten die de prijs van jouw app beïnvloeden. De doelgroep voor jouw applicatie heeft unieke behoeftes. En voor sommige doelgroepen zijn deze behoeftes duurder dan voor andere doelgroepen. Als jouw doelgroep veel complexe functionaliteiten nodig heeft, vergt dat meer tijd om te bouwen, wat de app duurder maakt. In sommige branches zal een applicatie ontzettend goed beveiligd moeten zijn voordat hij voor het eerst in gebruik genomen wordt. Hiervoor moet een applicatie, meer dan normaal, van voor tot achter en door- en door compleet getest worden. Dit kost tijd, en dus geld. Dan zijn er nog doelgroepen die alleen toegang hebben tot een desktop en geen mobiel apparaat. Dit beïnvloedt het type applicatie, wat vervolgens weer de prijs beïnvloedt.
Dit onderwerp wordt vaak overgeslagen bij het uitwerken van een applicatie-idee. Wij hopen hiermee te laten zien dat dit eigenlijk je beginpunt zou moeten zijn (nadat je een idee voor een app hebt bedacht, natuurlijk). Van hieruit kun je namelijk veel beter bepalen hoe de andere punten uit dit artikel het beste ingevuld kunnen worden. Zo bespaar je misschien onnodige kosten, of voorkom je dat goedkoop juist duurkoop wordt, omdat jouw app niet toereikend is voor je gebruikers.
Wie huur je in?
Deze factor is eigenlijk tweeledig:
- Wat voor type partij huur je in om jouw app te bouwen?
- Waar is deze partij gevestigd?
Het eerste punt is eigenlijk vrij simpel. Voor het bouwen van je applicatie kun je kiezen voor een freelancer of een bureau. Over het algemeen zijn freelancers goedkoper (hoewel dit niet altijd opgaat). Bij een bureau betaal je meestal meer, omdat er meerdere mensen (specialisten) op het project zitten en er vaak iemand in dienst is om het project te managen.
De locatie van de freelancer of het bureau heeft erg veel invloed op de prijs van de applicatie. Werken met freelancers of bureaus uit het buitenland kan de prijs met een derde tot de helft verminderen. Het brengt soms wel uitdagingen met zich mee zoals communiceren met tijdsverschil en een taalbarrière (en ja, vaak ook de kwaliteit van het werk).
Een tussenoplossing is een lokaal bureau dat óók buitenlandse developers op afstand aanstuurt. Zo heb je de voordelen van communiceren in je eigen taal en tijd, maar voor een lager tarief dan wanneer het complete bureau in Nederland is gevestigd.
Wanneer wil je online?
Het bouwen van een applicatie hoeft niet lang te duren. Vooral bureaus bieden vaak de mogelijkheid om sterk op te schalen, waardoor de ontwikkeling beduidend minder lang duurt. Daar tegenover staat dat er meestal extra kosten verbonden zitten aan het versnellen van het ontwikkelingstraject. Dit heeft o.a. te maken met de inzet van extra developers.
Waar vaak geen rekening mee gehouden wordt, is alle tijd die aan de ontwikkeling van de app voorafgaat. Het uitkiezen van de juiste partij om je app te bouwen bijvoorbeeld. Ga je praten met verschillende bureaus? Of kies je iemand van een freelance-platform? En als je eenmaal de juiste partij hebt gekozen, houd er dan rekening mee dat het tijd kost om het project in te plannen en op te starten.
Ook het compleet uitwerken van jouw idee samen met de projectmanager en/of developers kost tijd. Soms wordt hierop bespaard, wat achteraf tot teleurstellingen kan leiden. Wat voor jou super logisch is, kan voor een developer totaal niet vanzelfsprekend zijn. Een goed, grondig discovery traject kost misschien geld, maar zorgt er wel voor dat je achteraf niet hoeft te betalen voor veranderingen of toevoegingen.
Wat is de scope van de app?
Met de scope van een applicatie wordt een lijst van functies bedoeld die een app moet bevatten. In de regel is het zo dat hoe groter de scope, hoe duurder de applicatie. Als er dan ook nog complexe functies bij zitten, wordt de applicatie in de regel nog duurder.
Daarnaast horen we vaak: hoe groter de scope, hoe beter. Wij begrijpen de gedachte. Met meer mogelijkheden verwacht je meer succes te behalen met je applicatie.
Wij geven onze klanten echter altijd het advies om de scope voor de eerste versie of MVP zo klein mogelijk te houden. Zo kun je de app in gebruik nemen, je doelgroep beter leren kennen en al doende leren welke functies moeten worden toegevoegd en welke functies (die in eerste instantie op je lijst stonden) eigenlijk onnodig zijn. Dit voorkomt onnodige kosten voor een eerste versie, en zorgt er bovendien voor dat je eerder online kunt. Dit is altijd positief, want als je een origineel idee hebt geldt: hoe sneller mensen het zien, hoe beter!
Bij sommige applicaties is het goed mogelijk de scope bij de eerste versie relatief klein te houden. Dit heeft alles te maken met welke functies er absoluut onmisbaar zijn om jouw app te laten doen waar hij voor bedoeld is. Denk bijvoorbeeld aan een app om mensen met elkaar te laten chatten. Absoluut onmisbaar is de functie dat mensen met elkaar kunnen communiceren via chat. Andere functies die de bedenker van deze app wellicht in zijn hoofd heeft (zoals emoticons, lettertype-keuze, etc.) kunnen later toegevoegd worden.
Daarentegen móet een app van een vliegmaatschappij om vliegtickets te boeken een overzicht bieden van alle vluchten en prijzen, er moet een reservering kunnen worden geplaatst en er moet een betaalsysteem worden gebouwd. Zonder één van deze functies kan de applicatie zijn werk niet doen.
De beste manier om de scope van je app te verkleinen is een roadmapping sessie. In een goed discovery traject zal je hier uitgebreid mee te maken krijgen.
Kort maar krachtig: wat je kunt krijgen voor €1000, €10.000 en €100.000
Voor €1000:
- Een no-code prototype gemaakt door een freelancer;
- Een doe-het-zelf cursus om de basis te leren van programmeren;
- Heel veel andere vette dingen, maar helaas geen app.
Voor €10.000:
- Een simpele basisapplicatie, of een MVP van een complexere applicatie (mits gemaakt door een offshore developer);
- Een volledige opleiding tot programmeur;
- Een redelijk dikke auto.
Voor €50.000:
- Een uitgebreid discovery traject inclusief roadmapping sessie;
EN - Een maatwerk applicatie met gemiddelde scope en complexiteit;
- Een super dikke auto.
Voor €100.000:
- Een uitgebreid discovery traject inclusief roadmapping sessie;
EN - Een maatwerk applicatie, met grote scope en hoge complexiteit;
- Een klein huis of een nog dikkere auto.
Tot slot
Software ontwikkeling is duur. Wij begrijpen heel goed dat het verleidelijk is om voor de partij te gaan met de goedkoopste offerte, zeker wanneer alle partijen hetzelfde eindresultaat beloven. Helaas is de uitspraak “waar voor je geld” misschien nog wel meer toepasselijk op softwareontwikkeling dan op wat dan ook. Daarmee bedoelen we niet dat je moet gaan voor een belachelijk dure partij, omdat die zogenaamd automatisch beter is. We bedoelen alleen dat een goed stuk software, een hoge marktwaarde heeft. We hopen dat jij als bedenker van een nieuw app-idee, aan dit avontuur begint met realistische verwachtingen. Onthoud vooral dit: Er is geen loophole in de softwareontwikkeling. Uiteindelijk betaal je voor slechte software dubbel. Eerst voor het bouwen, daarna voor het fixen!
