BYGG SYSTEM

MANUAL DEL 3 // FRÅN SIDOR TILL SYSTEM

DU ÄR HÄR NU

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.

NIVÅ 1: FÅ NÅGOT ATT FUNKA ✓
NIVÅ 2: BYGGA SAKER SOM ANVÄNDS ✓
NIVÅ 3: BYGGA SYSTEM SOM FUNGERAR ←

API

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.

DIN SIDA → FÖRFRÅGAN → EXTERN TJÄNST
EXTERN TJÄNST → SVAR → DIN SIDA VISAR DET

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.

DITT FÖRSTA API-ANROP

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:

  1. Ett API-konto. Skapa ett konto på platform.openai.com eller console.anthropic.com. Båda har gratisnivåer för testning.
  2. 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.
  3. En prompt till Claude som kopplar ihop allt.

"Jag har ett textfält och en knapp på min sida.
När användaren klickar ska texten skickas till
Anthropic Claude API (claude-haiku-4-5-20251001).
Svaret ska visas i ett outputfält under.
API-nyckeln ska läsas från ett inputfält högst upp.
Visa ett laddningsmeddelande medan vi väntar.
Hantera fel — visa ett tydligt felmeddelande om det misslyckas.
Här är min nuvarande kod: [klistra in]"

API

SÄKERHET

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.

ALDRIG: API-NYCKEL I KODEN
ALDRIG: API-NYCKEL I EN FIL DU PUBLICERAR
OK: ANVÄNDAREN KLISTRAR IN SIN EGEN NYCKEL
OK: NYCKEL I EN BACKEND SOM INTE ÄR PUBLIK

VARNING

FORMULÄR PÅ RIKTIGT

Frå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.

  1. Skapa ett gratis konto på formspree.io
  2. Skapa ett nytt formulär — du får en unik URL
  3. Be Claude ersätta din localStorage-logik med ett Formspree-anrop

"Byt ut localStorage mot Formspree.
Min endpoint: https://formspree.io/f/[din-kod]
Skicka name, email och message som JSON.
Visa bekräftelsetext vid lyckad skickning.
Visa feltext om det misslyckas.
Här är min kod: [klistra in]"

Nu hamnar alla inskickningar i din Formspree-dashboard och skickas som e-post till dig. Ingen backend, ingen server.

INTEGRATION

PERSISTENT DATA

Data 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.

"Jag vill spara formulärdata i Supabase.
Tabellnamn: submissions
Kolumner: name, email, message, created_at
Min Supabase URL: [din URL]
Min anon key: [din nyckel]
Bygg koden som sparar ett nytt svar när formuläret skickas.
Visa också en lista med alla sparade svar under formuläret."

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.

DATABAS

DEPLOYMENT

Frå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:

  1. Skapa ett gratis konto på github.com och ett nytt repository för ditt projekt.
  2. Koppla din lokala projektmapp till repositoryt — be Claude förklara exakt vilka kommandon du kör i terminalen.
  3. 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.

GIT PUSH → GITHUB → NETLIFY MÄRKER → AUTO-PUBLISH
ÄNDRING LIVE PÅ UNDER EN MINUT

AUTO-DEPLOY

DOMÄN

Byt 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.

NETLIFY URL → FUNKAR
EGET DOMÄNNAMN → SER UT SOM EN PRODUKT

KOMPLEXITET

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:

"Här är min kod. Rita upp hur de olika delarna
hänger ihop — vad pratar med vad, i vilken ordning,
och var data kan tappa bort sig."

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ÄNK

FELSÖKNING

Konsolen — 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.

NÅGOT FUNGERAR INTE →
F12 → CONSOLE → KOPIERA FELMEDDELANDET
KLISTRA IN I CLAUDE MED KODEN → FÅ SVAR

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ÖK

AVANCERADE PROMPTS

Be 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:

"Förklara vad den här koden gör — en mening per funktion"

"Vad händer om det här API-anropet misslyckas?
Hur märker användaren det?"

"Vilka delar av det här kan gå sönder när fler
användare använder det samtidigt?"

"Finns det ett enklare sätt att göra det här
som är lättare att underhålla?"

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.

GIT NÄSTA STEG

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.

git checkout -b ny-funktion  → SKAPA OCH BYTA TILL NY BRANCH
git checkout main         → GÅ TILLBAKA TILL HUVUDVERSIONEN
git merge ny-funktion     → SAMMANFOGA OM DET FUNKADE

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.

GIT

TAKET

Vad 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.

VIBE CODING: BRA PÅ ATT BYGGA SNABBT
UNDERLIGGANDE KONCEPT: BRA PÅ ATT ÄGA DET DU BYGGT
KOMBINATIONEN: DET STARKASTE MÖJLIGA

NÄSTA STEG

SAMMANFATTNING

Vad du tar med dig

1. API = DIN SIDA PRATAR MED EXTERNA TJÄNSTER
2. PUBLICERA ALDRIG DIN API-NYCKEL I KODEN
3. FORMSPREE → FORMULÄR SOM FAKTISKT SKICKAR
4. SUPABASE → DATA SOM SPARAS FÖR ALLA
5. GITHUB + NETLIFY → AUTO-DEPLOY VID PUSH
6. EGET DOMÄNNAMN → SER UT SOM EN PRODUKT
7. F12 → CONSOLE → KOPIERA FEL → KLISTRA I CLAUDE
8. BE OM FÖRKLARINGAR, INTE BARA KOD
9. BRANCHER → EXPERIMENTERA UTAN ATT RISKERA

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

NÄSTA: FÖRSTÅ KOD

VIBE CODING HAR ETT TAK // DET HÄR ÄR VÄGEN BORTOM DET