TL;DR<\/h2>\n\n\n\n
Onderhoud van een app is het doorlopende werk van repareren, aanpassen, verbeteren en beschermen van een app na de lancering. Bij een AI-gebouwde app zit het risico niet in het werk zelf, maar in het ontbreken van een eigenaar: de redenen achter door AI geschreven code staan mogelijk alleen in een promptgeschiedenis, dus elke wijziging vraagt om iemand die de code kan lezen en testen.<\/p>\n\n\n\n
- \n
- Onderhoud omvat vier soorten werk uit de onderhoudsstandaard ISO\/IEC\/IEEE 14764: correctief, adaptief, perfectief en preventief.<\/li>\n\n\n\n
- Het eigenaarschap ligt bij \u00e9\u00e9n verantwoordelijke persoon of \u00e9\u00e9n team die code kan lezen en testen, zodra de app betalingen verwerkt of persoonsgegevens opslaat.<\/li>\n\n\n\n
- De overdracht verloopt in vijf stappen: accounts op naam van het bedrijf, een schriftelijk runbook, monitoring met een benoemd aanspreekpunt, een schriftelijke onderhoudsscope en een onafhankelijke nulmeting van de codebase.<\/li>\n\n\n\n
- De kosten van het onderhoud hangen af van vijf factoren: leesbaarheid en tests van de code, integraties, platforms, gevoeligheid van data en het tempo van productwijzigingen.<\/li>\n<\/ul>\n\n\n\n
Wat houdt onderhoud van een AI-gebouwde app in?<\/h2>\n\n\n\n
Onderhoud van een app omvat elke wijziging in een live app na de lancering, van bugfixes tot de updates die de volgende storing voorkomen. ISO\/IEC\/IEEE 14764, de internationale standaard voor softwareonderhoud<\/a>, onderscheidt typen onderhoudswerk. Vier daarvan sluiten direct aan op een AI-gebouwde app:<\/p>\n\n\n\n
- \n
- Correctief:<\/strong> fouten herstellen die gebruikers of monitoring vinden, zoals een checkout die voor \u00e9\u00e9n betaalmethode mislukt.<\/li>\n\n\n\n
- Adaptief:<\/strong> de app laten werken wanneer de omgeving verandert, zoals een nieuw mobiel besturingssysteem of een uitgefaseerde API-versie.<\/li>\n\n\n\n
- Perfectief:<\/strong> de app verbeteren en functies toevoegen, zoals het volgende scherm dat u met een prompt bouwt.<\/li>\n\n\n\n
- Preventief:<\/strong> toekomstige storingen voorkomen voordat ze ontstaan, zoals verouderde pakketten bijwerken of een back-up testen.<\/li>\n<\/ul>\n\n\n\n
De lancering is het punt waar het bouwbudget stopt. De vier typen onderhoud lopen door zolang de app gebruikers heeft.<\/p>\n\n\n\n
Waarom een AI-gebouwde app na de lancering een benoemde eigenaar nodig heeft<\/h2>\n\n\n\n
Een AI-gebouwde app heeft een benoemde eigenaar nodig omdat de code zichzelf niet toelicht. Schrijft een ontwikkelaar een app, dan weet die ontwikkelaar nog waarom een query zo is opgebouwd of welk randgeval een controle afvangt. Schrijft een AI-codingtool de app, dan staan die redenen mogelijk alleen in een chat- of promptgeschiedenis die niemand opnieuw leest.<\/p>\n\n\n\n
De code werkt nog, maar niemand kan zeggen wat een wijziging kapotmaakt. De oprichter vraagt de tool om een fix, de tool herschrijft een deel van de code en niemand controleert wat er nog meer is veranderd.<\/p>\n\n\n\n
De bruikbare vraag is dus niet “hoeveel uur onderhoud heeft de app nodig?”, maar “wie kan deze code volgende maand veilig aanpassen?” Het antwoord moet een benoemde persoon of een benoemd team zijn, met de toegang, documentatie en tests om te handelen. Tot die tijd wacht het onderhoud op wie als eerste een probleem opmerkt.<\/p>\n\n\n\n
6 onderhoudstaken die zonder eigenaar productie-incidenten worden<\/h2>\n\n\n\n
![\"6](\"https:\/\/sunbytes.io\/wp-content\/uploads\/2026\/11\/6-maintenance-tasks-that-become-production-incidents-without-an-owner-2.webp\")
<\/figure>\n\n\n\nElke taak hieronder is routine zolang iemand de app beheert en wordt een productie-incident zodra niemand dat doet. Toets elke taak aan uw eigen product.<\/p>\n\n\n\n
Beveiligingspatches en updates van afhankelijkheden raken verouderd<\/h3>\n\n\n\n
Een AI-gebouwde app leunt op opensourcepakketten, afhankelijkheden genoemd, die anderen schrijven en onderhouden. Wordt in een pakket een beveiligingslek gevonden, dan brengen de beheerders een fix uit. Uw app blijft kwetsbaar tot iemand het pakket bijwerkt en test of de app nog werkt.<\/p>\n\n\n\n
AI-codingtools voegen pakketten toe om een functie werkend te krijgen, maar volgen ze niet meer nadat de sessie eindigt. Tools zoals GitHub Dependabot geven meldingen over kwetsbare afhankelijkheden<\/a>; die meldingen helpen alleen als iemand ze leest en opvolgt. Vraag uw ontwikkelaar: “Wanneer hebben we onze afhankelijkheden voor het laatst bijgewerkt en hoeveel openstaande beveiligingsmeldingen zijn er?”<\/p>\n\n\n\n
Wijzigingen bij platforms en API’s van derden breken functies<\/h3>\n\n\n\n
Platforms en providers wijzigen hun regels op hun eigen tempo, en een app die niet wordt aangepast, stopt met werken of kan geen updates meer uitbrengen. Google Play eist dat nieuwe apps en updates van bestaande apps vanaf 31 augustus 2026 Android 16 (API-niveau 36) als doelversie hebben<\/a>. Bestaande apps met een doelversie lager dan Android 15 zijn niet meer beschikbaar voor nieuwe gebruikers op nieuwere Android-apparaten.<\/p>\n\n\n\n
Apple eist sinds 28 april 2026 dat apps die naar App Store Connect worden ge\u00fcpload, met Xcode 26 zijn gebouwd<\/a>. Providers van betalingen, inloggen en databases faseren API-versies op dezelfde manier uit. De waarschuwing komt als e-mail van de provider, dus vraag: “Wie leest onze berichten van providers en app stores, en wanneer hebben we daar voor het laatst op gehandeld?”<\/p>\n\n\n\n
Bij storingen reageert niemand<\/h3>\n\n\n\n
Zonder monitoring en een benoemd aanspreekpunt is de eerste die een storing opmerkt een klant. Monitoring betekent automatische controles of de app bereikbaar is en meldingen wanneer het aantal fouten oploopt. Een benoemd aanspreekpunt, ook wel on-call genoemd, is de persoon die die meldingen ontvangt en geacht wordt te handelen.<\/p>\n\n\n\n
Een AI-gebouwde app kan live gaan zonder foutregistratie, beschikbaarheidscontroles of meldingen, omdat geen van die dingen in een demo zichtbaar is. Hoort u over downtime via supporttickets of berichten op social media, dan heeft deze taak nog geen eigenaar. Vraag: “Wie krijgt de melding als de app zondagnacht om 02:00 uur uitvalt?”<\/p>\n\n\n\n
Back-ups bestaan, maar herstel wordt nooit getest<\/h3>\n\n\n\n
Hosting- en databaseplatforms bieden back-ups, maar een back-up die nog nooit is hersteld, is een aanname. De instellingen hangen af van uw abonnement. Bij Supabase bijvoorbeeld lopen dagelijkse back-ups mee in de abonnementen Pro, Team en Enterprise, is point-in-time recovery een extra optie en bevatten back-ups van de database geen bestanden die via Supabase Storage zijn opgeslagen<\/a>.<\/p>\n\n\n\n
Bevat de app persoonsgegevens, dan vraagt artikel 32, lid 1, onder c van de AVG<\/a> om het vermogen om de beschikbaarheid van en de toegang tot persoonsgegevens bij een fysiek of technisch incident tijdig te herstellen. Vraag: “Wanneer hebben we voor het laatst een back-up in een testomgeving teruggezet en hoe lang duurde dat?”<\/p>\n\n\n\n
Nieuwe functies breken oude functies<\/h3>\n\n\n\n
Elke nieuwe door AI gegenereerde wijziging kan elders in de app het gedrag veranderen wanneer geen geautomatiseerde tests de rest controleren. Ontwikkelaars noemen dat een regressie: iets wat werkte, werkt niet meer na een wijziging die er niets mee te maken lijkt te hebben. AI-codingtools richten zich op de functie uit de prompt, niet op alles wat die functie raakt.<\/p>\n\n\n\n
Twee signalen wijzen op dit probleem: fixes veroorzaken nieuwe bugs en elke release vraagt om een handmatige doorloop van de hele app. Hoe ver de code is afgedreven, meet u met onze indicatoren voor AI-codekwaliteit<\/a> en onze gids over AI technical debt<\/a>. Vraag: “Welke van onze kritieke flows hebben geautomatiseerde tests?”<\/p>\n\n\n\n
Accounts en toegang liggen bij \u00e9\u00e9n persoon<\/h3>\n\n\n\n
Als de accounts waarop uw app draait van een freelancer of \u00e9\u00e9n medeoprichter zijn, heeft het bedrijf geen controle over zijn eigen product. Accounts die tijdens een snelle bouw op persoonlijke naam zijn geopend, blijven daar staan tot iemand ze verplaatst. De test is simpel: kunt u zelf inloggen op productie?<\/p>\n\n\n\n
Controleer minstens deze acht accounts:<\/p>\n\n\n\n
- \n
- domeinregistrar en DNS<\/li>\n\n\n\n
- hosting- of cloudplatform<\/li>\n\n\n\n
- database<\/li>\n\n\n\n
- coderepository<\/li>\n\n\n\n
- App Store Connect<\/li>\n\n\n\n
- Google Play Console<\/li>\n\n\n\n
- betaalprovider<\/li>\n\n\n\n
- het account van de AI-codingtool waarin het project staat<\/li>\n<\/ul>\n\n\n\n\n
Weet wat u overneemt<\/strong><\/p>\n
Voordat iemand het onderhoud van uw app op zich neemt, wilt u weten wat erin zit. Een AI-built product review bekijkt beveiliging, code, betrouwbaarheid en deployment in samenhang en legt de bevindingen uit in begrijpelijke taal, zodat de volgende eigenaar met feiten begint.<\/p>\n
Bekijk de AI-built product review<\/strong><\/a><\/p>\n<\/div>\n\n\n\n
Wie moet na de lancering eigenaar van uw app zijn?<\/h2>\n\n\n\n
Bij een live product met betalende gebruikers werkt \u00e9\u00e9n verantwoordelijke eigenaar die code kan lezen en testen, plus toegang tot elk account op naam van het bedrijf, beter dan elke regeling waarin de oprichter en een AI-tool de taak delen. De eigenaar kan een freelancer, een bureau, een medewerker of een dedicated team zijn. Waar het om gaat: \u00e9\u00e9n partij is verantwoordelijk voor alle vier de typen onderhoud.<\/p>\n\n\n\n
- Adaptief:<\/strong> de app laten werken wanneer de omgeving verandert, zoals een nieuw mobiel besturingssysteem of een uitgefaseerde API-versie.<\/li>\n\n\n\n
- Correctief:<\/strong> fouten herstellen die gebruikers of monitoring vinden, zoals een checkout die voor \u00e9\u00e9n betaalmethode mislukt.<\/li>\n\n\n\n
![\"\"](\"https:\/\/sunbytes.io\/wp-content\/uploads\/2026\/11\/What-drives-app-maintenance-cost-1.webp\")
<\/figure>\n\n\n\n