Bygg det som är unikt för din app. Köp det som alla appar behöver. Inloggning och betalning behöver alla appar, de är lösta sedan länge, och en egen variant är sämre än en färdig i praktiskt taget alla avseenden. Data behöver du förstå — inte bygga, men veta var den ligger.
Var data faktiskt hamnar
Det här är det vanligaste missförståndet i vibecoding, och det upptäcks nästan alltid för sent: appen fungerade perfekt, sedan laddade någon om sidan och allt var borta.
Anledningen är att den första versionen av nästan varje app sparar data i webbläsarens minne. Det är enklast, det syns inte som en begränsning när du provar själv, och det försvinner vid omladdning.
I webbläsaren
- Försvinner vid omladdning, eller senast när fliken stängs.
- Finns bara på den enhet där den skrevs in.
- Ingen annan kan se den.
- Går inte att säkerhetskopiera.
- Duger till: en prototyp du ska visa någon i tio minuter.
I en databas
- Finns kvar tills någon raderar den.
- Samma data oavsett vem som tittar och varifrån.
- Går att säkerhetskopiera och exportera.
- Kostar oftast ingenting alls i den storlek det här handlar om.
- Duger till: allt annat.
Frågan att ställa, tidigt och ordagrant: "Var sparas data i den här appen? Finns den kvar om jag laddar om sidan, och finns den kvar om någon annan öppnar appen på sin telefon?"
Så byter du utan att börja om
- Beställ bytet som ett eget steg, inte tillsammans med något annat.
- Be om planen först: vad ändras, och vad händer med det som redan är inmatat?
- Räkna med att det som redan finns i webbläsaren försvinner. Skriv av det du behöver innan.
- Prova genom att fylla i något, ladda om sidan, och sedan öppna appen på telefonen. Alla tre stegen.
Inloggning: bygg den inte
Be en modell om ett inloggningsformulär och du får ett. Det ser rätt ut, det fungerar när du provar, och det är nästan alltid osäkert på ett sätt du inte kan upptäcka genom att titta.
Problemet är inte att modellen är dålig på inloggning. Problemet är att inloggning består av ett dussin detaljer som var och en måste vara rätt — hur lösenord lagras, vad som händer vid glömt lösenord, hur en session hålls vid liv, hur den avslutas, vad som händer efter tio felaktiga försök. Ingen av dem syns i gränssnittet, och du har ingen realistisk möjlighet att kontrollera dem.
- Lösenord som sparas läsbara eller med en metod som inte längre räknas som säker.
- Kontrollen ligger i webbläsaren. Alltså kan den kringgås av vem som helst som vet hur, och det räcker med att någon vet hur.
- Ingen begränsning av antal försök. Ett lösenord går att gissa fram automatiskt.
- Inloggningen skiljer användare men inte deras data. Alla ser allas uppgifter så snart de kommit in.
Alternativet kostar oftast ingenting i den här storleken: en färdig inloggningstjänst som du kopplar in. Beställ den så här: "Använd en etablerad inloggningstjänst i stället för att bygga egen hantering av lösenord. Föreslå två alternativ och vad de kostar för femtio användare."
Ofta räcker något ännu enklare
- Ingen inloggning alls. Om appen bara samlar in något behövs ingen inloggning — bara en adress som är svår att gissa för den sida som visar resultatet.
- En engångslänk via mejl. Inga lösenord att läcka, och användarna glömmer inget.
- Inloggning med ett konto de redan har. Google, Microsoft eller liknande. Du hanterar aldrig något lösenord.
- Ett delat lösenord för en liten grupp. Inte elegant, men om det är fem personer i en styrelse är det ärligare än en halvfärdig kontohantering.
Betalning: rör inte kortuppgifter
Regeln är kort: kortnummer ska aldrig passera kod du inte kan granska. I praktiken betyder det att din app ska skicka besökaren till en betaltjänst och få tillbaka ett svar — aldrig ta emot kortuppgifter själv.
Det här är inte ett råd, det är i praktiken ett krav. Att hantera kortuppgifter själv medför regelkrav som inte går att uppfylla i en app man inte kan läsa.
Vad du ska bygga själv
Listan ovan kan låta som att inget går att göra själv. Tvärtom — allt som är specifikt för din app är precis det vibecoding är bra på, och det är också det enda ingen kan sälja dig färdigt.
Bygg gärna själv
- Formulären och fälten: vad som frågas, i vilken ordning, med vilka ord.
- Reglerna som är dina: vem som får anmäla sig, hur många platser, sista datum.
- Hur informationen visas: listor, summeringar, filter, utskrifter.
- Texterna, tonen och felmeddelandena. Det är här appen känns genomtänkt eller inte.
- Exporten. Att kunna få ut allt som en fil är billigt att lägga till och räddar dig den dag du byter verktyg.
Nästa steg
Data ligger på rätt plats och du bygger inte det du inte ska bygga. Nästa guide handlar om steget som avslöjar allt annat: att låta någon annan använda appen på en riktig adress.