Från Lovable till Claude Code: när artiklarna blev Markdown

Vår egen sajt låg på Lovable. Den såg ut som vi ville, vi var nöjda med design och innehåll. Men det skavde varje gång vi skulle göra en ändring eller skriva en artikel. Att lämna editorn för ett separat webbgränssnitt bröt flödet. Att ha en backend att underhålla för något så enkelt som ett kontaktformulär kändes överflödigt. Vi ville hellre jobba Claude Code-först, med artiklarna som Markdown direkt i repot. Inte för att Lovable är dåligt, utan för att vi ville kunna ändra vad som helst, när som helst, utan att lämna verktyget vi redan jobbar i.

Så vi flyttade hem den. Astro 6, React-öar där vi behöver dem, deploy på Vercel, innehåll som Markdown-filer i vårt eget repo. Ingen Supabase, ingen CMS, ingen extra adminyta. Själva migreringen gick snabbt. Det var efteråt det blev intressant. Plötsligt blev både publicering och prestanda saker vi kunde lösa direkt i editorn.

Vi ville äga flödet

På Lovable låg innehåll, kod och hosting i samma låda. Det är bekvämt tills man vill göra något specifikt: ändra ett SEO-element, byta deploy-target, lägga till ett eget byggsteg, redigera en artikel utan att klicka sig in i ett UI. Vi ville ha tre saker:

Ett Claude Code-först-flöde, där vi skriver i Markdown och låter specialiserade agenter sköta det redaktionella putset.
Artiklar som filer, så att skriva ett inlägg är samma flöde som att skriva vilken commit som helst.
Hosting utan eget tankearbete: bara git push och så är det live.

Astro + Vercel + GitHub löser exakt det. Lovable löste något annat, för andra användare. Inget fel med det. Vi växte ur det.

Push till main = live på uxare.design

Hostingen är det enklaste vi någonsin haft. Vercel är kopplad till vårt GitHub-repo. Pushar vi till main så bygger Vercel sajten och deployar till produktion. Pushar vi till en feature-branch får vi en preview-URL automatiskt. Det är allt.

Hela vår release-process är git push. Inget admin-UI att logga in i, ingen “publicera”-knapp, ingen separat staging. PR-review är vår enda rutin. Vi jobbar aldrig direkt mot main, utan öppnar en PR, granskar förhandsdeployen och mergar när det ser bra ut.

Den serverlösa funktionen vi ändå behöver, kontaktformuläret som skickar via Resend, ligger som en enskild route i src/pages/api/contact.ts. Resten av sajten är statiskt prerenderad. Två deploy-mål som blir ett.

Artiklarna är bara filer

Att skriva artiklar blev enklare. Markdown-filer i src/content/articles/{sv,en}/ istället för formulärfält i ett UI. Schemat är definierat i src/content.config.ts: title, excerpt, datum, kategori, språk. Att skriva en ny artikel är att skapa en ny fil. Att publicera är att sätta published: true och pusha.

Det finns ingen backend. Ingen Supabase med en articles-tabell. Ingen CMS-instans att uppgradera. Inga RLS-regler att felsöka. Innehåll och kod är samma sak, versionerade i samma git-historik, redigerade i samma editor.

För oss betyder det också att vi kan be Claude Code om hjälp med en artikel på samma sätt som med en bugg. “Skriv om den här delen tightare.” “Lägg till ett <Callout> här.” “Översätt till engelska och lägg i en/.” Samma verktyg, samma flöde, samma repo.

Formatet låter oss dessutom blanda in komponenter mitt i Markdown-texten. En bildkarusell, en tvåkolumnslayout, en presentation, utan att lämna artikeln. Komponenterna ligger i src/components/mdx/ och är samma byggstenar som resten av sajten använder.

Claude Code blir både redaktör och utvecklare

När innehållet är kod blir gränsen mellan “skriva en artikel” och “förändra sajten” suddig på ett bra sätt. Vi sitter i samma terminal, använder samma verktyg, och Claude Code förstår båda lagren samtidigt.

