Kort samengevat.
- Begroot ruwweg 15–25% van de oorspronkelijke bouwkosten van je Flutter-app, per jaar, voor onderhoud — een app van € 24K kost ongeveer € 3,6-6K per jaar om gezond te houden.
- Onderhoud valt uiteen in vier bakken: bugs herstellen (correctief), meebewegen met veranderingen in OS, SDK en API's (adaptief), verbeteren wat al werkt (perfectief), en technische schuld aflossen voordat ze zich opstapelt (preventief).
- Flutter is één onderhoudsstroom, geen twee — één codebase om te upgraden, te testen en uit te brengen, in plaats van aparte iOS- en Android-teams die dat werk twee keer doen.
- Een goedkope bouw kan alsnog een dure app zijn in beheer: gehaaste of onbewaakte door AI gegenereerde code zonder tests en zonder architectuur blaast elk van die vier bakken op.
- Onderhoud is een percentage dat zich elk jaar dat de app leeft opstapelt — begroot het bij de lancering, niet na de eerste storing.
Wat "apponderhoud" werkelijk dekt
"Onderhoud" wordt als verzamelnaam gebruikt voor alles wat na de lancering gebeurt, en juist daarom is het makkelijk te laag te begroten. Deze vierdeling hebben we niet verzonnen om nauwkeurig te klinken — het is de standaardindeling uit ISO/IEC 14764, de internationale norm voor softwareonderhoud, en ze houdt in de praktijk stand:
- Correctief — bugs herstellen die productie halen: crashes, foute berekeningen, kapotte stromen. Dit is het onderhoud dat mensen zich als eerste voorstellen, en in een gezonde codebase meestal de kleinste bak.
- Adaptief — wijzigingen die de buitenwereld je oplegt: een nieuwe stabiele Flutter-release, een nieuwe iOS- of Android-versie, een aanpassing in winkelbeleid, een betaaldienst die zijn API wijzigt. Jij koos dit werk niet; het platform deed dat.
- Perfectief — verbeteringen die niemand je oplegt: prestaties afstemmen, de gebruikservaring bijschaven, nieuwe functies op bestaande schermen. Hier verandert "onderhoud" stilletjes in "productontwikkeling", en dat is prima — het blijft doorlopende kosten.
- Preventief — herstructureren, afhankelijkheden bijwerken, beveiligingspatches, en technische schuld aflossen voordat er iets breekt, niet erna. Dit is de bak die als eerste sneuvelt bij een krap budget, en die twee jaar later het duurst blijkt te zijn overgeslagen.
Een realistische jaarlijkse onderhoudsbegroting moet alle vier dekken, niet alleen de correctieve die de meeste oprichters voor ogen hebben.
Wat het kost
Reken op 15–25% van je oorspronkelijke bouwkosten per jaar. Waar je in die bandbreedte uitkomt hangt af van hoe actief de app nieuwe functies uitbrengt (perfectief werk schaalt mee met producttempo), hoeveel koppelingen met derden hij draagt (elk daarvan is een toekomstige bron van adaptief werk), en of hij in een gereguleerde sector zit waar de eisen onder je voeten veranderen.
Die bandbreedte, toegepast op de bouwkostenniveaus uit onze uitsplitsing van de kosten van Flutter-appontwikkeling:
| Niveau | Gebruikelijke bouwkosten | Gebruikelijk jaarlijks onderhoud |
|---|---|---|
| MVP | € 12.000-24.000 | € 1.800-6.000 |
| Zakelijke app | € 24.000-48.000 | € 3.600-12.000 |
| E-commerce | € 40.000-72.000 | € 6.000-18.000 |
| Enterprise / AI | vanaf € 72.000 | vanaf € 10.800 |
Die onderhoudsbedragen zijn de vuistregel toegepast op de bouwkostenbandbreedtes, geen apart afgegeven offerte — behandel ze als planningsraming, niet als prijs. Het eerste jaar na de lancering neigt naar de bovenkant van de bandbreedte: je vindt nog correctieve bugs die echte gebruikers blootleggen en die het testen niet ving, en de app is nog niet uitgehard. Jaar twee en drie zakken bij een goed gebouwde app doorgaans lager. Hoe die bouwkosten zelf per fase uiteenvallen, lees je in ons Flutter-ontwikkelproces en onze uitsplitsing van de doorlooptijd — onderhoud is in beide al de laatste fase.
Wat de kosten bepaalt
Sommige hiervan gelden voor elke app, mobiel of niet. Enkele zijn specifiek voor uitleveren op Flutter.
| Drijver | Specifiek voor Flutter? | Waarom het geld kost |
|---|---|---|
| Upgrades van de Flutter-SDK | Ja | Flutter brengt meerdere stabiele releases per jaar uit; bijblijven is goedkoop, twee majors achterlopen niet. |
| Updates van iOS en Android en winkelbeleid | Nee | Apple en Google brengen elk jaarlijks een grote OS-versie uit plus kleinere updates, en herzien beoordelings- en API-eisen meerdere keren per jaar. |
| Verloop in afhankelijkheden en pakketten | Deels | Pakketten op pub.dev worden verlaten of brengen brekende wijzigingen uit; native apps lopen hetzelfde risico in hun eigen pakketecosystemen. |
| Abonnementen op SDK's van derden | Nee | Analyse, pushmeldingen, betalingen, kaarten — terugkerende leverancierskosten, los van je framework. |
| Kosten voor backend, hosting en API's | Nee | Schaalt mee met gebruik, niet met de taal waarin de clientapp is geschreven. |
| Bugs herstellen (correctief) | Nee | Elke app komt met bugs uit; de vraag is hoe duur elke bug is om te vinden en te herstellen. |
| Beveiligingspatches | Nee | Zowel de app als zijn afhankelijkheden moeten gepatcht worden zodra kwetsbaarheden opduiken. |
| Analyse en monitoring | Nee | Crashrapportage en gebruiksanalyse zijn hoe je problemen vindt voordat supporttickets dat doen. |
| Functies doorontwikkelen (perfectief) | Nee | De grootste, meest wisselende post — schaalt mee met hoe actief je nog bouwt. |
De rijen die specifiek voor Flutter zijn vormen de kleinste helft van de tabel. Het meeste wat je na de lancering betaalt heeft niets te maken met welk framework de app bouwde — het zijn de kosten van software draaien, punt.
Waar Flutter bespaart (en waar niet)
De eerlijke versie van "Flutter is goedkoper te onderhouden" is smaller dan de marketingversie: één codebase betekent één upgradestroom, één testronde en één release, in plaats van twee. Een native bureau dat iOS en Android apart onderhoudt, betaalt dezelfde bugfix, dezelfde SDK-bump en dezelfde regressieronde twee keer — één per platform, op twee verschillende planningen, vaak door twee verschillende engineers die op één lijn moeten blijven. Het is dezelfde mechaniek achter de 30–40% lagere bouwkosten die Flutter heeft ten opzichte van twee native apps, en volgens onze eigen vergelijking van Flutter en native wordt de besparing na de lancering doorgaans groter, niet kleiner — elke latere fix en functie wordt nog steeds één keer geschreven in plaats van twee.
Waar het niet volledig opgaat: platformspecifieke koppelingen — diep werk met ARKit of ARCore, bepaalde betaal-SDK's, randgevallen bij achtergrondverwerking — vragen ook binnen een Flutter-app nog native kennis, omdat Flutter op dat punt native code aanroept en niet vervangt. En een Flutter-app draagt net zo goed echt afhankelijkheidsrisico als een native app op zijn eigen bibliotheken leunt: een plug-in kan onbeheerd raken of door de leverancier worden gestopt, en die vervangen is echt adaptief werk. Flutter verkleint hoe vaak je onderhoudskosten dubbel betaalt; het haalt de onderhoudskosten niet weg.
Waarom een slecht gebouwde app duurder is om te onderhouden
Elk van de vier onderhoudsbakken wordt duurder wanneer de onderliggende code slecht is — en "slecht" betekent hier niet dat de app er voor een gebruiker kapot uitziet. Het betekent: geen tests, dus elke fix riskeert een nieuwe regressie. Geen samenhangende architectuur, dus een wijziging in één scherm heeft neveneffecten op drie andere die niemand voorzag. Gedupliceerde logica, dus dezelfde bug wordt één keer opgelost en duikt zes maanden later elders weer op.
Dat is niet hypothetisch. We hebben tientallen met AI gebouwde codebases beoordeeld en vonden vrijwel elke keer dezelfde elf problemen terug: blootgestelde geheimen, geen invoervalidatie, authenticatie die nooit controleert wie het vraagt, geen tests, gedupliceerde code, geen consistente architectuur, callbackchaos in plaats van deugdelijke asynchrone patronen, en geen besef van de uitrolomgeving. Niets daarvan is zichtbaar in een demo. Alles daarvan duikt op zodra je voor het eerst veilig iets probeert te wijzigen. Onze beoordeling van Flutter geschreven door onbewaakte AI-agents laat hetzelfde patroon vanuit een andere hoek zien — code die vandaag werkt en meetbaar lastiger aan te raken wordt met elke maand dat er niemand naar kijkt.
De praktische les: een MVP van € 12K die snel is gebouwd en nooit is beoordeeld, is geen app van € 1,8K onderhoud per jaar. Het is een herbouwkandidaat met een onderhoudsbegroting om. Erfde je een codebase — met AI gebouwd, uitbesteed, of anderszins — en weet je niet welke van de twee je hebt, dan is daar een audit van AI-code voor: die vertelt je je werkelijke onderhoudslast voordat je je een jaar eraan verbindt.
Wie het onderhoud doet
Drie echte opties, met dezelfde afwegingen als bij werven voor de eerste bouw — uitgebreider behandeld in onze uiteenzetting over eigen mensen, bureau en teamuitbreiding:
- Eigen mensen. Zinnig zodra de app kern van de zaak is en je de code en de kennis voltijds in eigen huis wilt hebben. Hoogste vaste kosten, beste eigenaarschap op lange termijn.
- Bureau op abonnement. Iemand anders draagt de piketdienst en de kennis van Flutter en de platforms; je betaalt voor capaciteit die je gebruikt. Laagste beheerlast, minste grip op wie er van week tot week aan de code komt.
- Teamuitbreiding. Engineers werken binnen jouw team, jouw repo, jouw proces — jij beheert de roadmap, zij leveren de Flutter-capaciteit. Werkt goed wanneer je al technische aansturing hebt maar meer handen nodig hebt, via teamuitbreiding.
Wij draaien onze eigen doorlopende ondersteuning als maandelijkse urenafspraak afgestemd op de app, geen vast pakket — een fintech-app met drie betaal-SDK's en een contentapp zonder horen niet in hetzelfde onderhoudsplan, en we bakenen het liever nauwkeurig af dan je een getal te verkopen dat niet bij je app past.
Hoe je onderhoudskosten verlaagt
Niets hiervan is exotisch; het is vooral discipline die goedkoop is om vol te houden en duur om over te slaan:
- Houd afhankelijkheden elk kwartaal bij, niet elke twee jaar. Eén Flutter-versie ophogen is een dag werk. Drie jaar uitgestelde ophogingen in één keer is een project.
- Investeer vroeg in tests en CI. Een regressie die CI vangt kost minuten. Dezelfde regressie die een gebruiker vangt kost een supportticket, een spoedfix en vertrouwen.
- Begroot preventief werk expliciet, als eigen post, niet als wat er overblijft nadat de functies zijn opgeleverd. Het is de bak die als eerste sneuvelt en die het duurst is om te hebben overgeslagen.
- Wees voorzichtig met broze of nauwelijks onderhouden SDK's van derden. Elk daarvan is een toekomstige bron van adaptief werk buiten je macht — controleer de onderhoudsactiviteit voordat je van een pakket afhankelijk wordt, niet nadat het breekt.
- Monitor voordat je gebruikers melden. Crashrapportage en analyse maken van een stille storing een oplosbare voordat het een recensie wordt.
Veelgestelde vragen
Reken op ruwweg 15–25% van de oorspronkelijke bouwkosten van de app per jaar. Voor een app die € 24K kostte om te bouwen is dat ongeveer € 3,6-6K per jaar, voor bugs herstellen, OS- en SDK-updates, beveiligingspatches, hosting en doorlopende verbeteringen.
Krijg een onderhoudsplan dat bij je app past
De snelste weg naar een echt getal is geen vuistregel — het is een blik op je werkelijke codebase. Heb je al een live Flutter-app en wil je weten wat het echt kost om die goed draaiende te houden, dan bakenen we er een onderhoudsplan tegen af. Weet je niet zeker wat je hebt geërfd, begin dan met een audit van AI-code en we zeggen eerlijk in welke staat hij is. En zit je nog in de bouwfase, dan bouwt ons team voor Flutter-appontwikkeling met de komende drie jaar in gedachten, niet alleen met de lanceerdatum. Neem contact op en vertel ons waar je app vandaag staat.
Ilya Nixan is oprichter en lead developer bij Nerdy Production, een Flutter-eerst bureau dat apps bouwt en onderhoudt in fintech, zorg en retail.