Hoe je je met AI gebouwde app bijwerkt zonder hem te breken voor de mensen die hem al gebruiken

De eerste versie van je app was makkelijk te veranderen. Als er iets brak, was de enige persoon die het merkte jij. Toen begonnen echte mensen hem te gebruiken — en nu voelt elke wijziging als een operatie op een patiënt die wakker is. Leren je met AI gebouwde app bij te werken zonder hem te breken is grotendeels een kwestie van routine, en de routine is kleiner dan je zou denken.

Een eigenaar van een bijlesbedrijf die we kennen leerde dit op de pijnlijke manier. Haar planningsapp had maandenlang vlot gedraaid, dus op een avond vroeg ze haar AI-bouwer om een kleine verbetering: hernoem “Sessie” naar “Les” overal, omdat dat het woord was dat haar bijlesdocenten echt gebruikten. De bouwer hernoemde het vrolijk — inclusief, zo bleek, de plek waar bestaande boekingen werden opgeslagen. De volgende ochtend openden drie bijlesdocenten hun agenda’s en vonden ze leeg. De data was niet weg, maar de app kon hem niet meer vinden, en ze besteedde een stressvolle dag aan het opnieuw verbinden ervan.

Niets aan die wijziging was onredelijk. Ze had gewoon nog geen routine voor hoe je je met AI gebouwde app bijwerkt zodra hij gebruikers heeft. Deze post is die routine — vier gewoonten die misschien vijftien extra minuten per wijziging kosten en de meeste rampen voorkomen.

Waarom updates anders voelen zodra je gebruikers hebt

Drie dingen veranderen op het moment dat iemand anders op je app vertrouwt:

Er zit nu data in. Wijzigingen die ongevaarlijk waren op een lege app — dingen hernoemen, formulieren herstructureren — kunnen informatie die mensen al invoerden ontkoppelen of door elkaar husselen.
Mensen hebben gewoonten. Je gebruikers leerden waar de knoppen zijn. Zelfs een verbetering is een verstoring als het iets verplaatst dat ze elke dag gebruiken.
Je kunt de timing van problemen niet kiezen. Toen de app alleen van jou was, maakte een kapotte avond niet uit. Nu is een kapotte dinsdagochtend drie bijlesdocenten met lege agenda’s.

Niets hiervan betekent dat je moet stoppen met je app verbeteren. Apps die stoppen met veranderen sterven langzaam in plaats van plotseling. Het betekent dat wijzigingen een beetje ceremonie nodig hebben.

Gewoonte 1: maak een back-up voordat je iets aanraakt

Dit is de niet-onderhandelbare. Voordat je een wijziging maakt die groter is dan een typefout repareren, zorg dat je een actuele back-up van de data van je app hebt — en weet hoe je hem herstelt.

Als je al automatische back-ups hebt ingesteld, krimpt deze gewoonte tot één vraag voor je AI-bouwer: “Wanneer was de laatste back-up, en hoe zou ik hem herstellen?” Als het antwoord zelfverzekerd en recent is, ga door. Als je nog geen back-ups hebt ingesteld, doe dat voor je volgende update — we schreven een volledige gids voor het back-uppen van je met AI gebouwde app, en het is het beste uur dat je deze maand aan je product zult besteden.

Het bijlesapp-verhaal hierboven had een gelukkig einde juist omdat haar platform back-ups bijhield. De stressvolle dag zou anders een catastrofale zijn geweest.

Gewoonte 2: vraag “wat zou dit kunnen breken?” voordat je ja zegt

Hier is de vraag die de meeste bouwers er nooit aan denken te stellen, en hij doet meer werk dan de andere drie gewoonten samen. Nadat je een wijziging aan je AI-bouwer hebt beschreven, en voordat je hem goedkeurt, voeg één regel toe:

“Voordat je deze wijziging maakt — welke bestaande functies of data zou hij kunnen beïnvloeden?”

Dit werkt omdat de AI meestal de verbindingen kan zien die jij niet kunt. De bijlesapp-eigenaar kon niet weten dat “Sessie” ook de naam was van de plek waar boekingen leefden. De bouwer wist het — ze vroeg het gewoon nooit. Toen ze haar routine daarna opnieuw opbouwde, werd deze ene vraag de stap die problemen ving: hij signaleerde dat het veranderen van haar prijsformulier twee oude facturen zou beïnvloeden, en dat het toevoegen van een verplicht veld bestaande klanten zou blokkeren die zich hadden aangemeld zonder het.

