BYGG SYSTEM
Du kan bygga sidor. Nu bygger du system.
Del ett lärde dig grundflödet — be om kod, klistra in, se resultatet. Del två lärde dig att bygga saker som faktiskt används — bättre prompts, flera filer, versionshantering.
Det här är steget där saker börjar hänga ihop på riktigt. Du kopplar din sida till externa tjänster. Du bygger saker som fungerar för fler än dig. Du hanterar data som faktiskt sparas, skickas och används.
Det kräver inte att du förstår mer kod. Det kräver att du förstår mer om systemet runt koden — vad som pratar med vad, var data tar vägen, och vad som kan gå fel när fler saker är inblandade.
Vad är ett API — och varför behöver du veta det?
Ett API är ett sätt för din kod att prata med en annan tjänst. När du klickar "skicka" i ett formulär och datan hamnar i ett Google Sheet — det sker via ett API. När din sida visar aktuellt väder — det hämtas via ett API. När Claude svarar på din prompt — det sker via ett API.
Du behöver inte förstå tekniken bakom. Du behöver förstå konceptet: din sida skickar en förfrågan till en extern tjänst, tjänsten svarar med data, din sida visar svaret.
Det öppnar upp allt: AI-funktioner, väderdata, betalningar, e-post, kartor, valutakurser, nyheter. Allt finns som API. Och Claude kan skriva koden som kopplar ihop det åt dig.
Bygg ett AI-verktyg med riktig AI bakom
I del ett byggde du kanske ett AI-gränssnitt med platshållartext. Nu kopplar du in riktigt. Det kräver tre saker:
- Ett API-konto. Skapa ett konto på platform.openai.com eller console.anthropic.com. Båda har gratisnivåer för testning.
- En API-nyckel. En lång textsträng som identifierar dig. Den hittar du i ditt konto under "API Keys". Kopiera den och spara den säkert — behandla den som ett lösenord.
- En prompt till Claude som kopplar ihop allt.
Publicera aldrig din API-nyckel
Det här är det vanligaste och dyraste misstaget för vibe-coders som börjar jobba med API:er. En API-nyckel i din kod — och du publicerar sidan på Netlify — betyder att vem som helst kan hitta nyckeln, använda den och debitera ditt konto.
Det finns ett enkelt mönster som löser det: låt användaren klistra in sin egen API-nyckel i ett fält på sidan. Nyckeln sparas bara i webbläsarens minne under sessionen och skickas aldrig till någon server.
Det är inte lika smidigt som att hårdkoda nyckeln — men det är det enda säkra sättet för statiska sidor utan en backend.
VARNINGFrån localStorage till något som faktiskt skickas
I del två lärde du dig att spara data i localStorage — webbläsarens inbyggda minne. Det fungerar bra för personliga verktyg. Men om du vill samla in data från andra, behöver du något som faktiskt skickar datan någonstans.
Det enklaste sättet utan att bygga en backend: Formspree.
- Skapa ett gratis konto på formspree.io
- Skapa ett nytt formulär — du får en unik URL
- Be Claude ersätta din localStorage-logik med ett Formspree-anrop
Nu hamnar alla inskickningar i din Formspree-dashboard och skickas som e-post till dig. Ingen backend, ingen server.
INTEGRATIONData som finns kvar — för alla, alltid
localStorage sparar data i din webbläsare på din dator. Öppnar du sidan på en annan dator är datan borta. Det duger för personliga verktyg — men inte för produkter med användare.
För att spara data som finns kvar och är tillgänglig för alla behöver du en databas. Det låter mer avancerat än det är.
Det enklaste alternativet just nu: Supabase. Det är en databas i molnet med ett gratis plan. Du skapar ett konto, skapar en tabell och Claude skriver koden som sparar och hämtar data därifrån.
Supabase anon key är publik av design — den är säker att ha i frontend-kod. Det är inte samma sak som en API-nyckel du håller hemlig.
DATABASFrån drag-och-släpp till auto-deploy
I del ett publicerade du genom att dra och släppa en mapp på Netlify. Det fungerar — men varje gång du gör en ändring måste du göra om det manuellt.
Det finns ett bättre sätt: koppla Netlify direkt till ett GitHub-repository. Varje gång du pushar kod till GitHub publiceras sidan automatiskt.
Tre steg att sätta upp det:
- Skapa ett gratis konto på github.com och ett nytt repository för ditt projekt.
- Koppla din lokala projektmapp till repositoryt — be Claude förklara exakt vilka kommandon du kör i terminalen.
- I Netlify: välj "Import from Git" istället för drag-och-släpp, välj ditt repository. Klart.
Nu räcker det med git push för att uppdatera den publicerade sidan. Netlify märker ändringen och publicerar om på sekunder.
AUTO-DEPLOYByt ut netlify.app mot ditt eget namn
Netlify ger dig en slumpmässig länk som sparkling-fox-a1b2c3.netlify.app. Det fungerar — men det ser inte ut som en riktig produkt.
Ett eget domännamn kostar ungefär 100–150 kronor per år och förändrar hur folk uppfattar vad du byggt. mittverktyg.se är en produkt. En netlify-URL är ett test.
Köp ett domännamn via namecheap.com, one.com eller valfri registrar. Koppla det till Netlify via deras DNS-inställningar — det finns en steg-för-steg-guide direkt i Netlify-dashboarden.
Be Claude förklara exakt hur du sätter upp DNS-posterna om något är oklart. Det är ett av de få ställen där det faktiskt kan ta upp till 24 timmar innan det slår igenom.
När projektet har för många delar
På den här nivån börjar projekten ha fler rörliga delar: ett formulär som pratar med Formspree, en AI-funktion som pratar med Claude API, data som sparas i Supabase, allt publicerat via Netlify. Det är fyra externa tjänster i ett enda projekt.
När något går fel vet du inte var felet är. Är det formuläret? API-nyckeln? Supabase-anslutningen? Netlify-builden?
Lösningen är att testa en sak i taget — och att ha en mental karta över vad som pratar med vad.
Be Claude rita upp systemet:
Det ger dig en karta att använda när något går fel. Du kan peka på en del av systemet och fråga: "Om det här steget misslyckas — hur märker jag det?"
SYSTEMTÄNKKonsolen — ditt viktigaste verktyg
Du har troligen sett webbläsarens konsol nämnas men aldrig öppnat den. Det är dags nu.
Öppna konsolen med F12 (Windows) eller Cmd+Option+I (Mac), välj fliken "Console". Här visas felmeddelanden, varningar och information som din kod skickar.
När något inte fungerar — öppna alltid konsolen först. Felmeddelandet där är nästan alltid mer informativt än "det funkar inte". Kopiera det och klistra in i Claude.
Lär dig också att använda nätverksfliken (Network). Den visar varje förfrågan din sida skickar och om den lyckades. Om ett API-anrop misslyckas ser du exakt vilket och varför.
FELSÖKBe om förklaringar, inte bara kod
På den här nivån förändras hur du använder Claude. Du ber fortfarande om kod — men du börjar också be om förklaringar av varför något är byggt på ett visst sätt.
Det är inte för att du måste förstå koden. Det är för att du ska kunna fatta bättre beslut om vad du ber om härnäst.
Prompts som ger mer än kod:
De frågorna ger dig en förståelse för systemet som gör att du kan debugga, förbättra och förklara vad du byggt — även utan att läsa koden rad för rad.
Brancher — experimentera utan att riskera det som fungerar
I del två lärde du dig att committa och pusha. Nu introducerar vi brancher — det enda Git-konceptet utöver grunderna du faktiskt behöver på den här nivån.
En branch är en parallell version av ditt projekt. Du kan experimentera, lägga till en ny funktion eller testa en idé — utan att röra huvudversionen som fungerar. Om experimentet lyckas sammanfogar du det. Om det misslyckas kastar du branchen och är tillbaka där du startade.
Vet du inte när du ska använda det? Enkel regel: varje gång du ska lägga till något som kan gå sönder — gör det på en branch.
GITVad vibe coding inte löser — och vad som finns bortom det
Du kan nu bygga saker som:
- Tar emot input från användare och sparar det permanent
- Pratar med AI och externa API:er
- Publiceras automatiskt när du pushar kod
- Lever på ett eget domännamn
Det är mer än de flesta vibe-coders någonsin bygger. Men det har ett tak.
Taket är ägande. Du kan få saker att fungera — men om något komplext går sönder på ett oväntat sätt, om du behöver optimera för många användare, om säkerhet är kritisk — då är du beroende av att AI förstår problemet korrekt. Och det gör den inte alltid.
Det som finns bortom taket är inte svårare att lära sig än det du redan gjort. Det är bara ett annat slags förståelse: vad koden faktiskt gör, inte bara vad den producerar.
NÄSTA STEGVad du tar med dig
Du är nu en vibe-coder som kan bygga produkter på riktigt. Nästa steg är att börja förstå vad som händer under ytan — inte för att sluta använda AI, utan för att använda den bättre.
LOOP ACTIVE