Konkret: vi skrev den här artikeln själva, och bad Claude Code om hjälp med struktur, skarpare formuleringar och att hålla tonen jämn. När vi insåg att kontaktlänken inte gick rätt fixade vi det i samma session. När vi ville lägga till en ny <Callout>-variant gjorde vi det utan att byta verktyg. Det är ingen designad workflow, det är en bieffekt av att allt är textfiler i ett repo.

Simona: en agent som lär sig hur vi skriver

Vi skriver själva det vi vill säga. Simona ser till att det kommer fram tydligt och i rätt ton.

Innan den här artikeln gick live hade hon läst igenom den och städat upp språket.

Simona är en agent i Claude Code, alltså en specialiserad version av Claude med ett tydligt jobb och en egen kontext. Vi gav henne en roll: läs vår copy, putsa den, behåll tonen, plocka bort tankstreck där de blivit för många. Hon är ingen separat tjänst eller modell. Hon är en Markdown-fil med instruktioner som ligger i .claude/agents/simona-ux-copy.md. Vi anropar henne med ett kommando, hon läser uppdraget, gör jobbet och rapporterar tillbaka.

Förenklat: en agent är ett uppdrag för Claude med fördefinierad expertis. Istället för att börja från noll varje gång med “vår ton är direkt, undvik tankstreck, läs CLAUDE.md” säger vi bara “kör Simona på den här artikeln”. Hon kommer in med all kontext redan på plats.

Skärmdump från Claude Code där ett uppdrag skickas till Simona, körs i bakgrunden i 34 sekunder, och rapporten kommer tillbaka med två förslag på ändringar. — En agent är ett uppdrag, inte ett verktyg du övervakar. Simona jobbar i bakgrunden och rapporterar tillbaka vad hon ändrade och varför.

Den andra delen är det som gör det riktigt bra: agenter har minne. Efter sin första körning sparade Simona två filer i .claude/agent-memory/simona-ux-copy/:

voice_uxare_articles.md, observationer om hur uxare-artiklar är skrivna: vi-form, korta meningar, kursiverade exempel-prompter, fet-prefix-listor.
feedback_dash_replacements.md, hennes egna mönster för hur tankstreck oftast ska ersättas (kolon, punkt, omskrivning) utifrån vad vi accepterat och avvisat.

Skärmdump av Simonas minnesfil för tankstreck-ersättningar med en numrerad lista över fem mönster (punkt och ny mening, komma, kolon, parentes, omskrivning), följt av etiketterade avsnitt för "Why" och "How to apply". — Simonas minne är textfiler vi kan öppna, läsa och redigera. Inget vektorbibliotek, ingen black box. Bara en anteckning hon själv skrivit och själv slår upp nästa gång.

Nästa gång vi ber Simona polera en artikel börjar hon inte från noll. Hon läser sina egna anteckningar, jobbar fortare, blir mer konsekvent. Det är ingen avancerad RAG-pipeline, det är textfiler hon skriver själv när hon lär sig något nytt om hur vi vill jobba.

Allt det här ligger i samma git-historik som artiklarna: agentdefinitionen, hennes minne och artikeln hon polerade. Versionerade tillsammans, pushade tillsammans.

Och prestandan? En skill räckte

Första gången vi körde Lighthouse på den nya sajten landade vi på Performance 58. Tillgänglighet 96. Resten 100. Vi hade flyttat in utan att städa.

Istället för att jaga sidor en i taget körde vi Unlighthouse. Den crawlar hela sajten, alla 52 rutter på svenska och engelska, och visar resultatet i en sorterbar dashboard. Mycket lättare att se vilka sidor som drog ner snittet och vad de hade gemensamt.

Sen paketerade vi arbetsflödet som en Claude Code-skill: lighthouse-perf. Den innehåller hela playbooken: hur man bygger sajten, kör mätningarna och vad som typiskt behöver fixas. Skillen är aktiverbar via en prompt och gör att vi inte börjar från noll nästa gång någon vill polera prestandan.

