Att skala en SaaS efter lanseringen utan att förstöra produkten

Alla firar lanseringen. Nästan ingen varnar dig för den del som kommer efteråt — det märkliga, nervpåfrestande året när produkten som gav dig dina första hundra kunder börjar svikta under vikten av de nästa tusen. Inget dramatiskt händer. Saker blir bara långsammare, skakigare, svårare att ändra. En tisdag inser du att en funktion som förr tog en dag nu tar en vecka, och ingen kan riktigt säga varför. Det är där, inte vid lanseringen, som de flesta SaaS-produkter tyst vinns eller förloras.

Vi har suttit med många grundare precis vid den här punkten. De håller inte på att misslyckas — det är det förvirrande. Intäkterna stiger, teamet växer, demona går bra. Men under ytan kvider produkten. Supportärendena ökar snabbare än användarna. Driftsättningar som förr var tråkiga kommer nu med andan i halsen. Kodbasen som kändes smart för ett år sedan känns nu som ett minfält där varje ändring riskerar att utlösa något annat. De gjorde inget fel. De växte bara ur det de byggde, och ingen sa åt dem att det var meningen att det skulle hända.

Så det här är guiden vi önskar att fler grundare hade haft innan sprickorna dök upp. Den handlar inte om hyperskala, Kubernetes eller vad någon enhörning gjorde vid femtio miljoner användare. Den handlar om den tråkiga, avgörande mellanfasen — att gå från det fungerar för några få till det fungerar för många — utan att skriva om allt, skrämma bort dina kunder eller bränna ut ditt team. Målet är inte en perfekt arkitektur. Det är en produkt som fortsätter växa istället för en som tyst börjar gå sönder.

Vad som faktiskt går sönder när en SaaS växer

Här är den del som överraskar grundare mest: skalningsproblem anländer nästan aldrig som det dramatiska avbrott du vapnar dig mot. Servern fattar inte eld. Istället utvecklar produkten ett slags lågintensiv feber. Sidor som laddades direkt börjar ta tre sekunder. En rapport som gick fint för tidiga kunder timar ut för den stora som just skrev på. Samma bugg dyker upp om och om igen eftersom två delar av koden i hemlighet är beroende av varandra på ett sätt som ingen dokumenterade.

Det som verkligen går sönder är sällan dina servrar — det är dina antaganden. Tidigt byggde du för formen på dina första användare: några få konton, lite data, enkla arbetsflöden, alla ungefär likadana. Tillväxt lägger inte bara till mer av samma. Den lägger till variation. En kund med tio gånger så mycket data. Ett team som använder en funktion på ett sätt du aldrig föreställt dig. En topp klockan nio på måndagsmorgonen när alla loggar in samtidigt. Var och en av dem bryter tyst mot ett antagande som bakades in i din kod för ett år sedan, när att bryta mot det var otänkbart.

De fyra ställen där det tenderar att visa sig först är förutsägbara. Databasen är nästan alltid kanariefågeln — frågor som var omedelbara på små tabeller kryper när datan växer. Den långsamma slutpunkten: en eller två sidor som gör för mycket arbete per förfrågan, vilket går bra tills trafiken staplas. Den sköra driftsättningen, där det blivit skrämmande att skicka ut något alls eftersom koden är för tilltrasslad för att överblicka. Och supportbelastningen, som inte alls är infrastruktur men är den sannaste tidiga signalen på att produkten inte längre passar hur folk faktiskt använder den.

Fällan att lösa problem du inte har än

Innan vi pratar om att fixa saker, en varning som räddat fler produkter än någon optimering. Det största hotet mot en växande SaaS är inte att ignorera skala — det är att jaga den för tidigt. I det ögonblick en grundare känner den första nedsaktningen är instinkten att gripa efter den arkitektur de läste om på någon känd ingenjörsblogg. Mikrotjänster. En meddelandekö. En multiregionsuppställning. Att sharda databasen innan den har en miljon rader.

Så här lägger du sex månader och en förmögenhet på att bygga infrastruktur för en skala du inte nått, medan själva produkten slutar röra sig. Värre, du har nu gjort varje framtida ändring svårare, eftersom ett distribuerat system är dramatiskt mer komplext att bygga och felsöka än det enkla du hade. Du bytte ett problem du inte hade än mot ett garanterat som du har idag: inget blir klart.

Disciplinen här är densamma som gör bra produkter från första början: lös problemet framför dig, inte det du smickras av att föreställa dig. En tråkig, välförstådd monolit du kan ändra snabbt kommer att överskala ett moderiktigt distribuerat system du är rädd att röra. Komplexitet är en kostnad du betalar varje enda dag, inte ett engångsköp.