Lees het antwoord zoals een piloot een weerbericht leest. “Dit is cosmetisch, niets anders raakt het aan” — heldere lucht, ga. “Dit zal aanpassen hoe boekingen worden opgeslagen” — dat is je signaal om te vertragen, opnieuw te back-uppen, en misschien om een zachtere versie van de wijziging te vragen.

Gewoonte 3: verander één ding tegelijk, en test het als een vreemde

Vijf verbeteringen bundelen in één grote update voelt efficiënt. Het is eigenlijk het tegenovergestelde: wanneer er iets breekt, weet je niet welke van de vijf het veroorzaakte, en de kapotte ongedaan maken betekent alle vijf ongedaan maken.

Eén wijziging, dan checken. Het checken doet er net zoveel toe als het opsplitsen:

Gebruik een tweede account, niet je eigenaarsaccount. Jij ziet de app als beheerder; je gebruikers niet. Log in als een gewone gebruiker — houd een permanent testaccount voor precies dit aan — en loop het pad door dat je wijziging raakte. (Als je je eigen app nog nooit hebt getest, hier is hoe je het doet zonder QA-achtergrond.)
Check het ding dat je veranderde, en het ding ernaast. Als je het boekingsformulier bijwerkte, maak een boeking — open dan ook een oude boeking en zorg dat hij nog steeds wordt weergegeven. De meeste breuken van updates duiken op in oude data, niet in nieuwe.
Doe het nu, niet morgen. Test meteen na de wijziging, terwijl hij vers en klein is. Een probleem gevonden vijf minuten na de update wordt overduidelijk veroorzaakt door de update. Een probleem gevonden op vrijdag kan van alles zijn.

Gewoonte 4: kies een rustig moment, en ken je ongedaan-maken

Twee laatste stukjes timinggevoel dat professionals gebruiken en niet-ontwikkelaars zelden over horen:

Lanceer wanneer je gebruikers weg zijn. Je kent waarschijnlijk het ritme van je app — de bijlesapp was het drukst op weekdagmiddagen, vrijwel stil op zondagavonden. Zondagavond is wanneer wijzigingen gebeuren. Als er iets misgaat, heb je uren om het te repareren voordat iemand arriveert, in plaats van minuten.

Ken je ongedaan-maken voordat je het nodig hebt. Vraag je AI-bouwer: “Als deze wijziging problemen veroorzaakt, kun je hem terugdraaien? Wat zou dat kosten?” Soms is het antwoord “één klik”. Soms is het “de wijziging terugdraaien is makkelijk, maar data aangemaakt na de wijziging past misschien niet in de oude versie”. Je wilt dat antwoord horen terwijl je kalm bent, niet terwijl drie bijlesdocenten je berichten sturen.

En wanneer een wijziging zichtbaar is voor gebruikers — een verplaatste knop, een hernoemd veld, een nieuwe stap — vertel het ze. Eén kort bericht (“Je merkt dat Sessies nu Lessen heten — dezelfde boekingen, vriendelijkere naam”) verandert een verwarrende verrassing in een teken dat iemand actief zorgt voor het product waar ze op vertrouwen.

De vijftien-minuten-versie

Hier is de hele routine, klein genoeg om op een plakbriefje te houden: huidige back-up → vraag wat zou kunnen breken → één wijziging tegelijk → test als een vreemde, oude data inbegrepen → rustige uren → ken je ongedaan-maken → vertel je gebruikers.

De eigenaren die zoiets volgen, werken hun met AI gebouwde apps niet minder bij dan de roekeloze — ze werken meer bij, omdat elke wijziging ophoudt een gok te zijn. Dat is de echte beloning: niet breuk vermijden, maar zelfverzekerd genoeg blijven om het ding dat mensen op rekenen te blijven verbeteren.

De volgende keer dat je op het punt staat je bouwer om een wijziging te vragen, probeer de eenregelige vraag uit gewoonte 2 en zie wat het bovenbrengt. En als dit de post is die je eindelijk zover krijgt om back-ups in te stellen — begin hier.