Wat een app laten maken kost, is voor een bureau een rekensom: het aantal uren maal je uurtarief, plus een opslag voor risico. De uren komen uit de functies, schermen, koppelingen en platformen die de klant wil. Daar komt het werk naast het programmeren bij: ontwerp, testen, projectmanagement, oplevering in de app stores.
De klant vraagt ‘wat kost een app?’. Jij beantwoordt eerst een andere vraag: ‘hoeveel uur kost deze app, en hoe zeker weten we dat?’ Hieronder staat hoe je die uren opbouwt, welke posten vaak ontbreken en hoe je de prijs uitlegt.
Waaruit bestaat de prijs van een app?
| Onderdeel | Wat de uren bepaalt |
|---|---|
| Analyse en programma van eisen | Hoe goed de klant weet wat hij wil |
| Ontwerp (UX en UI) | Aantal schermen, eigen huisstijl of bestaande |
| Frontend | Aantal schermen, per platform een eigen app of één codebase |
| Backend en API | Datamodel, rollen en rechten, rekenlogica |
| Koppelingen | Aantal systemen en de kwaliteit van hun documentatie |
| Beheeromgeving | Wat de klant zelf wil kunnen aanpassen |
| Testen | Aantal apparaten, automatische tests, acceptatie |
| Projectmanagement | Aantal stakeholders en overleggen |
| Oplevering | App store-review, hosting, monitoring |
Koppelingen zijn meestal de grootste onzekerheid. Een betaalkoppeling met goede documentatie kost weinig uren. Een koppeling met een oud ERP-systeem zonder testomgeving kan een project laten ontsporen.
Hoe reken je de uren uit?
- Knip de app op in functies. Inloggen, profiel, zoeken, bestellen, notificaties. Hoe kleiner de stukken, hoe beter je inschatting.
- Schat elke functie drie keer. Optimistisch, waarschijnlijk, pessimistisch. Een groot verschil tussen de drie zegt dat je de functie nog niet snapt.
- Tel het werk naast het programmeren erbij. Ontwerp, testen, projectmanagement, deployment.
- Zet er een risico-opslag op. Hoger bij onbekende koppelingen of een vage scope.
- Vermenigvuldig met je uurtarief. Een vaste prijs of een begroting op nacalculatie volgt daaruit.
Hoe bepaal je je uurtarief?
Begin bij je kostprijs per declarabel uur. Een uurtarief dat daar niet ruim boven ligt, levert bij de eerste uitloop verlies op.
- Loonkosten per medewerker. Brutoloon, vakantiegeld, werkgeverslasten, pensioen.
- Overhead. Kantoor, licenties, hardware, sales, administratie, management.
- Declarabele uren. Niet elk uur is declarabel. Vakantie, ziekte, interne overleggen en tijd tussen projecten gaan eraf.
- Marge. Wat je overhoudt voor risico, investering en winst.
Wat vergeten bureaus in de offerte?
- Accounts en review in de app stores. Een afgekeurde app kost extra rondes.
- Hosting en monitoring. Wie betaalt de servers, en wie wordt er ‘s nachts gebeld?
- Onderhoud na de lancering. Nieuwe versies van de mobiele besturingssystemen, verouderde pakketten, beveiligingsupdates.
- Privacy. Verwerkt de app persoonsgegevens voor de klant, dan heb je een verwerkersovereenkomst nodig (artikel 28 lid 3 AVG) en een beveiligingsparagraaf.
- Content en vertalingen. Wie vult de app, en in hoeveel talen?
- Acceptatie. Hoe lang test de klant, en hoeveel rondes herstel zitten in de prijs?
- Overdracht van de code. Wat krijgt de klant: een gebruiksrecht of het auteursrecht? Dat verandert de waarde van wat je oplevert.
Waarom is de ene offerte goedkoper dan de andere?
| Oorzaak | Gevolg voor de prijs |
|---|---|
| Eigen componenten op de plank | Minder uren, scherpere prijs, zelfde marge |
| Eén codebase voor beide mobiele platformen | Minder uren dan twee native apps |
| Team deels in het buitenland | Lagere kostprijs per uur, meer afstemming (zie nearshoring) |
| Smalle lezing van de scope | Lage prijs nu, meerwerk later |
| Geen buffer | Lage prijs, verlies bij de eerste tegenvaller |
De eerste regel is de enige die zowel de klant als je bureau helpt. Een bureau met een eigen basis voor inloggen, beheer en betalingen bouwt die niet voor elke klant opnieuw.
Dat werkt alleen als die basis van jou blijft. Lees wie eigenaar is van de code en wat je eigen componenten waard kunnen zijn.
Hoe leg je de prijs uit aan de klant?
- Toon de opbouw per functie. De klant ziet dan welke functie duur is en kan kiezen.
- Werk met prioriteiten. Must-haves in de eerste versie, de rest als optie.
- Bied een eerste versie aan. Een kleinere app die live gaat, en daarna doorbouwen op basis van echt gebruik.
- Kies het prijsmodel bewust. Lees vaste prijs of nacalculatie voordat je een totaalbedrag noemt.
- Leg de scope vast. Het programma van eisen is de basis van de offerte.