Wat kost een app laten maken? Daar bestaat geen betrouwbaar standaardbedrag voor zonder de gebruikers, functies, gegevens en koppelingen te kennen. Twee apps met tien schermen kunnen technisch totaal verschillend zijn. Een eenvoudige informatieve flow is iets anders dan een platform met betalingen, rollen, documenten en synchronisatie met externe systemen.
Een goede prijsinschatting begint daarom met scope en risico. In dit artikel leer je welke onderdelen het budget bepalen en hoe je voorkomt dat een goedkope offerte later verandert in een duur onafgewerkt project.
Waarom een prijs per scherm weinig zegt
Een scherm kan een eenvoudige tekstpagina zijn, maar ook een dashboard met filters, rechten, grafieken en realtime gegevens. Het zichtbare ontwerp is maar één laag. Achter een app zitten vaak databankregels, authenticatie, validatie, logging en integraties.
Vergelijk offertes daarom niet alleen op aantallen schermen. Vraag welke gebruikersscenario's, back-endfuncties, testgevallen en opleveringsonderdelen inbegrepen zijn.
De belangrijkste prijsfactoren
1. Gebruikersrollen en toegangsrechten
Een app voor één beheerder is eenvoudiger dan een platform voor klanten, medewerkers, partners en superadmins. Iedere rol vraagt regels over wat iemand mag zien, toevoegen, wijzigen en verwijderen.
Complexiteit ontstaat vooral wanneer rechten per organisatie, dossier of record verschillen. Die regels moeten in de back-end worden afgedwongen en getest.
2. Datamodel en bedrijfslogica
De databank moet de echte werking ondersteunen. Denk aan klanten, projecten, taken, statussen, documenten, producten, planning en facturen.
Prijs stijgt wanneer:
- gegevens veel onderlinge relaties hebben;
- statussen alleen onder voorwaarden mogen veranderen;
- historische versies bewaard moeten blijven;
- berekeningen en uitzonderingen belangrijk zijn;
- meerdere gebruikers tegelijk gegevens wijzigen.
Een goed datamodel voorkomt later dure ombouw.
3. Koppelingen met externe systemen
Koppelingen met CRM, boekhouding, betalingen, agenda, e-mail, kaarten of andere software vragen analyse en foutafhandeling. Een API kan goed gedocumenteerd zijn, maar ook beperkt, betalend of onbetrouwbaar.
Voor iedere integratie moet duidelijk zijn wat gebeurt wanneer het externe systeem tijdelijk niet reageert. Logging, herpogingen en handmatige herstelopties kosten werk, maar voorkomen stille gegevensverliezen.
4. Webapp of mobiele app
Een responsieve webapp kan met één codebasis veel toestellen bedienen. Een native mobiele app kan extra ontwikkeling vragen voor iOS, Android, appstores, toestelrechten en versies.
Kies niet automatisch voor twee mobiele apps wanneer een webapp de taak goed uitvoert. Lees webapp of mobiele app voor de afweging.
5. Offline gebruik en synchronisatie
Offline werken is technisch veel complexer dan alleen gegevens lokaal tonen. De app moet wijzigingen bewaren, later synchroniseren en conflicten oplossen wanneer meerdere gebruikers hetzelfde item aanpassen.
Neem offline functionaliteit alleen op wanneer de werkomgeving het echt vereist.
6. UX/UI en prototype
Wireframes en prototypes kosten tijd, maar besparen ontwikkeling wanneer ze verkeerde flows vroeg zichtbaar maken. Een goed ontwerp bevat ook laadstatussen, foutmeldingen, lege schermen, mobiele varianten en toegankelijk gedrag.
Een prototype is vooral waardevol bij complexe workflows of wanneer meerdere stakeholders verschillende verwachtingen hebben.
7. Beheeromgeving
Bijna iedere app heeft beheer nodig. Iemand moet gebruikers blokkeren, gegevens corrigeren, content aanpassen, exports maken of fouten herstellen.
Een beheeromgeving is geen automatisch gratis bijproduct. Bepaal welke handelingen beheerders nodig hebben en welke acties gelogd moeten worden.
8. Beveiliging en privacy
Gevoelige gegevens, betalingen, medische informatie of complexe rollen verhogen analyse- en testwerk. Beveiliging omvat onder meer authenticatie, autorisatie, versleuteling, logging, back-ups en incidentrespons.
Een offerte die beveiliging alleen als één algemeen punt noemt, is moeilijk te beoordelen. Vraag welke concrete maatregelen en tests worden voorzien.
9. Datamigratie
Bestaande spreadsheets, CRM-exports of oude databanken zijn zelden perfect opgeschoond. Import vraagt mapping, validatie, testmigraties en een plan voor dubbele of ontbrekende gegevens.
De hoeveelheid records is niet de enige factor. Datakwaliteit bepaalt veel van het werk.
10. Onderhoud en doorontwikkeling
Na lancering blijven hosting, monitoring, updates, support en verbeteringen nodig. Externe API's en dependencies veranderen. Reserveer dus niet het volledige budget voor de eerste livegang.
Werk met fases in plaats van één gigantische scope
Een haalbaar project kan uit vier budgetlagen bestaan.
Fase 1: analyse en prototype
Doel: risico's en aannames zichtbaar maken.
Mogelijke output:
- functionele analyse;
- gebruikersrollen;
- kernflow;
- datamodel op hoofdlijnen;
- technisch advies;
- klikbaar prototype;
- MVP-scope en raming.
Fase 2: MVP
Doel: de kernwaarde in productie testen.
De MVP bevat alleen noodzakelijke functies, maar wel voldoende beveiliging, logging en beheer om echte gebruikers toe te laten.
Fase 3: integraties en verdieping
Na bewijs van gebruik volgen aanvullende koppelingen, rapporten, automatisering en uitzonderingen.
Fase 4: optimalisatie en schaal
Hier verbeter je prestaties, onboarding, analytics en processen op basis van werkelijke data.
Hoe vergelijk je app-offertes?
Controleer of iedere offerte antwoord geeft op deze vragen:
- Welke gebruikersrollen zijn inbegrepen?
- Welke concrete flows worden gebouwd?
- Is UX/UI inbegrepen?
- Wie bouwt en beheert de back-end?
- Welke koppelingen zijn inbegrepen?
- Hoe worden fouten en uitzonderingen behandeld?
- Welke tests worden uitgevoerd?
- Wie is eigenaar van code en accounts?
- Welke hosting- en gebruikskosten zijn extern?
- Welke documentatie wordt geleverd?
- Wat valt onder garantie en wat onder onderhoud?
- Hoe worden scopewijzigingen geprijsd?
Een lage prijs kan het gevolg zijn van een efficiënte oplossing, maar ook van ontbrekende onderdelen. Vergelijk daarom de afbakening, niet alleen het eindbedrag.
Veelvoorkomende budgetfouten
Alles in versie één willen
Een grote eerste scope verhoogt doorlooptijd en maakt feedback duur. Bouw eerst de functies die de hoofdtaak mogelijk maken.
Externe kosten vergeten
Denk aan hosting, e-mail, opslag, kaarten, betaalproviders, AI-gebruik, appstoreaccounts en premium API's. Sommige kosten groeien mee met gebruik.
Geen budget voor content en data
Teksten, productgegevens, imports, documentstructuur en testdata moeten worden voorbereid. Slechte brondata vertraagt ontwikkeling.
Geen eigenaar binnen het bedrijf
Een ontwikkelaar kan technische keuzes begeleiden, maar iemand binnen de organisatie moet prioriteiten bepalen en processen uitleggen. Gebrek aan beslissingen veroorzaakt vertraging en extra werk.
Kun je een vaste prijs krijgen?
Voor een goed afgebakende fase is een vaste prijs mogelijk. Bij een nieuw product met veel onzekerheid is een korte betaalde analyse vaak eerlijker dan een schijnbaar vaste totaalprijs met ruime aannames.
Een combinatie werkt goed:
- vaste prijs voor analyse en prototype;
- vaste of beperkte bandbreedte voor een scherp beschreven MVP;
- losse prioriteiten voor latere iteraties.
Samenvatting
De kosten van een app worden bepaald door gebruikers, data, bedrijfsregels, koppelingen, platform, beheer, beveiliging en onderhoud. Een realistisch budget ontstaat door de kernflow te beschrijven en het project in fases te verdelen.
Lees de pillar app laten maken voor het volledige ontwikkelproces of bekijk onze dienst app laten maken.
