BYGG EN PRODUKT
Inte en övning — en riktig produkt
De föregående guiderna har byggt upp förståelse: hur webben fungerar, hur man läser kod, hur system hänger ihop. Nu sätter vi ihop allt.
Den här guiden är en walkthrough. Vi bygger en fullständig produkt från idé till live — med databas, formulär, AI-funktion och auto-deploy. Inte som ett övningsprojekt, utan som ett riktigt projekt med de beslut, problem och kompromisser som hör till.
Produkten vi bygger: Feedbackverktyg — en sida där besökare kan lämna feedback på vad som helst, och en enkel adminvy där du ser alla svar. Enkelt nog att bygga på en dag. Komplext nog att använda alla koncept från del 1–5.
Rita upp systemet innan du skriver en prompt
Det vanligaste misstaget på den här nivån är att hoppa direkt till att prompta. Resultatet är ett projekt som växer oklart — varje ny funktion läggs till utan att passa in i helheten.
Fem minuters planering sparar timmar. Svara på fyra frågor innan du öppnar Claude:
- Vad gör det? En mening. Inte mer.
- Vem använder det och hur? Beskriv flödet ur användarens perspektiv.
- Vad sparas, var och hur länge? All data som hanteras.
- Vad är minsta möjliga version som är användbar?
För feedbackverktyget:
Den sista frågan är den viktigaste. Allt utanför MVP:n är version 2. Bygg inte version 2 förrän version 1 fungerar.
PLANERASätt upp databasen innan du bygger gränssnittet
Det här är en ordningsfråga som gör stor skillnad. Om du bygger formuläret först och databasen sen tvingas du gå tillbaka och ändra kod som redan fungerar. Börja med datalagret — bestäm vad som ska sparas och hur.
- Skapa ett gratis konto på supabase.com
- Skapa ett nytt projekt — välj ett namn och en region nära dig
- Gå till Table Editor → New Table
- Skapa tabellen feedback med kolumnerna:
Hämta sedan två värden från Project Settings → API: Project URL och anon public key. Spara dem — du behöver dem i koden.
Nu vet du exakt vad databasen ser ut. Prompten du skriver härnäst kan vara precis.
Bygg formuläret — en fil, ett ansvar
Nu är du redo att prompta. Var specifik om exakt vad formuläret ska göra, hur det ska validera, vad som händer vid framgång och fel, och hur det kopplar till Supabase.
Notera hur prompten specificerar exakt vad som händer i varje steg — framgång, validering, fel. Det är inte överkurs. Det är skillnaden mellan kod som fungerar och kod som ser ut att fungera.
FORMULÄRTesta alla scenarion — inte bara det lyckliga
De flesta testar bara det som ska fungera: fylla i formuläret korrekt och klicka skicka. Det är för lite.
Testa alltid tre kategorier:
Det lyckliga scenariot. Fyll i allt korrekt. Kontrollera att Supabase faktiskt fick posten — öppna Table Editor i Supabase och se att raden finns. Det är den enda bekräftelsen som räknas.
Felscenarierna. Skicka tomt formulär. Skriv in ogiltig e-post. Skriv ett meddelande kortare än 10 tecken. Ser du rätt felmeddelanden på rätt ställen?
Edge cases. Vad händer om du trycker skicka två gånger snabbt? Vad händer om du klipper och klistrar in konstiga tecken? Vad händer om du stänger webbläsaren mitt i ett Supabase-anrop?
Hittade du något som inte fungerar — det är bra. Det är nu, inte när riktiga användare hittar det.
TESTABygg adminvyn — en separat fil
Adminvyn är en separat sida. Den hämtar alla poster från Supabase och visar dem i en tabell. Den ska inte vara länkad från formulärsidan — du navigerar till den direkt via URL.
Testa att adminvyn faktiskt visar de poster du skickade i steg 4. Om den är tom — öppna konsolen. Troligen ett Supabase-anropsfel eller en felstavad tabellnamn.
ADMINVYLägg till AI-analys av feedbacken
Nu lägger vi till ett lager som faktiskt visar varför det här är intressantare än ett vanligt formulär: en knapp i adminvyn som skickar all feedback till Claude API och ber om en sammanfattning.
Här tillkommer API-nyckelproblemet från del 3. Lösningen: ett inputfält i adminvyn där du klistrar in din Anthropic API-nyckel. Den lagras bara i sessionens minne — lämnar aldrig webbläsaren.
AI-ANALYSPublicera — med auto-deploy från start
Nu publicerar vi — men inte med drag-och-släpp. Vi sätter upp auto-deploy från start så att varje förbättring du gör publiceras automatiskt.
- Skapa ett repository på github.com och kalla det feedback-tool.
- Koppla din lokala projektmapp till repositoryt. Kör i terminalen:
- Gå till netlify.com → Add new site → Import an existing project → GitHub. Välj repositoryt. Klicka Deploy.
Nu är sidan live. Och nästa gång du ändrar något i koden:
Netlify märker pushen och publicerar om automatiskt inom en minut. Det är hela deploy-flödet.
LIVESkydda adminvyn — enkel lösenordsskydd
Just nu kan vem som helst som känner till URL:en öppna admin.html och se all feedback. Det är inte bra.
Riktig autentisering kräver en backend — det är utanför scope här. Men ett enkelt klientside-lösenord är bättre än ingenting och håller borta slumpmässiga besökare.
Notera att prompten är ärlig om begränsningarna. Det är bra praxis — att förstå vad en lösning skyddar mot och vad den inte skyddar mot.
Version 2 — lägg till en sak i taget
Nu har du en fungerande produkt. Det är steget de flesta aldrig når. Nu kan du iterera — men med disciplin.
Gör en lista över allt du vill lägga till. Rangordna den efter värde: vad ger mest nytta för minst arbete? Börja alltid längst upp.
Möjliga version 2-funktioner, rangordnade:
- Visa datum och tid formaterat (2 apr 2025, 14:32) — enkelt, förbättrar läsbarheten
- Sökfält i adminvyn som filtrerar i realtid — måttligt, sparar tid vid många svar
- Exportknapp som laddar ner alla svar som CSV — enkelt, praktiskt nytta
- E-postnotifikation när ny feedback kommer in — kräver en extern tjänst (Resend eller Formspree)
- Möjlighet att markera svar som hanterade — mer kod, men ger bättre workflow
Bygg en i taget. Testa. Commita. Pusha. Se det live. Gå till nästa.
ITERERATre nivåer av fel — och hur du angriper varje nivå
I ett projekt med formulär, databas och AI-API finns det tre separata ställen där saker kan gå fel. Det är viktigt att veta vilken nivå felet är på innan du börjar felsöka.
Nivå 1: Frontend-fel. Sidan laddas inte, CSS saknas, en funktion anropas aldrig. Konsolen visar röda felmeddelanden. Felet är i din HTML/CSS/JS-fil.
Nivå 2: API-fel. Frontend fungerar men anropet misslyckas. Nätverksfliken i konsolen visar ett anrop med status 400, 401 eller 500. 400 — felaktigt formaterad förfrågan. 401 — fel API-nyckel. 500 — fel på tjänstens server (inte ditt fel).
Nivå 3: Databasfel. Anropet lyckas men data sparas eller hämtas fel. Kontrollera i Supabase Table Editor — finns datan? Är kolumnnamnen i koden identiska med kolumnnamnen i databasen?
FELSÖKVad det här projektet faktiskt lärde dig
Det ser ut som ett enkelt feedbackformulär. Det är inte det. Det är ett system med sex separata lager:
Du har nu jobbat med alla sex lagren i ett sammanhängande projekt. Du vet hur de pratar med varandra, var felen uppstår och hur du felsöker på rätt nivå.
Det viktigaste du lärt dig är inte feedbackverktyget — det är mönstret. Samma sex lager gäller för nästan alla webbaserade produkter du bygger härnäst. Projekten växlar, arkitekturen är densamma.
SYSTEM ACTIVEVad du gör härnäst med det du kan
Du kan nu bygga ett brett spektrum av reella produkter. Här är projekt på din nivå med samma arkitektur men olika komplexitetsgrad:
- Väntelista. Enklare än feedbackverktyget. Bara e-post och ett bekräftelsemeddelande. Perfekt för att testa en idé utan att bygga produkten.
- Länkbibliotek. Spara och kategorisera länkar med titlar och anteckningar. localStorage eller Supabase beroende på om det är privat eller delat.
- AI-textverktyg. Mejlomskrivare, sammanfattare, tonväxlare. Samma mönster som AI-analysen i det här projektet, men som huvudfunktion.
- Enkel CMS. En adminvy där du skriver innehåll som sparas i Supabase och en publik sida som visar det. Blogg, portfolio, produktsida — allt fungerar med samma grund.
Välj ett projekt du faktiskt vill använda. Bygg det med samma metodik: planera systemet, bygg databasen, bygg gränssnittet, testa alla scenarion, publicera.