Vad du ska göra när din AI-byggda app går sönder klockan två på natten (och du inte är utvecklare)

Du byggde en app utan att skriva en rad kod. Den fungerade hela veckan. Sedan messar en användare dig klockan 01:47 och säger att registreringsknappen inte gör något, och du vaknar av att din telefon lyser på nattduksbordet.

Om du aldrig har behövt fixa en live-app förut kan det här ögonblicket kännas hemskt. Du läser inte kod. Du vet inte vad “databasen” egentligen betyder. Du är inte säker på om det är trasigt-trasigt eller bara-konstigt, och de som normalt skulle hjälpa dig sover.

Här är en lugn, ordnad spelbok för vad du ska göra när en AI-byggd app går sönder och du inte kan skriva kod. Det mesta handlar om att inte göra saker värre, vilket är den del ingen varnar dig för.

Först: deploya inte om

Det finns en knapp någonstans i din AI-appbyggare som säger något i stil med “publicera om”, “deploya om” eller “skeppa”. Du är på väg att vilja trycka på den. Gör det inte, än.

Att trycka på deploya-om på en halvtrasig app kan låsa in det trasiga tillståndet, blåsa bort vilken felsökningsinformation som än låg och rörde sig, och göra det svårare för någon – inklusive AI-byggaren själv – att lista ut vad som gick fel.

Det första draget är alltid att titta, inte att agera. Du har inte ens bekräftat vad som är trasigt än.

Steg 1 – Återskapa problemet själv

Öppna appen i ett färskt webbläsarfönster – inkognito- eller privat läge är bäst, eftersom det tar bort gammal inloggning eller cache som kan få saker att bete sig annorlunda för dig än för din användare.

Försök göra exakt det användaren rapporterade. Om de sa att registreringsknappen inte fungerar, försök registrera dig. Om de sa att instrumentpanelen är tom, försök logga in och titta på instrumentpanelen.

Du letar efter en av tre saker:

Det är trasigt för alla. Du stöter på samma problem. Det är faktiskt den lättaste sorten att fixa, eftersom det är konsekvent.
Det fungerar för dig. Det här är det svåraste scenariot, eftersom något med användarens specifika situation (deras webbläsare, deras konto, deras data) är problemet.
Det är sporadiskt. Det fungerar en gång och går sönder nästa gång. Det här är det mest stressande men också det mest informativa – det betyder oftast att något tajmar ut eller får slut på en resurs.

Skriv ner vilken av de tre du såg. Du behöver det när du ber om hjälp.

Steg 2 – Kontrollera de uppenbara externa sakerna innan du skyller på din app

Ett förvånande antal “min app är trasig”-ögonblick är inte din app. Innan du gräver ner dig i din AI-byggare, kontrollera:

Fungerar internet i sig? Öppna ett par andra sajter. Om ditt wifi krånglar kan din app vara fin och det kan vara du som är trasig.
Hade AI-byggaren själv ett driftstopp? De flesta AI-appbyggare har en statussida (sök på produktnamnet plus “status”). Om de har en dålig natt behöver du inte lista ut något annat.
Gick ett av dina anslutna verktyg ner? Om din app använder Stripe för betalningar, en e-posttjänst för aviseringar eller en databastjänst för att lagra data, kan vilken som helst av dem ha driftstopp. Var och en har sin egen statussida. Kontrollera de din app beror på.

Ungefär en gång på fem är svaret “det är faktiskt inte min app”, och du kan gå tillbaka och sova.

Steg 3 – Titta på felmeddelandet, även om det skrämmer dig

Om din app visar en skärm med text på – även text som ser ut som rappakalja – läs den. Ta en skärmdump. Särskilt om det finns en lång sträng av bokstäver och siffror (folk kallar det en “stack trace”; det ser ut som alfabetssoppa men det är det mest användbara du kan ha när du ber om hjälp).

De flesta AI-appbyggare har också ett ställe att se fel som hänt nyligen. Det kan heta Loggar, Aktivitet, Fel eller Konsol. Öppna det. Du behöver inte förstå det mesta du ser – du letar efter den senaste röda texten eller det senaste felet, och tidpunkten det hände. Tid spelar roll: ett fel från igår morse är förmodligen inte varför din användare inte kunde registrera sig just nu.

Kopiera det felet. Du ska klistra in det någonstans hjälpsamt om en stund.

Steg 4 – Fråga AI-byggaren vad som ändrades

Det här är draget de flesta icke-tekniska byggare underutnyttjar. Öppna chatten med din AI-byggare och säg, på vanligt språk:

“Min app är trasig. Användare kan inte registrera sig – knappen gör inget. Här är felet från loggarna: [klistra in det]. Vad ändrades under de senaste 24 timmarna, och vad kan orsaka det här?”

En bra AI-byggare berättar vilken nyligen gjord ändring som mest troligt är ansvarig. Ibland känner du igen det direkt (“jaha, jag bad den att göra formuläret snyggare igår och det har förmodligen sönder skicka-logiken”). Ibland pekar den på något du inte minns att du rörde, vilket också är användbart – det betyder att något automatiskt ändrades, som ett anslutet verktyg som uppdaterades.

Låt inte AI-byggaren börja göra fixar än. Du är fortfarande i diagnosläge. Det vanligaste sättet jag sett folk göra ett litet problem värre är att låta en AI börja “fixa” saker innan någon förstår vad som är trasigt.

Steg 5 – Avgör om du ska rulla tillbaka

Nästan varje AI-appbyggare låter dig gå tillbaka till en tidigare version av din app. Ibland kallas det “historik”, “versioner”, “checkpoints” eller “rollback”.

Om du tydligt kan minnas en timme eller en dag när appen fungerade är det enskilt mest pålitliga draget att gå tillbaka till den versionen. Det kostar dig vilka ändringar du än gjorde däremellan (som du kanske inte ens vill ha längre), och det ger dig en fungerande app att vakna upp till.

En bra regel: om det trasiga är något användare gör varje dag (registrering, inloggning, betalning), rulla tillbaka först och fixa framåt senare. Fungerande-men-inaktuell slår trasig-och-aktuell varje gång.

Om det trasiga är en funktion du lade till idag som ingen är beroende av än, kan du lämna den trasig till morgonen och fixa den med klart huvud.

Steg 6 – Om du måste låta AI-byggaren fixa det

Om rollback inte är möjligt, eller om du beslutat att inte göra det, då låter du AI-byggaren föreslå en fix. Två saker att hålla i minnet medan den gör det:

Läs vad den planerar att ändra innan du godkänner. Du kommer inte att förstå allt, men du kan se om den redigerar en fokuserad sak eller skriver om halva appen. Små, fokuserade ändringar är mycket säkrare än svepande klockan två på natten.

Testa fixen på det tråkigast möjliga sättet. Fråga inte bara “är det fixat?” och lita på svaret. Gå faktiskt till appen själv i ett inkognitofönster och gör saken som var trasig. Om fixen fungerade fungerar den trasiga saken nu. Om den inte gör det, acceptera inte ändringen bara för att AI-byggaren sa att den fungerade.

Steg 7 – Skriv tillbaka till användaren, även om du inte fixade det

Användaren som messade dig klockan 01:47 förväntar sig inte att du ska vara online. Men om du är det betyder ett kort svar mer än en fix skulle:

“Tack för att du sa till – jag tittar på det just nu. Jag skickar en rad så fort det fungerar igen.”

Om de är en betalande användare är det enda meddelandet skillnaden mellan att de berättar för folk att du svarar snabbt och att de berättar för folk att du ignorerade dem. Fixen kan vänta till morgonen. Svaret kan inte det.

Den större lärdomen: bygg din app som om den kan gå sönder

Om du tyckte det här var stressande är silverkanten att upplevelsen kommer att forma om hur du bygger. Efter din första incident klockan två på natten börjar du göra saker annorlunda:

Du lägger till en statuskontroll. En enkel sida som berättar om de viktiga delarna av din app fungerar, så du inte behöver logga in för att ta reda på det.
Du behåller en säkerhetskopia av användardatan. De flesta AI-byggare exporterar din data på begäran. Att göra det en gång i veckan tar 30 sekunder och räddar dig i värsta fall.
Du skriver ner vad din app beror på. En kort lista över varje anslutet verktyg (betalningar, e-post, databas, lagring), så att du har en checklista i stället för gissningar när något går sönder klockan två på natten.
Du ändrar en sak i taget. När du gör 10 ändringar på en gång och appen går sönder har du ingen aning om vilken ändring som gjorde det. När du gör en ändring i taget har du det.

Du kan bygga en app utan att koda. Du kan också hålla en igång utan att vara utvecklare – men färdigheterna det kräver är annorlunda än byggfärdigheterna. Du lär dig dem mest den hårda vägen, oftast vid en obekväm tidpunkt.

Den goda nyheten: varje gång det händer blir det mindre skrämmande. Tredje gången är det irriterande i stället för skrämmande. Tionde gången är det bara tisdag.