Onderhoud van een AI-gebouwde app is minder een budgetvraag dan een eigenaarschapsvraag: wie kan deze code volgende maand veilig aanpassen? De app draait vandaag misschien goed. Komt er een beveiligingspatch, een wijziging in het beleid van een app store of een storing, dan moet iemand de code goed genoeg begrijpen om in te grijpen. Bij AI-gebouwde code staan de redenen achter elke keuze mogelijk nergens beschreven.
Deze gids is bedoeld voor bedrijfsleiders van wie de AI-gebouwde app live is en de eerste betalende gebruikers heeft. Hij behandelt wat onderhoud inhoudt, zes taken die zonder eigenaar misgaan, wie de app moet beheren, hoe u de overdracht regelt en wat de kosten bepaalt. Hij maakt deel uit van onze gids over het veilig lanceren van AI-gebouwde producten.
TL;DR
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.
- Onderhoud omvat vier soorten werk uit de onderhoudsstandaard ISO/IEC/IEEE 14764: correctief, adaptief, perfectief en preventief.
- Het eigenaarschap ligt bij één verantwoordelijke persoon of één team die code kan lezen en testen, zodra de app betalingen verwerkt of persoonsgegevens opslaat.
- 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.
- 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.
Wat houdt onderhoud van een AI-gebouwde app in?
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, onderscheidt typen onderhoudswerk. Vier daarvan sluiten direct aan op een AI-gebouwde app:
- Correctief: fouten herstellen die gebruikers of monitoring vinden, zoals een checkout die voor één betaalmethode mislukt.
- Adaptief: de app laten werken wanneer de omgeving verandert, zoals een nieuw mobiel besturingssysteem of een uitgefaseerde API-versie.
- Perfectief: de app verbeteren en functies toevoegen, zoals het volgende scherm dat u met een prompt bouwt.
- Preventief: toekomstige storingen voorkomen voordat ze ontstaan, zoals verouderde pakketten bijwerken of een back-up testen.
De lancering is het punt waar het bouwbudget stopt. De vier typen onderhoud lopen door zolang de app gebruikers heeft.
Waarom een AI-gebouwde app na de lancering een benoemde eigenaar nodig heeft
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.
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.
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.
6 onderhoudstaken die zonder eigenaar productie-incidenten worden
Elke 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.
Beveiligingspatches en updates van afhankelijkheden raken verouderd
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.
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; 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?”
Wijzigingen bij platforms en API’s van derden breken functies
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. Bestaande apps met een doelversie lager dan Android 15 zijn niet meer beschikbaar voor nieuwe gebruikers op nieuwere Android-apparaten.
Apple eist sinds 28 april 2026 dat apps die naar App Store Connect worden geüpload, met Xcode 26 zijn gebouwd. 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?”
Bij storingen reageert niemand
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.
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?”
Back-ups bestaan, maar herstel wordt nooit getest
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.
Bevat de app persoonsgegevens, dan vraagt artikel 32, lid 1, onder c van de AVG 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?”
Nieuwe functies breken oude functies
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.
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 en onze gids over AI technical debt. Vraag: “Welke van onze kritieke flows hebben geautomatiseerde tests?”
Accounts en toegang liggen bij één persoon
Als de accounts waarop uw app draait van een freelancer of één 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?
Controleer minstens deze acht accounts:
- domeinregistrar en DNS
- hosting- of cloudplatform
- database
- coderepository
- App Store Connect
- Google Play Console
- betaalprovider
- het account van de AI-codingtool waarin het project staat
Weet wat u overneemt
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.
Wie moet na de lancering eigenaar van uw app zijn?
Bij een live product met betalende gebruikers werkt één 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: één partij is verantwoordelijk voor alle vier de typen onderhoud.
| Eigenaar | Werkt als | Gaat mis als | Wat het bedrijf zelf in handen houdt |
|---|---|---|---|
| Oprichter met de AI-tool | De app heeft geen betalende gebruikers en geen persoonsgegevens | Een fix vraagt om iemand die de code leest, of een wijziging breekt een flow die niemand testte | Alles: accounts, code, back-ups |
| Freelancer | De app is klein en stabiel en één persoon kan het geheel overzien | De freelancer is niet beschikbaar, vertrekt of heeft de accounts op eigen naam | Alle accounts, de coderepository en een schriftelijk runbook |
| Het bureau dat de app bouwde | Het bureau kent de code en u legt een schriftelijke onderhoudsscope vast | Problemen herleiden naar de oorspronkelijke bouw en niemand kan het werk van het bureau zelf controleren | Accounts, repository en een onafhankelijke nulmeting van de code |
| Eerste engineer in dienst | Het product is de kern van het bedrijf en verandert elke maand | Eén persoon draagt alle kennis en bouwt ook nog nieuwe functies | Accounts, documentatie en een tweede persoon die kan deployen |
| Dedicated team of partner in productengineering | De app heeft betalende gebruikers, persoonsgegevens of meerdere platforms | Scope en eigenaarschap van beslissingen zijn niet vastgelegd | Accounts, repository en het recht om de code elders onder te brengen |
De voorwaarde die het antwoord verandert is risico, niet omvang. Het model van oprichter plus AI-tool houdt alleen stand zolang de app geen betalende gebruikers en geen persoonsgegevens heeft. Zodra u betalingen verwerkt of klantgegevens opslaat, hebt u een eigenaar nodig die de code van de tool kan lezen en vóór de release kan testen.
Wij zouden het onderhoud niet teruggeven aan het bureau dat de app bouwde zonder eerst een onafhankelijke nulmeting, omdat het bureau dan zijn eigen werk beoordeelt. De nieuwe eigenaar erft bovendien mogelijk code die hij niet zou willen behouden, waardoor het eigenaarschapsbesluit een besluit over refactoren of herbouwen wordt.
Zo draagt u het eigenaarschap van uw app over na de lancering
Het eigenaarschap van een app wisselt veilig van hand in vijf stappen, in deze volgorde: de eerste vier geven de nieuwe eigenaar controle en context, de vijfde laat zien wat hij erft.
Zet elk account op naam van het bedrijf
Voordat er iets aan de code verandert, brengt u elk productieaccount over naar een e-mailadres van het bedrijf en geeft u minstens twee mensen beheerrechten. Gebruik de lijst met acht accounts hierboven als checklist. Bewaar de inloggegevens in een wachtwoordmanager van het bedrijf, een gedeelde kluis waarin toegang kan worden verleend en ingetrokken, en niet in de browser of de notities van één persoon. Is de overdracht klaar, dan is de toegang van een freelancer intrekken een instelling en geen onderhandeling.
Schrijf op hoe de app draait en wordt gedeployd
Een kort runbook laat een nieuwe eigenaar vanaf de eerste week werken in plaats van de app te moeten reverse-engineeren. Twee pagina’s zijn genoeg om te beginnen: hoe u een wijziging deployt, waar de logs staan, hoe u een rollback uitvoert en welke omgevingsvariabelen er zijn. Omgevingsvariabelen zijn de instellingen en sleutels die de app bij het opstarten leest. Een rollback betekent teruggaan naar de vorige werkende versie wanneer een release misgaat.
Richt monitoring in en benoem een aanspreekpunt voor incidenten
Beschikbaarheidscontroles, foutregistratie en meldingen naar een benoemd persoon maken van storingen tickets in plaats van klachten van klanten. U hebt drie dingen nodig: een controle of de app reageert, een overzicht van fouten die gebruikers tegenkomen en een meldroute naar iemand die heeft toegezegd te handelen. Schrijf op wie dat is buiten kantooruren.
Leg de onderhoudsscope schriftelijk vast
Een onderhoudsovereenkomst moet vastleggen wat gedekt is, wat niet en hoe snel elk type probleem een reactie krijgt. Gedekt werk kan beveiligingspatches, platformupdates, incidentafhandeling, controles van back-ups en kleine fixes omvatten. Nieuwe functies zijn een apart besluit met een eigen budget. De verwachte reactietijd moet afhangen van de impact: een uitval van betalingen is niet hetzelfde als een typefout op een instellingenpagina.
Laat een onafhankelijke nulmeting van de codebase maken
Een onafhankelijke review laat de nieuwe eigenaar, en u, zien wat zij erven: beveiligingslekken, kwetsbare onderdelen, ontbrekende tests en wat het eerst moet worden opgelost. Zonder die nulmeting wordt elk later probleem een discussie over wie het veroorzaakte. Een AI-built product review geeft beide partijen dezelfde bevindingen voordat de onderhoudsovereenkomst ingaat.
Wat bepaalt de kosten van het onderhoud van uw app?
De kosten van het onderhoud van een app hangen minder af van hoe groot de app lijkt dan van vijf factoren, die elk bepalen hoeveel werk en risico één fix of update met zich meebrengt. Wij publiceren geen prijzen, omdat dezelfde factoren van product tot product zeer verschillende scopes opleveren.
Hoe leesbaar en getest de code is
Leesbare, geteste code maakt elke wijziging kleiner en veiliger, en dat is de grootste kostenfactor bij een AI-gebouwde app. Heeft code geen tests en geen duidelijke structuur, dan vraagt een fix van één regel uren aan controle van wat die nog meer raakt. Meet dit voordat u een onderhoudsscope afspreekt.
Op hoeveel integraties de app leunt
Elke externe dienst waarmee de app verbinding maakt, voegt onderhoud toe, omdat elke dienst op het tempo van zijn provider verandert. Betalingen, inloggen, e-mail, kaarten, analytics en API’s van AI-modellen hebben elk hun eigen versies, limieten en berichten.
Op hoeveel platforms u uitbrengt
Elk platform waarop u uitbrengt voegt een eigen releaseproces en eigen regels toe. Een webapp, een iOS-app en een Android-app betekenen drie releasepijplijnen, en de twee mobiele apps volgen elk de eisen van de stores, zoals de SDK-regels van Google Play en Apple hierboven.
Hoe gevoelig de data is
Persoons- of betaalgegevens leveren beveiligingswerk op dat nooit ophoudt. Artikel 32, lid 1, onder d van de AVG vraagt om een procedure voor het regelmatig testen, beoordelen en evalueren van de doeltreffendheid van de technische en organisatorische maatregelen ter beveiliging van de verwerking. In de praktijk betekent dat regelmatig patchen, toegangsrechten controleren en herstel testen, bovenop de gewone fixes.
Hoe snel het product nog verandert
Een product dat zijn markt nog zoekt, heeft elke sprint perfectief werk nodig, waardoor onderhoud en nieuwe ontwikkeling in elkaar overlopen. Een stabiele interne tool vraagt vooral om preventief en adaptief werk: patches, platformupdates en controles van back-ups.
Als onderhoud niet genoeg is: stabiliseren, refactoren of herbouwen
Onderhoud is in reddingswerk veranderd wanneer fixes meer problemen veroorzaken dan ze oplossen, of wanneer niemand de app kan aanpassen zonder iets te breken. Drie signalen laten die verschuiving zien: hetzelfde incident keert na elke fix terug, elke release breekt een flow waar niemand aan zat en geen ontwikkelaar neemt een wijziging aan zonder dat deel van de app eerst te herschrijven.
Dan is de eerste taak de schade te beperken. Onze gids over project rescue legt uit hoe u een falend AI-gebouwd product stabiliseert voordat u iets anders beslist. Is het product stabiel, dan staat de keuze tussen de bestaande code verbeteren en opnieuw beginnen in refactoren of herbouwen.
Hoe Sunbytes AI-gebouwde apps na de lancering ondersteunt
De overdrachtsstap die later geschillen voorkomt, is de onafhankelijke nulmeting. Zien de oprichter en de nieuwe eigenaar dezelfde bevindingen, dan wordt onderhoud een plan in plaats van een discussie over wie wat kapotmaakte.
De AI-built product review kijkt naar beveiliging en data, code en architectuur, betrouwbaarheid van kritieke flows, deployment en beheer, en onderhoudbaarheid en code-eigenaarschap. U ontvangt duidelijke bevindingen, een geprioriteerd actieplan en een technische overdracht waarmee de volgende eigenaar aan de slag kan. De uitvoering is Nederlands geleid en ISO 27001-gecertificeerd, met meer dan 15 jaar ervaring in softwarelevering en meer dan 300 opgeleverde projecten.
Blijkt uit de bevindingen dat de app een eigenaar voor de lange termijn nodig heeft, dan kan ons team productengineering de Run-fase overnemen (monitoring, back-ups, deploymentondersteuning en afgesproken serviceniveaus) en de Evolve-fase voor nieuwe ontwikkeling. De scope bepalen we per geval. Bespreek een review met ons voordat u een onderhoudsovereenkomst tekent.