Claude Code-session där användaren skriver /lighthouse-perf. Skillen svarar med en meny av tre alternativ: Verify, Investigate, Improve. Användaren väljer 1, och skillen kör sedan en sekvens av kommandon automatiskt: rensar gammal cache, bygger sajten, startar en lokal server och kör Unlighthouse-mätningen. — Skillen är inte bara en checklista. Den frågar vad vi vill göra och kör rätt kommandon i rätt ordning. Tankearbetet ligger paketerat, inte i någons huvud.

Lighthouse-rapport för en av sajtens sidor. Tillgänglighet, Best Practices och SEO ligger på 100 i gröna ringar, Performance på 84 i orange. I detaljvyn nedanför är mätvärdet Cumulative Layout Shift markerat i rött med värdet 0,325. Övriga mätvärden är gröna. — Rapporten pekar ut vad som ska fixas. Det gröna är klart, det orange och röda är vad skillen sen tar tag i.

Resten var rutinjobb: krympa bilder, ladda in tunga komponenter först när de faktiskt behövs, justera färgkontraster så de uppfyller tillgänglighetskraven, reservera plats för bilder så att layouten inte hoppar när de laddas in. Inget av det är magi. Det är en lista som någon (eller något) behöver beta av. Skillen är vår genväg till att veta vad som ska kollas och i vilken ordning.

Resultatet

Alla 52 sidor på 100/100/100/100 i Lighthouse. Full pott i de fyra områdena Google bedömer en sajt på: hur snabbt den laddar, hur tillgänglig den är, om den följer god praxis, och hur väl den fungerar för sökmotorer. Både på svenska och engelska, oavsett var i sajten man landar.

Unlighthouse-dashboarden efter optimering. TOTAL SCORE 100, och alla sajtens sidor visar fyra gröna ringar med 100 i Performance, Accessibility, Best Practices och SEO. En enskild sida (startsidan) ligger på 99 i Performance, övriga på 100 rakt igenom. — Samma sajt, samma rapportverktyg, en kväll senare. Listan är avbockad och kolumnerna gröna.

I praktiken: sidorna laddar snabbt, besökare som använder skärmläsare eller tangentbord kan röra sig genom sajten utan att fastna, och sökmotorerna får allt de behöver för att indexera den ordentligt.

Men siffrorna är inte huvudpoängen. Huvudpoängen är att vi fick dem på en kväll. Att flytten gjorde det möjligt att jobba med sajten som med vilken kodbas som helst, och att verktygen runt den (Claude Code, Unlighthouse, en skriven skill) plockar upp arbetet där vi släppte det förra gången.

Vad vi tog med oss

Sajten i eget repo är värt det. Inte för principens skull, utan för att artiklar, prestanda och deploy blir samma sorts arbete istället för tre olika.
GitHub fungerar utmärkt som CMS. För en sajt av vår storlek slår filer i ett repo varje admin-UI vi har provat.
Astro låser oss inte. Vi kör React-öar idag, men Astro stödjer också Vue, Svelte, Solid och Preact. Vill vi byta riktning imorgon behöver vi inte starta om.
Vercel push-deploy är osynligt på rätt sätt. Pusha. Det är live. Branch-deploy ger preview. Klart.
Skalat verktyg slår snabba prompts. Det vi sparade som en skill blir det vi inte behöver tänka på nästa gång.
Prestanda är inte en svart konst. Det är en lista. Mät rätt (i produktion, inte dev), börja uppifrån och flytta dig nedåt.

Det viktigaste: om du sitter med en sajt på en plattform du själv vill kunna förändra, flytta hem den. Det är en kväll. Sen kan du bygga vidare på din egen mark, i din egen takt, med dina egna verktyg.

Vill ni effektivisera er digitala utveckling?

Vi hjälper företag att korta vägen från idé till färdigt med användarcentrerade metoder, AI-teknik och snabb prototypframtagning. Vi börjar inte med tekniken. Vi börjar med människan, vad som faktiskt behöver lösas, och vilken affärsnytta ni vill uppnå. Hör av er så pratar vi om var ni skulle börja.