Läs koden, inte bara gränssnittet
En app som ser färdig ut kan dölja mycket. Börja med att läsa vad som har byggts: vilket ramverk, vilken databas, vilka externa tjänster den anropar och vilka paket den är beroende av. Leta efter kod som genererats, övergetts och blivit kvar, logik som finns på flera ställen och funktioner som bara fungerar med testdatan. Kontrollera att projektet går att bygga från en ren kopia med dokumenterade steg, så att det inte hänger på en persons dator eller på ett verktygs editor. Den läsningen är också där hjälp med AI-byggda projekt börjar.
Säkerhetsregler i databasen och row-level security
Appar byggda i Lovable och liknande verktyg pratar ofta med databasen direkt från webbläsaren, oftast via Supabase. Det är säkert bara om databasen själv avgör vem som får läsa och skriva varje rad, genom row-level security i PostgreSQL. Kontrollera att den är påslagen för varje tabell och att reglerna säger det ni menar, till exempel att användare bara ser sina egna ordrar och att ingen kan ändra sin egen roll. Testa genom att logga in som en vanlig användare och försöka nå någon annans data. En tabell där row-level security är avstängd är öppen för alla som har appens publika nyckel, och den nyckeln ligger i webbläsaren för alla att se.
Hemligheter och API-nycklar
Sök igenom koden och historiken i repot efter API-nycklar, lösenord och tokens. Den publika nyckel som en Supabase-app använder i webbläsaren är avsedd att vara publik, men service role-nyckeln, betalleverantörens hemligheter och nycklar till AI-leverantörer får bara finnas på servern, i miljövariabler eller i plattformens lagring för hemligheter. Anrop till AI-modeller och betaltjänster ska gå via en serverfunktion, aldrig direkt från webbläsaren. Nycklar som någon gång har committats ska bytas, eftersom historiken behåller dem.
Inloggning med riktiga användare
Inloggningen brukar fungera för den som byggt appen och falla isär i kanterna. Gå igenom hela flödena med riktiga e-postadresser: registrering, bekräftelse, glömt lösenord, byte av e-postadress, inloggning med Google eller en annan leverantör och vad som händer när en session går ut. Kontrollera att e-posten skickas från er egen domän med SPF, DKIM och DMARC på plats, så att bekräftelselänkarna inte hamnar i skräpposten. Bestäm hur konton tas bort och vad som händer med deras data, en fråga som GDPR kräver att ni kan svara på.
Hastighet och bilder
Prototyper brukar ladda allt på en gång: stora bilder direkt från uppladdningen, alla bibliotek på första sidan och data som hämtas i flera omgångar innan något syns. Mät på en mellanklasstelefon över mobilnätet, inte på utvecklarens dator. Visa bilder i moderna format som AVIF eller WebP och i de storlekar de visas i, dela upp koden så att varje sida laddar det den behöver och hämta data med så få anrop som möjligt. Googles Core Web Vitals, LCP, INP och CLS, ger mål att sikta mot och syns i Search Console när trafiken är tillräcklig.
SEO på sajter byggda som single page-appar
Många AI-verktyg bygger en single page-app, där webbläsaren får en nästan tom sida och JavaScript ritar upp innehållet. Google kan rendera JavaScript, men det tar längre tid, och många andra sökrobotar, AI-söktjänster och länkförhandsvisningar i sociala medier och chattappar läser bara den första HTML-koden. Varje sida som ska hittas behöver en egen adress, titel, beskrivning och canonical-tagg i den HTML-koden, vilket i praktiken betyder serverrendering eller förrendering. En sitemap, vettiga interna länkar och riktig text på sidorna gör resten.
Egen hosting, eget repo och underhåll
Koden ska ligga i ett repo som företaget äger, med åtkomst för fler än en person, och appen ska köras på hosting i företagets egna konton, med domän, databas och säkerhetskopior i eget namn. Då kan projektet flyttas till ett annat verktyg, en annan utvecklare eller en annan leverantör utan att någon behöver ge lov. Efter lanseringen kommer uppdateringar av beroenden, säkerhetsrättningar, bevakning av fel och en provad återställning från säkerhetskopia. En genomgång av webb, IT och AI kan fastställa var ett projekt står innan ni bestämmer vem som tar det vidare.