Blijft een AI-gebouwd product haperen, dan is een nieuwe prompt of een volledige herbouw niet automatisch de volgende stap. Eerst moet het product stabiel worden, moet de toegang tot code en data veilig zijn en moet duidelijk zijn wat de fouten veroorzaakt. Pas daarna beslist u hoe u het product herstelt.
Software project rescue verloopt in vier stappen: stabiliseren, beoordelen, beslissen en herstellen. Zo ziet u welke problemen op te lossen zijn, of onderdelen herbouwd moeten worden en wanneer stoppen zakelijk de betere keuze is. U leest ook wanneer specialistische hulp nodig is en waar u op let bij het kiezen van een rescuepartner.
TL;DR
Software project rescue betekent dat u de regie neemt over een falend softwareproduct, vaststelt wat nog werkt en beslist of u het oplost, onderdelen herbouwt of stopt.
- Blootgestelde gegevens, betaalfouten en storingen gaan voor alles: beperk de toegang, vervang gelekte keys gecontroleerd en ga na of een datalek gemeld moet worden volgens artikel 33 van de AVG (GDPR).
- Specialistische hulp levert het meeste op wanneer fouten terugkomen zonder duidelijke oorzaak, gevoelige gegevens of betalingen geraakt kunnen zijn, een grote herbouwbeslissing bewijs vraagt dat verder gaat dan de aannames van het oorspronkelijke team, of niemand in het bedrijf de code kan lezen.
- Stoppen is het overwegen waard wanneer het product geen haalbare businesscase meer heeft, de waarde niet opweegt tegen de kosten en het risico van herstel, of een geschikt alternatief de zakelijke behoefte beter invult.
Zo redt u een falend AI-gebouwd project
De vier stappen hieronder vormen een werkkader, geen verplichte procedure. Urgente inperking kan tegelijk met de beoordeling lopen, en fouten waarvan de oorzaak bekend is, kunt u al oplossen voordat alle bevindingen binnen zijn. Waar het om gaat: neem geen grote beslissing, zoals een herbouw, vóór de beoordeling. De stappen passen de aanpak voor het veilig lanceren van AI-gebouwde producten toe op een product dat al in de problemen zit.
Stap 1: Stabiliseer het product en stel de toegang veilig
Een AI-gebouwd product stabiliseren betekent dat u wijzigingen beperkt totdat iemand de huidige staat begrijpt. Pauzeer niet-essentiële features en ongecontroleerde wijzigingen, ook het opnieuw genereren van code met de AI-tool op de live versie. Urgente fixes voor beveiliging en betrouwbaarheid moeten wel kunnen blijven doorgaan. Wijs één beslisser aan voor wijzigingen in productie, leg de huidige staat vast en zorg dat kritieke wijzigingen te testen en terug te draaien zijn.
Breng daarna alle kritieke accounts in kaart, stel vast wie ze beheert en regel toegang die het bedrijf heeft geautoriseerd. Begin met deze diensten:
- de coderepository (bijvoorbeeld GitHub of GitLab) en de werkomgeving van de AI-builder
- hosting- en deploymentdiensten
- de database en de authenticatiedienst (bijvoorbeeld Supabase of Firebase)
- het domein en de DNS-instellingen
- betalingen (bijvoorbeeld Stripe) en de ontwikkelaarsaccounts voor de App Store of Google Play
Noteer welke accounts een formele overdracht nodig hebben en plan eigendomswijzigingen en het vervangen van inloggegevens zo dat essentiële processen doorlopen. Een vervangen key moet u bijwerken in elk systeem dat hem gebruikt, en daarna controleert u of de dienst nog werkt. Verhuist een repository, dan gaan issues, pull requests en de wiki mee, volgens de documentatie van GitHub. Maak een databaseback-up die het bedrijf zelf beheert. Zijn klantgegevens mogelijk al blootgesteld, stel dan vast of er sprake is van een datalek: de meldtermijn van de AVG gaat in op het moment dat de verwerkingsverantwoordelijke ervan op de hoogte is.
Stap 2: Beoordeel wat kapot is en wat nog werkt
Bij de beoordeling scheidt u wat nog werkt van wat misgaat, nog vóórdat u iets beslist. Begin bij de kritieke flows die omzet opleveren of persoonsgegevens bevatten, zoals aanmelden, inloggen, betalen en beheerschermen. Leg vast wat er misgaat, onder welke omstandigheden en sinds wanneer. Herleid daarna elke fout tot de oorzaak in de code, de gegevensverwerking, de configuratie of de deployment, in plaats van alleen het symptoom te verhelpen.
Toegangscontrole heeft voorrang: broken access control staat op de eerste plaats in de OWASP Top 10:2025. Kunnen gebruikers gegevens van andere gebruikers inzien, behandel dat dan als een mogelijk beveiligingsincident dat snel onderzocht en ingeperkt moet worden, niet als een gewone fout in de applicatie. De gids over een AI code audit beschrijft wat een volledige beoordeling omvat; voor AI-gebouwde producten voert Sunbytes die uit als AI-built product review.
Verdeel de bevindingen in twee groepen: nu oplossen (blootgestelde gegevens, betaalfouten, storingen) en later verbeteren (codestructuur, prestaties, onderhoudbaarheid).
Twijfelt u of uw product een rescue nodig heeft of alleen een paar fixes? Een AI-built product review bekijkt software-engineering en security in samenhang en laat zien wat nu moet en wat kan wachten. Bespreek uw AI-built product review →
Stap 3: Beslis: oplossen, herbouwen of stoppen
Later beslissen betekent dat de beslissing volgt uit de beoordeling, niet uit hoeveel frustratie het product inmiddels oplevert:
- Gericht oplossen wanneer de kernlogica van het product correcte resultaten geeft en de fouten zich beperken tot een paar onderdelen, zoals inloggen, rechten of betalingen.
- Falende onderdelen herbouwen wanneer het datamodel of de architectuur op specifieke punten niet klopt, terwijl de rest blijft draaien. De keuze tussen refactoren en herbouwen behandelt de signalen; Product Engineering beschrijft een gefaseerde herbouw.
- Overwegen te stoppen wanneer het product geen haalbare businesscase meer heeft, de waarde niet opweegt tegen de kosten en het risico van herstel, of een geschikt alternatief de zakelijke behoefte beter invult. Weeg vóór de beslissing de verplichtingen tegenover klanten, de verplichtingen rond gegevens en de kosten van het afbouwen mee.
Valt het besluit op stoppen, dan vraagt het afbouwen nog werk: geef gebruikers een einddatum, lever de gegevens aan die zij opvragen, bewaar geen persoonsgegevens die u niet meer nodig hebt (artikel 5, lid 1, onder e AVG), handel verzoeken tot verwijdering af volgens artikel 17, trek API-keys in en zeg betaalde diensten op.
Stap 4: Herstel veilig en leg het eigenaarschap vast
Herstellen betekent fixes in kleine stappen uitrollen, elk met monitoring en, waar de wijziging dat toelaat, een manier om terug te draaien. Niet elke wijziging is makkelijk terug te draaien: databasemigraties en datacorrecties vragen eerst een back-up en een testrun. Spreek één regel af voor de AI-codingtool: wijzigingen gaan naar een aparte branch en een mens beoordeelt ze vóór de release. Leg daarna vast welke persoon of welk team na de rescue eigenaar van het product is; onderhoud van een AI-gebouwde app beschrijft wat dat eigenaarschap inhoudt.
Is uw AI-gebouwde product nog te redden?
Een AI-gebouwd product is te redden wanneer de kernlogica correcte resultaten geeft en de fouten zitten in herkenbare onderdelen zoals inloggen, gegevenstoegang, betalingen of deployment. Klopt de bedrijfslogica zelf niet, dan maakt het repareren van code het product niet bruikbaar: dan moet het businessmodel eerst opnieuw ontworpen of gevalideerd worden. Tabel 1 helpt bij de technische diagnose; tabel 2 ondersteunt de zakelijke beslissing.
| Symptoom | Mogelijke oorzaak | Directe actie |
|---|---|---|
| Elke fix breekt een andere functie | Geen geautomatiseerde tests die laten zien wat een wijziging kapotmaakt | Pauzeer niet-essentiële wijzigingen; noteer de kapotte flows |
| Werkt in preview, faalt in productie | Ontbrekende omgevingsvariabelen, buildinstellingen of hostingconfiguratie | Vergelijk de configuratie van preview en productie |
| Gebruikers zien gegevens van anderen | Ontbrekende rechtencontroles of toegangsregels in de database | Beperk de toegang en onderzoek het als mogelijk beveiligingsincident |
| Inloggen of betalen werkt wisselend | Fouten in de sessielogica; bij betalingen kunnen niet-geverifieerde events een oorzaak zijn | Test beide flows van begin tot eind en controleer hoe betaalevents worden geverifieerd |
| Kosten stijgen zonder nieuwe features | Herhaald genereren of onbeperkte aanroepen van AI-model-API’s | Stel bestedingslimieten in en bekijk de gebruikslogs |
| Niemand kan een kernflow uitleggen | Geen documentatie; oorspronkelijke bouwer niet bereikbaar | Regel eerst toegang tot de repository en de lijst met bekende fouten |
| Beveiligingswaarschuwingen of gelekte keys | Secrets in de frontendcode | Verplaats secrets naar de server en vervang de keys volgens plan |
Twee van deze oorzaken staan beschreven in de documentatie van de platforms zelf. De documentatie van Supabase meldt dat een tabel in een blootgesteld schema zonder RLS leesbaar en schrijfbaar is voor elke rol die er rechten op heeft; de row-level-security-instelling van elke blootgestelde tabel hoort daarom in de beoordeling. De documentatie van Stripe waarschuwt dat een aanvaller zonder handtekeningverificatie valse webhookevents naar uw endpoint kan sturen. Niet-geverifieerde webhooks zijn dus één oorzaak om uit te sluiten wanneer betalingen haperen. Gelekte keys komen uitgebreid aan bod in gelekte API keys in AI-producten.
Meer prompten kan deze symptomen verergeren wanneer er geen tests zijn die laten zien wat een wijziging kapotmaakt: elke prompt verhelpt het beschreven symptoom, en een opnieuw gegenereerd bestand kan een eerdere fix ongedaan maken. In een gebruikersonderzoek van Perry et al. uit 2023 schreven deelnemers met een AI-assistent bij de beveiligingstaken uit het onderzoek significant minder veilige code, en ze dachten vaker dat hun code veilig was. Het onderzoek mat code uit gecontroleerde opdrachten, niet de beveiliging van AI-gebouwde producten op de markt, maar het onderbouwt dat een mens AI-gegenereerde fixes vóór de release beoordeelt.
| Situatie | Oordeel | Volgende stap |
|---|---|---|
| De businesscase staat, fouten zijn op zichzelf staand, geen risico voor gegevens of betalingen | Doorgaan | Los de problemen op en laat de code beoordelen vóór de volgende release |
| De businesscase staat, maar fouten komen terug of gegevens of betalingen lopen risico | Redden | Perk urgente problemen in, stabiliseer en beoordeel daarna |
| Geen haalbare businesscase, kosten en risico van herstel wegen niet op tegen de waarde, of een geschikt alternatief vult de behoefte beter in | Overwegen te stoppen | Breng verplichtingen tegenover klanten, verplichtingen rond gegevens en afbouwkosten in kaart |
Wie moet uw softwareproject redden?
De oorspronkelijke ontwikkelaar kan problemen met een bekende oorzaak onderzoeken en oplossen, zeker wanneer die het systeem kent en verantwoordelijk blijft voor het werk. Een onafhankelijke beoordeling wordt waardevoller wanneer fouten terugkomen zonder duidelijke oorzaak, gevoelige gegevens of betalingen geraakt kunnen zijn, of een grote herbouwbeslissing bewijs vraagt dat verder gaat dan de aannames van het oorspronkelijke team.
| Optie | Werkt wanneer | Let op |
|---|---|---|
| Oorspronkelijke ontwikkelaar | De oorzaak van de problemen bekend is, de ontwikkelaar het systeem kent en verantwoordelijk blijft, en het bedrijf veilige toegang heeft tot alle kritieke accounts | Terugkerende fouten zonder duidelijke oorzaak vragen om een tweede blik |
| Externe reviewer | U vóór een grote beslissing een betrouwbare beoordeling nodig hebt | Een beoordeling lost zelf niets op; voor de fixes is een team nodig |
| Rescueteam | U de beoordeling en de fixes bij één partij wilt beleggen | Spreek schriftelijke bevindingen af voordat er een fix begint |
| Intern team | U ontwikkelaars hebt of aanneemt die het product op lange termijn beheren | Het team heeft eerst de beoordeling en veilige toegang tot de accounts nodig |
Waarschuwingssignalen bij het kiezen van een rescuepartner:
- een volledige herbouw voorstellen voordat iemand de code heeft gelezen
- een vaste scope of prijs vóór enige beoordeling
- accounts op naam van de partner houden in plaats van op naam van het bedrijf
- geen schriftelijke bevindingen of onderbouwing bij de aanbevelingen
- de belofte dat de AI-tool alles sneller oplost
- bevindingen die niet in gewone taal uit te leggen zijn
Wat bepaalt de scope en de kosten van een rescue?
De scope van een rescue hangt af van de omvang en complexiteit van het product, het aantal gebruikers dat ervan afhankelijk is en de staat van de code. Omvang alleen beslist het niet: een kleine app met blootgestelde klantgegevens kan meer spoed vragen dan een grotere app met goede toegangsregels. Vier groepen factoren bepalen de inspanning:
- Toegang en eigenaarschap: accounts en inloggegevens die ontbreken of bij iemand anders liggen
- Risico: of klantgegevens of betalingen geraakt zijn, en hoeveel actieve gebruikers van het product afhankelijk zijn
- Technische staat: de omvang van de codebase, de integraties en of er tests en documentatie zijn
- De beslissing: of de beoordeling leidt tot oplossen, herbouwen of stoppen
Omdat elk van deze factoren per product verschilt, bepaalt Sunbytes de scope van elke rescue per geval; neem contact op over een review voor advies over uw product.
Hoe Sunbytes helpt bij de rescue van AI-gebouwde producten
Een app rescue loont pas wanneer de beoordeling na het stabiliseren helder genoeg is om op te beslissen. De AI-built product review van Sunbytes is voor die stap gemaakt. Daarin worden de code, architectuur, beveiliging, betrouwbaarheid en deployment achter een AI-gebouwd product beoordeeld, met software-engineering en security in samenhang: authenticatie, rechten, toegang tussen gebruikers, gelekte secrets en databaseregels.
De review levert duidelijke bevindingen met onderbouwing op, een geprioriteerd actieplan dat scheidt wat nu moet en wat kan wachten, en een technische overdracht waarmee uw team of uw AI-codingtool verder kan. Uw team voert de fixes uit, of Sunbytes lost de prioriteiten op en controleert ze opnieuw. Moeten onderdelen opnieuw worden ontworpen, dan start Product Engineering met een Product Blueprint en loopt daarna door Rebuild, Run en Evolve, waar mogelijk terwijl het bestaande product blijft draaien.
Het werk staat onder Nederlandse leiding, valt onder ISO 27001-gecertificeerd beveiligingsmanagement, met meer dan 15 jaar ervaring in softwareontwikkeling en ruim 300 projecten. Blijft uw product haperen? Neem contact op over een review en baseer uw volgende stap op bewijs.
