App onderhoud en updates: kosten na lancering

Een app bouwen kost €15.000 tot €80.000. Maar het bedrag dat je betaalt na de lancering is waar de meeste ondernemers door verrast worden. Jaarlijks onderhoud loopt al snel op tot 15–20% van de oorspronkelijke bouwkosten — voor een app van €30.000 is dat €4.500 tot €6.000 per jaar, elk jaar opnieuw. En dat is alleen het onderhoud. Nieuwe functies komen daar bovenop.

Toch plannen de meeste MKB-bedrijven geen onderhoudsbudget in wanneer ze een app laten maken. In dit artikel lees je precies waar dat geld naartoe gaat, wat je kunt verwachten per onderhoudslaag, en hoe je voorkomt dat je meer betaalt dan nodig.

Wat app-onderhoud daadwerkelijk inhoudt

"Onderhoud" klinkt als af en toe een schroefje aandraaien. In de praktijk is het een doorlopend proces met minstens zeven verschillende verantwoordelijkheden.

Besturingssysteem-updates. Apple brengt elke september een nieuwe iOS-versie uit. Binnen enkele weken moet je app getest en aangepast zijn, anders crasht hij op nieuwe toestellen of verdwijnen functies. Android-releases zijn geleidelijker, maar de fragmentatie — honderden telefoonmodellen met verschillende schermformaten en OS-versies — creëert een eigen reeks problemen.

Beveiligingspatches. Je app draait op frameworks, bibliotheken en afhankelijkheden die continu geactualiseerd worden. Eén ongepatcht beveiligingslek (CVE) kan gebruikersgegevens blootstellen. Regelmatig patchen is geen luxe — het is noodzaak. Lees ook onze beveiligingschecklist voor de basisprincipes die ook voor apps gelden.

Bugfixes. Geen enkele app lanceert foutloos. Echte gebruikers ontdekken randgevallen die testscenario's niet vangen. Een formulier dat crasht bij een specifieke emoji, een scherm dat niet goed schaalt op de iPhone SE, een laadscherm dat oneindig draait bij slechte wifi — deze problemen duiken pas op in productie.

Prestatiemonitoring. Serveruptime, crashpercentages, laadtijden — je hebt tooling nodig die afwijkingen signaleert en iemand die erop reageert. Niet volgende week, maar dezelfde dag.

Server- en hostingkosten. Cloudkosten (AWS, Google Cloud, Azure) lopen van €50 tot €500 per maand, afhankelijk van het aantal gebruikers, dataopslag en serverbelasting.

Wijzigingen in API's van derden. Stripe, Google Maps, Mollie, Firebase — wanneer die hun API's bijwerken, moet jouw code mee. Soms is dat een kleine aanpassing, soms een volledige herimplementatie.

App Store-compliance. Apple en Google wijzigen regelmatig hun richtlijnen voor apps. Privacy-eisen worden strenger, nieuwe permissieregels worden ingevoerd. Als je app niet meebeweegt, risikeer je verwijdering uit de store.

Kostenopbouw — drie onderhoudslagen

Niet elk bedrijf heeft hetzelfde onderhoudsniveau nodig. De meeste bureaus werken met een getrapte structuur:

De juiste laag hangt af van hoe kritisch de app is voor je bedrijf. Een interne planningsapp waar tien medewerkers mee werken, kan prima met basismonitoring. Een consumentenapp die inkomsten genereert, heeft volledige dekking nodig.

Voor een compleet overzicht van de initiële bouwkosten, lees het app-ontwikkeltraject van begin tot eind.

De verborgen kosten die bureaus niet benoemen

Het onderhoudscontract dekt niet alles. Bovenop die maandelijkse factuur betaal je nog een reeks vaste en variabele kosten die in geen enkele offerte staan:

• Apple Developer Program: €99 per jaar — verplicht om in de App Store te staan
• Google Play Developer: €25 eenmalig
• Pushnotificatiedienst (Firebase, OneSignal): €0–€100 per maand, afhankelijk van volume
• Analysetools (Mixpanel, Amplitude): €0–€300 per maand
• SSL-certificaten: meestal inbegrepen bij hosting, maar aangepaste domeinen kosten extra
• CDN voor mediarijke apps: €20–€200 per maand
• Foutregistratie (Sentry, Crashlytics): €0–€80 per maand
• Geautomatiseerde testinfrastructuur (CI/CD): €0–€200 per maand

Totale verborgen kosten: €200 tot €1.000 per maand, bovenop je onderhoudscontract. Bij een app van €30.000 kan je totale jaarlijkse onderhoudsrekening dus oplopen tot €8.000–€18.000 als je volledige dekking wilt.

iOS versus Android — verschillen in onderhoud

De keuze tussen platformen beïnvloedt niet alleen de bouwkosten, maar ook wat je structureel betaalt na lancering. Wie twijfelt tussen een PWA en een native app doet er goed aan deze onderhoudsverschillen mee te wegen.

iOS. Apple heeft een agressief afschrijvingsbeleid. Na een nieuwe iOS-versie heb je circa 12 maanden voordat het ondersteunen van de vorige versie onpraktisch wordt. SwiftUI evolueert snel — wat vorig jaar "best practice" was, kan dit jaar verouderd zijn. TestFlight maakt bètatesten eenvoudig, maar de App Store-review kan updates afwijzen wegens nieuwe beleidsregels die er bij de vorige versie nog niet waren.

