Infrastruktur Del 2: Varje måndag 06:00. 100 % byggt med AI.

Gör du bort dig på webben publicerar du bara om sidan, så är misstaget borta. Ett utskick som går snett går inte att rädda. Skickar du två gånger får hela listan en dubblett i inkorgen. Skickar du till någon som avregistrerat sig bryter du ett löfte, och lagen har synpunkter. Skickar du till halva listan har du sedan inget pålitligt sätt att nå den andra halvan. Och läcker nästa veckas nummer på sajten redan under lördagen, är utskicket förstört innan det ens har skett.

Därför byggde vi motorn baklänges. Vi utgick från det värsta som kunde hända. Allt fram till utskicket måste gå att göra om: importen, bygget, förhandsvisningen, testmejlet, till och med beslutet att skicka. Endast en enda gräns är oåterkallelig: sekunden då Postmark – tjänsten som pratar med världens mejlservrar – accepterar utskicket. Fram till dess kan vi backa bandet. Efter det får ingenting skicka det numret igen.

Att dra den gränsen rätt tog oss sex dagar. Den första versionen stod klar på en dag.

Den 17 juli introducerade vi en SQLite-databas som kärnan i systemet. En enda fil. Den går att läsa från både PHP och Node, den hanterar transaktioner, och den låser sig själv. Databasen ligger utanför mappen som besökarna kommer åt, med rättigheter som bara ägaren har. Båda miljöerna vägrar att starta om filrättigheterna är fel.

Allt som nyhetsbrevet behöver minnas bor där: prenumeranter, bekräftelsenycklar som bara sparas som hashar, räknare som stoppar missbruk, status för utskicken och historiken över varje nummer som någonsin skickats. Här sparas också varje uppdatering Postmark skickar om en adress: en avregistrering, ett klagomål på skräppost, eller en adress som slutat fungera. Allt det där tas emot via en enda säker ingång. Databasens uppdateringar är korta, och ingen skrivning hålls öppen medan vi väntar på nätverket. Databasen låser sig alltså aldrig på grund av en trög uppkoppling.

Designens viktigaste detalj är en maktdelning. SQLite bestämmer över samtycket: vill personen ha mejlet? Postmark bestämmer över leveransen: går det ens att skicka dit? En prenumerant får nyhetsbrevet bara när båda säger ja. Ingen av dem får skriva över den andras beslut. Om en adress slutar fungera permanent (en "hard bounce") stoppar det leveransen, men det ändrar inte på samtycket. En gammal bekräftelselänk kan aldrig upphäva en färsk avregistrering. Varje dygn jämför ett skript de två, städar bort utgångna inbjudningar, kollar databasens hälsa och sparar en verifierad backup. Vi behåller 35 dagliga kopior, och en i månaden under ett år.

Samtycket har också en ytterdörr. Vi gav den samma omsorg.

Det som landar i inkorgen byggs samtidigt som webbplatsen, och från samma textfil. Vår kod skapar ett rent, enspaltigt HTML-dokument som fungerar i e-postklienter. All design är inbakad direkt i elementen (inlinad CSS), och vi skickar med en version i ren text. Vi tvingar inte fram någon bakgrundsfärg eller textfärg, vilket gör att mottagarens eget mörka läge fungerar precis som de är vana vid. Om texten är för lång bryts den av i slutet och pekar vidare till webben, så att mejlet håller sig under 90 kilobyte. Gmail klipper nämligen allt över ungefär 102 kilobyte, vilket riskerar att dölja avregistreringslänken i botten. Vi har noll spårning i mejlet: inga dolda pixlar, inga spårningslänkar. Motorn vet vad Postmark har levererat, men inte ett skvatt om vad mottagarna gör därefter.

Det är i skickandet som vi byggde bort risken för fel. När utskicket förbereds sparas ett fingeravtryck (en hash) av exakt den HTML och text som ska skickas iväg. Innan sändaren startar kollar den hashen. Sedan bokför den avsikten att skicka i databasen: vilket nummer, innehållet, antalet mottagare, och ett kvitto på själva listan. Först därefter skickar den. Ett enda, massivt anrop till Postmarks Bulk-API, som innehåller själva mejlet och listan med alla mottagare. Ingen loop som skickar en liten del i taget. Ingen tillfällig fil som minns var ett kraschat program stannade.