Mät innan du ändrar något

Nästan varje grundare vi möter i det här skedet är övertygad om att de vet var problemet finns. De har fel ungefär halva tiden — inte för att de är slarviga, utan för att intuition är en usel profilerare. Den del av koden som känns långsam är ofta bra; den verkliga boven är någon tyst fråga som körs fyrtio gånger på en sida ingen tänkte på. Du kan inte fixa det du inte mätt, och att gissa här är hur team lägger veckor på att optimera fel sak.

Du behöver ingen flådig observerbarhetsstack för att börja. Du behöver tre tråkiga siffror framför dig, hela tiden. Vilka slutpunkter är långsammast, och hur långsamma under verklig trafik. Vilka databasfrågor tar mest total tid — inte den långsammaste enskilda frågan, utan den vars tid summeras över tusentals anrop. Och var fel faktiskt sker, med tillräckligt med kontext för att återskapa dem. Med de tre brukar dimman lätta inom en dag.

1. 1
   Slå på grundläggande övervakning

   Svarstider per slutpunkt, felfrekvenser och loggning av långsamma frågor i databasen. Molntjänster gör det på en eftermiddag. Du kan inte förbättra en siffra du inte ser.
2. 2
   Hitta de verkliga tre i topp

   Sortera efter total förbrukad tid, inte magkänsla. Tre bovar står nästan alltid för det mesta av plågan. Skriv ner dem — det är din verkliga färdplan.
3. 3
   Fixa en, mät igen

   Ändra en enda sak, kontrollera sedan siffrorna igen. Bekräfta att det hjälpte innan du går vidare. Två ändringar på en gång och du vet aldrig vilken som spelade roll.
4. 4
   Sluta när det är tillräckligt bra

   Definiera 'tillräckligt snabb' innan du börjar — säg, varje sida under en sekund vid nuvarande last. Bortom det är optimering en tidsslukare, inte en vinst.

Det sista steget spelar större roll än det ser ut. Prestandaarbete är genuint beroendeframkallande; det finns alltid en millisekund till att skala bort. Men dina kunder känner inte skillnaden mellan 200 ms och 120 ms, och timmarna du lägger på att jaga den är timmar du inte lägger på funktionen som faktiskt skulle få verksamheten att växa. Mät, fixa de tre i topp, utropa seger, gå vidare.

Databasen är nästan alltid den första väggen

Om vi var tvungna att satsa pengar på var en växande SaaS slår i sitt första riktiga tak, skulle vi satsa på databasen varje gång. Det är den enda del av systemet där små tidiga beslut bygger upp sig hårdast. En fråga utan index körs på ett ögonblick på tusen rader och kör fast på en miljon. Koden ändrades inte. Datan gjorde det — och data växer bara.

Den goda nyheten är att databasen också är där de billigaste, mest slagkraftiga fixarna finns. Den klassiska är det saknade indexet: en enda rad som förvandlar en flersekundersfråga till en omedelbar, eftersom databasen slutar skanna varje rad för att hitta de få den behöver. Strax bakom finns N+1-frågeproblemet — en sida som, istället för att ställa en fråga, tyst ställer samma lilla fråga till databasen hundratals gånger i en loop. Båda är vanliga, båda är osynliga tills du tittar, och båda är vanligtvis en endagsfix när du väl hittat dem.

Det finns en ordning att luta sig mot här, och det lönar sig att följa den i tur och ordning istället för att hoppa till slutet. Fixa frågorna först — index, N+1:or, den långsamma rapporten. Lägg sedan till cachning för data som läses ständigt men ändras sällan. Först därefter är det vettigt att prata om läsrepliker, större instanser eller att dela ut data. De flesta SaaS-produkter behöver aldrig de senare stegen. De behövde bara de första gjorda ordentligt.

Att skala produkten betyder att skala hur du ändrar den

Här är skiftet som tar grundare på sängen: bortom en viss punkt slutar skalning handla om att produkten hanterar fler användare och börjar handla om att ditt team hanterar mer förändring. När det var du och en utvecklare höll alla hela systemet i huvudet. Du kunde ändra vad som helst eftersom du visste vad det skulle påverka. Vid fem eller tio personer krossas den mentala modellen — och koden som antog att alla visste allt blir en belastning.

