Det började med en irritation. Substack Notes – deras variant av kortformat, typ Twitter – har ingen schemaläggning. Du skriver, du postar, det publiceras direkt. Vill du vara konsekvent med Notes behöver du sitta vid datorn varje gång.
Jag kör det mesta av mitt innehållssystem från WordPress. Att också kunna schemalägga Notes där kändes lockande.
Så jag byggde en plugin som löser det.
Vad tillägget gör
Det är enklare än det låter. En egen posttyp i WordPress för Notes – korta texter med datum och tid. När klockan slår publicerar pluginet automatiskt till Substack.
Det kluriga var att Substack inte har något publikt API. Inget officiellt sätt att automatisera Notes överhuvudtaget. Pluginet fick reverse-engineera deras interna API-endpoints, autentisera via sessions-cookies och översätta WordPress-innehåll till Substacks egna dokumentformat. Allt i ren PHP, inga externa beroenden.
Jag la till ett par saker som gör det praktiskt att faktiskt använda: krypterad lagring av inloggningsuppgifter, en dashboard-widget som visar vad som är köat och vad som publicerats, och en självläkande cron-mekanism som ser till att Notes verkligen går ut även på sajter med lite trafik. Om sessionen mot Substack löper ut pausar sig systemet själv och skickar ett mejl istället för att misslyckas tyst.
Hur det byggdes – och varför det är intressant
Hela pluginet byggdes i en enda Claude Code-session. Inte genom en prompt som spottade ur sig ett färdigt plugin, utan genom en iterativ process. Bygga, testa på en lokal WordPress-installation, stöta på ett problem, beskriva vad som hände, få en fix, testa igen.
Sex riktiga buggar dök upp under vägen. WordPress saniterings-funktioner som tyst förstörde Substacks sessions-cookie. Ett API-endpoint som inte existerade – Claude Code fick gå och läsa källkoden till ett npm-bibliotek på GitHub för att hitta rätt anrop. En hook-prioritetskonflikt som gjorde att posttypen aldrig registrerades. Tidszonproblem. WP Cron som inte triggas utan trafik.
Varje bugg var verklig, inte hypotetisk. Och det var i felsökningen – inte i kodgenereringen – som samarbetet med AI:n faktiskt testades.
Det här är mönstret jag ser mer och mer i mitt arbete med Claude Code: AI:n är snabb på att generera struktur och refaktorera. Men de svåra problemen kräver kontext som bara finns på min skärm. Jag behöver beskriva vad jag ser. AI:n behöver resonera om orsaker den inte kan observera direkt.
Kopplingen till Freymwork
Jag skrev en fullständig artikel om tillägget på Freymwork – den tekniska processen, alla sex buggar, och vad det säger om att bygga verktyg med AI. Den texten riktar sig till en engelskspråkig publik som bygger liknande saker.
Det här inlägget handlar mer om processen bakom. Om att gå från ”det här irriterar mig” till ett fungerande verktyg på en session. Och om hur gränsen mellan att använda AI och att bygga med AI börjar bli allt suddigare.
Pluginet är inget jag lägger upp på WordPress-pluginkatalogen – det bygger på Substacks interna API som kan ändras utan förvarning. Men som personligt verktyg gör det exakt vad jag behöver. Mina Notes schemaläggs från samma ställe som allt annat innehåll.
Ibland är det bästa sättet att förstå ett verktyg att bygga något med det som löser ett verkligt problem. Inte en demo. Inte en tutorial. Utan något du faktiskt tänker använda imorgon.