Antingen tar Postmark emot anropet och vi bevakar det via ett ID. Eller så misslyckas det på ett av två sätt. Får vi ett blankt nej kan vi lösa problemet och be systemet försöka igen, men det kräver att en människa trycker på knappen. Blir svaret oklart – som vid ett serverfel eller om nätet går ner – stannar alltihop. Hela skickandet fryser tills någon kollar databasen mot Postmarks loggar. Verktyget vi byggde för att stämma av det där är extremt pedantiskt. Det kollar anropets ID, ämnesrad, antalet mottagare och tidpunkten innan det accepterar Postmarks status som sanning.

Det finns inget "skicka direkt"-kommando. Databasen tillåter bara att ett (1) utskick av samma nummer körs. Vi lagade inte bara de luckor vi hittade – vi byggde bort dem strukturellt så att de inte längre kunde uppstå.

Söndagsrutinen styrs nu via en terminal som vi startar med två bokstäver: tj. Panelen jämför koden vi har med det senaste utkastet från Johans Obsidian. Den visar versionerna lokalt, på GitHub och på servern, och den uppdateras var tionde sekund. Val som inte går att göra tonas ner med en tydlig förklaring, så man slipper gissa varför.

[i] import the newest issue from the vault, commit only that issue, and upload it
[l] build and toggle the background local preview
[t] send the checked candidate to one remembered test address
[a] arm/disarm the checked revision for Monday 06:00
[u] unsubscribe one reader locally and at Postmark
[c] copy the current issue as rich HTML for LinkedIn

Så här ser numera en söndagskväll ut. Johan skriver klart texten i Obsidian. Han trycker [i]. Maskinen importerar texten, krymper bilderna, sparar ändringen, skickar den till servern och väntar på kvitto. Utkastet ligger nu på servern, granskat och klart, men dolt för omvärlden. [l] öppnar en förhandsvisning på skärmen. [t] skjuter iväg ett testmejl till en sparad adress – exakt den kod som ska ut, via samma servrar, fast utan att bokföras i databasen.

Sedan kommer det avgörande steget. Johan trycker [a]. Kommandot armerar versionen – och dess unika hash – för måndag 06:00. Det vi laddar maskinen med är bokstavligen de bytes som ska iväg. Om någonting ändras innan måndag, till exempel om vi rättar ett stavfel och laddar upp på nytt, avväpnar maskinen sig själv. Inget skickas förrän Johan aktivt har valt att armera den nya versionen. Ett extra tryck på [a] avväpnar utskicket. Och maskinen kan inte glömma bort det hela: om klockan slår 06:00 och tre timmar går utan att ett utskick har gått iväg, då går larmet.

Johan stänger locket. Ett utkast är armerat. Resten sköter maskinen.

Mejlet vi armerade den där första söndagen inleddes med orden "Goodbye Wordpress!". Det första maskinen gjorde var alltså att vinka hejdå till sin egen föregångare. Klockan 06:00 uppdaterades servern, utskicket accepterades, webben uppdaterades och hela listan fick numret i inkorgen. Sedan åkte det upp på LinkedIn. Vecka 30 ligger i arkivet.

Det är tre veckor sedan nu. Två måndagar till har passerat utan ett enda gupp. Människans roll har krympt till det den egentligen alltid borde ha varit: skriv texten, tryck på fyra tangenter, gå och lägg dig. Den årliga prenumerationen på WordPress-tilläggen är uppsagd. Den timslånga rutinen av manuell handpåläggning är borta. Kvar är kostnaden per mejl hos Postmark, och en liten kodbas som vi äger från ax till limpa. Vi lät Claude Fable 5 skriva motorn. Vi lät GPT-5.6 granska säkerheten. Vi stresstestade allt mot en lokal fejkserver. Och nyhetsbrevet skrivs fortfarande för hand.

Det är en modell som fungerar på alla processer där det kritiska ögonblicket inte går att ångra. Faktureringar, kundutskick, lönekörningar. Låt en enda plats äga sanningen (databasen). Gör armeringen till ett aktivt beslut knutet till exakta bytes. Bokför avsikten innan du tar klivet ut på nätverket, och stoppa maskinen vid minsta tveksamhet i stället för att chansa. Testa misstagen på en klon. Då är måndagarna tråkiga, precis som de ska vara.