Det här är det verkliga skälet till att driftsättningar blir skrämmande. Det är inte att koden blev sämre över en natt; det är att ingen längre kan förutsäga sprängradien av en ändring fullt ut. Lösningen är inte hjältedåd eller ett stopp för utskick. Det är att investera i den oglamorösa byggnadsställning som låter ett större team röra sig utan att trampa varandra på tårna: en automatiserad testsvit som fångar de uppenbara haverierna, driftsättningar som är rutin istället för ceremoniella, och ett sätt att stänga av en dålig release på sekunder istället för att famla i panik.

• En testsvit som täcker den handfull flöden som vore katastrofala om de gick sönder — inloggning, betalning, kärnhandling. Inte allt; de kritiska få.
• Driftsättningar som körs på en knapp, inte en ritual, så att skicka ut smått och ofta blir säkert istället för nervigt.
• Ett snabbt sätt att rulla tillbaka, så att en dålig release är en femminutershändelse, inte ett incident som tar hela natten.
• Funktionsflaggor, så att du kan skicka kod till några få kunder först och stänga av den direkt om den missköter sig.
• Tillräckligt med dokumentation så att en persons semester inte fryser ett helt område av produkten.

Inget av det här syns i en demo. Inget av det lägger direkt till en funktion. Och det är precis det arbete som skiljer en produkt som fortsätter accelerera från en som maler långsammare för varje ny anställning. Teamen som skalar väl är de som behandlar sin förmåga att ändra produkten säkert som en funktion i sig — för i skala är det precis vad det är.

En kort berättelse från spricktillfället

För att göra det konkret, här är ett sammansatt fall hämtat från arbete vi gjort — detaljerna suddiga, formen trogen verkligheten. En liten SaaS för att hantera fältserviceteam hade lanserat bra och vuxit till några hundra betalande företag. Grundarna var lika delar lyckliga och utmattade. Sedan skrev deras största kund någonsin på: ett företag med fler användare och mer historisk data än deras tidigare tio klienter tillsammans.

Inom en vecka hade instrumentpanelen som alla levde i saktat ner till en krypning för den kunden — och, märkligt nog, för alla andra också. Supportärendena sköt i höjden. Grundarna antog att de behövde en mycket större server och vapnade sig för en smärtsam, dyr omarkitektur. Det var ögonblicket vi kallades in, och instinkten var förståelig men fel.

Vi rörde inte arkitekturen. Vi slog på loggning av långsamma frågor och tittade på under en eftermiddag. Boven var nästan pinsamt liten: huvudinstrumentpanelen laddade varje användares jobblista med ett klassiskt N+1-mönster och avfyrade en fråga per jobb. För en liten kund innebar det några dussin harmlösa frågor. För den nya jätten innebar det tusentals per sidladdning — vilket, på delad infrastruktur, drog ner hela systemet för alla.

Läxan grundarna tog med sig var inte teknisk. Den var att det skräckinjagande skalningsproblem de föreställt sig — det som krävde en ombyggnad och en finansieringsrunda — var, när det mättes, en tvådagarsfix som gömde sig bakom ett skrämmande symptom. De hade varit på väg att lägga månader på att lösa fel problem. Det gapet, mellan den inbillade krisen och den uppmätta, är där det mesta av skalningspengarna slösas bort.

När det faktiskt är dags att bygga om en del

All den här försiktigheten kring förtidig skalning kan låta som refaktorera aldrig, bygg aldrig om. Så är det inte. Ibland har en del av produkten genuint nått slutet på sin livslängd, och att lappa den igen är det dyra valet. Konsten är att skilja en verklig strukturell gräns från vanlig växtvärk som en uppmätt fix skulle hantera.

Den ärliga signalen är denna: bygg om en komponent när kostnaden att ändra den konsekvent blivit högre än kostnaden att ersätta den. Inte när den är ful — ful kod som är stabil och sällan rörd är okej. Du letar efter en del av systemet där varje ändring är långsam och riskabel, där samma buggar fortsätter komma tillbaka, där nya utvecklare inte kan arbeta säkert och där du redan provat de billigare fixarna och kört in i en vägg. När flera av dessa är sanna samtidigt är en fokuserad omskrivning av just den ena delen rätt beslut.

Och när du bygger om, bygg om en del — inte produkten. Den fullständiga omskrivningen från grunden är skalningens sirensång, det som känns rent och slutar med att sänka ett år medan konkurrenterna skickar ut. Ersätt den ena ruttna komponenten, bakom en tydlig gräns, medan resten av produkten fortsätter köra och tjäna. Kirurgiskt, inte heroiskt.

Vanliga frågor