Android. Fragmentatie is de hoofduitdaging. Honderden schermformaten, besturingssysteemversies (sommige toestellen draaien nog Android 10), en fabrikant-specifieke aanpassingen. Kotlin en Jetpack Compose krijgen regelmatig updates. Google Play keurt updates sneller goed dan Apple, maar hun beleid rond permissies verandert onvoorspelbaar.

Cross-platform (React Native/Flutter). Eén codebase, één updatecyclus — dat scheelt. Maar updates aan het framework zelf kunnen codewijzigingen vereisen. En als het framework een bug bevat, treft het beide platformen tegelijk. Je bent ook afhankelijk van de snelheid waarmee het framework zelf nieuwe OS-functies ondersteunt.

Wanneer updaten en wanneer opnieuw bouwen

Niet elk probleem los je op met een patch. Soms is herbouw goedkoper dan blijven plakken.

Update als:

• De app functioneert naar behoren
• De technische stack wordt nog actief ondersteund
• Wijzigingen zijn incrementeel en afgebakend
• De architectuur kan de gevraagde aanpassingen aan

Herbouw als:

• De technische stack is verouderd (Objective-C naar Swift, Java naar Kotlin)
• De kernarchitectuur blokkeert nieuwe functionaliteit
• De prestaties zijn structureel onvoldoende en niet te verbeteren met patches
• Je besteedt meer tijd aan workarounds dan aan echte verbeteringen

Vuistregel: apps die 3 tot 5 jaar geleden zijn gebouwd op oudere frameworks zijn kandidaten voor herbouw. Vaak is herbouwen na twee jaar intensief patchwerk goedkoper dan doorgaan op de oude basis. Overweeg in dat geval ook of maatwerk software niet een betere langetermijnoplossing biedt.

Een onderhoudspartner kiezen — waar je op let

De goedkoopste aanbieder is zelden de beste keuze. Kijk naar deze vijf factoren:

SLA-vergelijking. Wat is de gegarandeerde responstijd? Een goed contract specificeert: kritiek (serveruitval, dataverlies) binnen 4 uur, hoog (functionaliteit kapot voor veel gebruikers) binnen 24 uur, normaal (cosmetische fouten, kleine bugs) binnen 48 uur.

Uptimegaranties. Het verschil tussen 99,5% en 99,9% uptime klinkt klein, maar 99,5% staat 43 uur downtime per jaar toe. 99,9% slechts 8,7 uur. Voor een omzetgenererende app is dat een relevant verschil.

Inbegrepen uren. Hoeveel uren per maand zitten in het contract? 8, 16, of 40? En wat kost een extra uur buiten de bundel?

Continuïteit. Is het originele ontwikkelteam beschikbaar voor het onderhoud? Overdracht naar een nieuw team kost tijd en verhoogt het foutenrisico.

Proactief versus reactief. Stelt de partner verbeteringen voor, of hoor je pas iets als er iets kapot is? Een proactieve partner bespaart je op de lange termijn meer dan hij kost.

Lees ook onze gids over maatwerk software versus standaardoplossingen om te begrijpen wanneer maatwerk onderhoud zich terugverdient.

Onderhoudskosten verlagen

Je hebt meer invloed op de hoogte van je onderhoudskosten dan je denkt — mits je de juiste beslissingen neemt vóór en tijdens de bouw.

• Kies de juiste technische stack. Moderne, breed ondersteunde frameworks (Swift/SwiftUI, Kotlin, React Native, Flutter) verlagen de onderhoudskosten structureel. Verouderde of niche-technologie kost meer om te onderhouden en maakt het moeilijker om ontwikkelaars te vinden.
• Schrijf schone, gedocumenteerde code vanaf dag één. Code zonder documentatie kost een nieuwe ontwikkelaar twee keer zoveel tijd om te begrijpen — en die tijd betaal jij.
• Investeer in geautomatiseerde tests. Geautomatiseerde tests vangen bugs vóór gebruikers ze tegenkomen. Dat scheelt brandjes blussen en spoedpatches.
• Zet CI/CD-pipelines op. Geautomatiseerde deployment vermindert handmatig werk en voorkomt menselijke fouten bij releases.
• Monitor proactief. Kleine problemen vroeg opsporen kost een fractie van wat dezelfde problemen kosten als ze uitgroeien tot klachten of uitval.
• Overweeg een PWA voor eenvoudigere toepassingen. Een Progressive Web App vereist minder onderhoud dan een native app en hoeft niet door de App Store-review. Niet geschikt voor alles, maar voor informatie- en portaalapps is het een serieus alternatief.

Rode vlaggen — tekenen dat je te veel betaalt

Niet elk onderhoudsbureau levert waar voor zijn geld. Let op deze signalen:

• Maandkosten boven 2% van de bouwkosten zonder dat er nieuwe functionaliteit wordt ontwikkeld
• Trage responstijden ondanks wat het SLA belooft — meet dit actief
• Elke kleine wijziging is een "change request" buiten scope, met extra kosten
• Geen proactieve communicatie — je hoort alleen van ze als er iets kapot is
• Geen toegang tot je eigen codebase of deployment-pipeline — dit is een ernstig risico. Je code is van jou, niet van het bureau

Onderhoud als investering, niet als kostenpost

De apps die het langst meegaan en het meeste opleveren, zijn niet de apps met de meeste functies bij lancering. Het zijn de apps die na lancering consistent worden bijgewerkt op basis van gebruikersdata, beveiligingsupdates en platformwijzigingen.

Zoek je een partner voor app-ontwikkeling die ook na de lancering naast je staat? Of wil je bestaande maatwerk software onder professioneel onderhoud brengen? Begin met een gesprek over wat je app nodig heeft — niet over wat een bureau wil verkopen.