Så uppdaterar du din AI-byggda app utan att ha sönder den för dem som redan använder den

Den första versionen av din app var lätt att ändra. Om något gick sönder var den enda som märkte det du. Sedan började riktiga människor använda den – och nu känns varje ändring som operation på en patient som är vaken. Att lära sig uppdatera sin AI-byggda app utan att ha sönder den är mest en fråga om rutin, och rutinen är mindre än du skulle tro.

En ägare av ett läxhjälpsföretag vi känner lärde sig detta den smärtsamma vägen. Hennes bokningsapp hade rullat på smidigt i månader, så en kväll bad hon sin AI-byggare om en liten förbättring: byt namn på “Session” till “Lektion” överallt, eftersom det var ordet hennes handledare faktiskt använde. Byggaren bytte glatt namn på det – inklusive, visade det sig, stället där befintliga bokningar lagrades. Nästa morgon öppnade tre handledare sina kalendrar och fann dem tomma. Datan var inte borta, men appen kunde inte längre hitta den, och hon tillbringade en stressig dag med att få den återansluten.

Inget med den ändringen var orimligt. Hon hade bara ingen rutin än för hur man uppdaterar sin AI-byggda app när den väl har användare. Det här inlägget är den rutinen – fyra vanor som tar kanske femton extra minuter per ändring och förhindrar de flesta katastroferna.

Varför uppdateringar känns annorlunda när du har användare

Tre saker ändras i samma stund någon annan förlitar sig på din app:

Det finns data i den nu. Ändringar som var harmlösa på en tom app – byta namn på saker, strukturera om formulär – kan koppla bort eller röra till information folk redan matat in.
Folk har vanor. Dina användare lärde sig var knapparna är. Även en förbättring är en störning om den flyttar något de använder varje dag.
Du kan inte välja när problem dyker upp. När appen var bara din spelade en trasig kväll ingen roll. Nu är en trasig tisdagsmorgon tre handledare med tomma kalendrar.

Inget av detta betyder att du ska sluta förbättra din app. Appar som slutar ändras dör långsamt i stället för plötsligt. Det betyder att ändringar behöver lite ceremoni.

Vana 1: säkerhetskopiera innan du rör något

Det här är den icke förhandlingsbara. Innan någon ändring större än att fixa ett stavfel, se till att du har en aktuell säkerhetskopia av din apps data – och vet hur du återställer den.

Om du redan har satt upp automatiska säkerhetskopior krymper den här vanan till en fråga till din AI-byggare: “När togs den senaste säkerhetskopian, och hur skulle jag återställa den?” Om svaret är säkert och färskt, kör på. Om du inte har satt upp säkerhetskopior än, gör det innan din nästa uppdatering – vi skrev en komplett guide till att säkerhetskopiera din AI-byggda app, och det är den bästa timmen du lägger på din produkt den här månaden.

Berättelsen om läxhjälpsappen ovan fick ett lyckligt slut just för att hennes plattform behöll säkerhetskopior. Den stressiga dagen hade annars varit en katastrofal.

Vana 2: fråga “vad kan det här ha sönder?” innan du säger ja

Här är frågan de flesta byggare aldrig tänker på att ställa, och den gör mer än de andra tre vanorna tillsammans. Efter att du beskrivit en ändring för din AI-byggare, och innan du godkänner den, lägg till en rad:

“Innan du gör den här ändringen – vilka befintliga funktioner eller vilken data kan den påverka?”

Det här fungerar för att AI:n oftast kan se kopplingarna du inte kan. Ägaren av handledarappen kunde inte veta att “Session” också var namnet på stället där bokningar bodde. Byggaren visste – hon frågade bara aldrig. När hon byggde om sin rutin efteråt blev den här enda frågan steget som fångade problem: den flaggade att en ändring av hennes prisformulär skulle påverka två gamla fakturor, och att lägga till ett obligatoriskt fält skulle blockera befintliga kunder som registrerat sig utan det.

Läs svaret som en pilot läser en väderrapport. “Det här är kosmetiskt, inget annat rör vid det” – klar himmel, kör. “Det här ändrar hur bokningar lagras” – det är din signal att sakta ner, säkerhetskopiera igen, och kanske be om en mildare version av ändringen.

Vana 3: ändra en sak i taget, och testa den som en främling

Att bunta ihop fem förbättringar i en stor uppdatering känns effektivt. Det är faktiskt tvärtom: när något går sönder vet du inte vilken av de fem som orsakade det, och att ångra den trasiga betyder att ångra alla fem.

En ändring, sedan kontrollera. Kontrollerandet spelar lika stor roll som uppdelningen:

Använd ett andra konto, inte ditt ägarkonto. Du ser appen som dess administratör; dina användare gör inte det. Logga in som en vanlig användare – behåll ett permanent testkonto för precis detta – och gå igenom vägen din ändring berörde. (Om du aldrig testat din egen app förut, så här gör du det utan QA-bakgrund.)
Kontrollera det du ändrade, och saken bredvid. Om du uppdaterade bokningsformuläret, gör en bokning – öppna sedan också en gammal bokning och se till att den fortfarande visas. Det mesta som går sönder av uppdateringar dyker upp i gammal data, inte ny.
Gör det nu, inte imorgon. Testa direkt efter ändringen, medan den är färsk och liten. Ett problem som hittas fem minuter efter uppdateringen är uppenbart orsakat av uppdateringen. Ett problem som hittas på fredag kan vara vad som helst.

Vana 4: välj ett lugnt ögonblick, och känn till din ångra-väg

Två sista bitar timing-känsla som proffs använder och icke-utvecklare sällan hör talas om:

Skeppa när dina användare är borta. Du känner förmodligen din apps rytm – läxhjälpsappen var mest aktiv på vardagseftermiddagar, nästan tyst på söndagskvällar. Söndagskväll är när ändringar händer. Om något går fel har du timmar att fixa det innan någon dyker upp, i stället för minuter.

Känn till din ångra-väg innan du behöver den. Fråga din AI-byggare: “Om den här ändringen orsakar problem, kan du återställa den? Vad skulle det kräva?” Ibland är svaret “ett klick”. Ibland är det “att återställa ändringen är enkelt, men data som skapats efter ändringen kanske inte passar den gamla versionen”. Du vill höra det svaret medan du är lugn, inte medan tre handledare messar dig.

Och när en ändring är synlig för användare – en flyttad knapp, ett omdöpt fält, ett nytt steg – berätta för dem. Ett kort meddelande (“Du kommer att märka att Sessioner nu kallas Lektioner – samma bokningar, vänligare namn”) förvandlar en förvirrande överraskning till ett tecken på att någon aktivt tar hand om produkten de förlitar sig på.

Femtonminutersversionen

Här är hela rutinen, liten nog att ha på en post-it-lapp: säkerhetskopiera nuvarande → fråga vad som kan gå sönder → en ändring i taget → testa som en främling, gammal data inkluderad → lugna timmar → känn till din ångra-väg → berätta för dina användare.

Ägarna som följer något i den här stilen uppdaterar inte sina AI-byggda appar mindre än de vårdslösa – de uppdaterar mer, eftersom varje ändring slutar vara en chansning. Det är den verkliga utdelningen: inte att undvika att saker går sönder, utan att hålla sig trygg nog att fortsätta förbättra det folk räknar med.

Nästa gång du ska be din byggare om en ändring, prova enradsfrågan från Vana 2 och se vad den får fram. Och om det här är inlägget som äntligen får dig att sätta upp säkerhetskopior – börja här.