Att välja teknikstack för din första SaaS: en grundares ärliga guide

Fråga tio ingenjörer vilken teknikstack du borde använda till din första SaaS och du får femton svar, tre av dem levererade med religiös övertygelse. De flesta av dessa svar är rätt — för den som ger dem. Inget av dem handlar om dig, din kassa eller kunderna du ännu inte har skrivit kontrakt med. Om du är grundare som stirrar på det här beslutet och mår lite illa, här är det ingen säger högt: stacken spelar långt mindre roll än du fått intrycket av, och de få sätt den faktiskt spelar roll på är inte de man bråkar om på nätet.

Jag har hjälpt en hel del förstagångsgrundare att ta sig från en pitch-presentation till en produkt som riktiga människor betalar för. Nästan ingen av dem var teknisk. Nästan alla anlände efter att ha sugit i sig en skrämmande mängd stackfolklore — att de behövde mikrotjänster, att ett ramverk var ”dött”, att fel val skulle döma dem. Och nästan varje gång visade sig stacken vara ett av de minst betydelsefulla besluten de fattade det året. Det som dödade projekt var omfattning, oklart ägarskap och att vackert bygga fel sak. Aldrig ramverket.

Så det här är guiden jag ger de grundarna innan vi skriver en enda rad kod. Den säger inte åt dig att använda en specifik stack, för den som lovar det utan att känna till din verksamhet säljer något. Istället ger den dig ett sätt att tänka — så att vad du än väljer, eller vad ditt team än föreslår, kan du sunt förnufts-granska det som en vuxen istället för att nervöst nicka med.

Varför beslutet känns svårare än det är

Stackfrågan känns enorm eftersom det är det första till synes oåterkalleliga valet du gör, och det är inlindat i ett språk du inte talar. Ord som Postgres, React, Kubernetes, serverless kastas omkring som om valet mellan dem vore som att välja grunden till en byggnad — välj fel och hela alltihop rasar.

Men mjukvara är ingen byggnad. Den är mycket närmare ett kök du kan bygga om medan du fortfarande lagar mat. Framgångsrika bolag skriver om delar av sin stack hela tiden; versionen av en produkt som hittar sina första hundra kunder är nästan aldrig versionen som betjänar de första hundra tusen. Målet med din första stack är inte att hålla för evigt. Det är att låta dig bygga, ändra och leverera tillräckligt snabbt för att lära dig om någon överhuvudtaget vill ha det här. Det är en helt annan — och mycket lägre — ribba än ”perfekt för det kommande decenniet”.

När du väl accepterar det halveras pressen. Du försöker inte längre förutspå framtiden. Du försöker göra en rimlig, återkallelig satsning som tar dig till en fungerande produkt och betalande användare. Och rimliga satsningar är något en icke-teknisk grundare absolut kan bedöma.

Vad en ”stack” faktiskt är, i klartext

Innan du bestämmer något hjälper det att avmystifiera ordet. En teknikstack är bara samlingen av verktyg som används för att bygga och köra din mjukvara. Du kan tänka på den i fyra lager, och du behöver inte förstå något av dem på djupet — du behöver bara veta att de finns.

• Frontend — det användarna ser och klickar på i sin webbläsare eller app. Det här är delen alla dömer dig på.
• Backend — logiken och reglerna som körs på en server: vem får göra vad, vad händer när de gör det, hur pengar rör sig.
• Databasen — där din information faktiskt bor: användare, beställningar, prenumerationer, allt du skulle bli förkrossad över att förlora.
• Infrastrukturen — servrarna och tjänsterna som håller allt ovanstående online, säkerhetskopierat och nåbart klockan tre på natten.

När någon säger ”vi använder en modern JavaScript-stack” eller ”Rails på Postgres” beskriver de val över dessa fyra lager. Det är allt. Varje SaaS, från ett tvåmanna-sidoprojekt till ett börsbolag, är någon version av dessa fyra saker staplade på varandra. De storslaget klingande arkitekturdiagrammen är bara det här, ritat med fler rutor.

Det som faktiskt spelar roll (och det som inte gör det)

Här går de flesta stackråd fel: de optimerar för saker som inte påverkar dina första två år och ignorerar de som gör det. Låt mig vara rak om båda listorna.

Vad som verkligen spelar roll

Vem som kan bygga och underhålla den. Den enskilt största faktorn är inte tekniken — det är människorna. Den bästa stacken för dig är den ditt team (eller partnern du anlitar) faktiskt kan arbeta i, flytande, idag. En ”perfekt” stack som bara en sällsynt specialist förstår är ett sämre val än en tråkig som vilken kompetent utvecklare som helst kan ta över. Rekrytering och kontinuitet slår teoretisk elegans varje gång.

Hur snabbt du kan ändra saker. Tidigt kommer du ständigt ha fel om din produkt. Stackens verkliga jobb är att göra det billigt att ändra sig. Mogna, väldokumenterade verktyg med stora communities låter dig röra dig snabbt eftersom svaren på dina problem redan finns. Knivskarpt nya verktyg gör dig till den som upptäcker buggarna.

Om du kan rekrytera för den. Välj något obskyrt och du binder din framtid till den som byggde det. Välj något vanligt och tråkigt och du kan alltid hitta nästa utvecklare, nästa byrå, nästa person som tar över. Tråkigt är en fördel när din verksamhet hänger på det.

Vad som spelar långt mindre roll än folk säger

Rå prestanda och ”skala”. Du har inget skalningsproblem. Du har ett ingen-använder-det-än-problem, vilket är det motsatta problemet. Arkitekturer designade för miljoner användare kommer sakta ner dig när du har elva. De berömda bolagen du härmar byggde den enkla versionen först och byggde om senare, finansierat av framgång. Det borde du också.

Vilket specifikt ramverk som ”vinner” i år. Ramverk stiger och faller i en modecykel som har nästan inget att göra med huruvida de bygger din faktureringsSaaS bra. Vilket som helst av de etablerade, brett använda alternativen klarar jobbet. Trenden är brus; välj från den tråkiga, populära mitten och gå vidare.

Varför ”tråkig” teknik oftast vinner

Det finns en tyst visdom bland erfarna byggare som nykomlingar tycker är nedslående: den bästa tekniken för en ny verksamhet är oftast den tråkiga, beprövade, lite omoderna sorten. Inte för att nya verktyg är dåliga, utan för att varje val du gör spenderar en begränsad budget av nyhet — antalet obekanta, ostödda, överraskande saker ditt lilla team kan hantera på en gång.

Spendera den budgeten på det som gör din verksamhet speciell — själva produkten, insikten bara du har. Spendera den inte på en databas ingen hört talas om bara för att känna dig modern. En tråkig, mogen stack betyder att problem har lösts förut, dokumentation finns, rekrytering är lätt och verktyget försvinner inte nästa år när dess enda underhållare tappar intresset. Tråkigt låter dig lägga all din entusiasm där den lönar sig: på kunden.

Det är också här AI förändrar bilden lite — och inte på det sätt hypen antyder. AI-kodningsassistenter är dramatiskt bättre på tråkig, populär teknik, eftersom de tränades på ett decennium av offentliga svar om den. Välj en etablerad stack och ditt team (och dina verktyg) får snabbare hjälp gratis. Välj något exotiskt och du är på egen hand precis när du har minst råd med det.

En beslutsmetod du faktiskt kan använda

Nog med principer. Här är ett konkret sätt att nå ett beslut, oavsett om du väljer själv, briefar en frilansare eller utvärderar vad en byrå föreslår. Inget av det kräver att du skriver kod — bara att du frågar rätt saker och väger svaren.

1. 1
   Utgå från teamet, inte tekniken

   Fråga: vem bygger och underhåller det här de kommande två åren? Vad de redan kan väl är ditt starka standardval. Att byta stack för att jaga en trend slår sällan flyt.
2. 2
   Förvalet är etablerat och beprövat

   Välj från den populära, väldokumenterade mitten av varje lager. Om du inte snabbt hittar guider, jobb och stora communities för ett verktyg, behandla det som en varning, inte en fördel.
3. 3
   Optimera för förändring, inte skala

   Föredra valet som gör det billigt och snabbt att redigera din produkt. Du kommer ha fel om produkten gång på gång — stackens jobb är att göra det överlevbart att ha fel.
4. 4
   Håll arkitekturen så enkel den kan vara

   En databas. En backend. En frontend. Inga mikrotjänster, inget smart distribuerat något, förrän ett verkligt, uppmätt problem tvingar din hand. Enkelhet är målet, inte kompromissen.
5. 5
   Skriv ner varför du valde den

   Ett stycke: vem bygger den, vad du valde och vad som skulle behöva ändras för att du ska ompröva. Den anteckningen besparar dig att ta upp beslutet på nytt varje gång någon läser en het åsikt.

Följer du inget annat, följ steg ett och fyra. Bygg med människorna du har, på den enklaste arkitektur som fungerar. Den kombinationen undviker tyst de två misslyckanden som sänker de flesta första SaaS-produkter: ingen som kan underhålla den, och ett system för komplicerat för sin egen storlek.

Frågor att ställa till den som föreslår en stack

De flesta grundare väljer inte stacken ensamma — en utvecklare, en byrå eller en CTO-vän föreslår en. Du behöver inte verifiera tekniken själv. Du behöver ställa en handfull frågor och lyssna på hur de svarar. Självsäkra svar på klarspråk är ett gott tecken. Defensiv jargong är det inte.

• ”Varför det här, och inte det tråkiga populära alternativet?” — ett bra svar handlar om dina specifika behov, inte om vad som är trendigt.
• ”Om du blev påkörd av en buss, hur lätt skulle någon annan kunna ta över det här?” — svaret avslöjar hur sällsynt och riskabelt valet är.
• ”Vad är den enklaste versionen av den här arkitekturen som ändå fungerar?” — se om de griper efter enkelhet eller komplexitet.
• ”Hur lätt blir det att rekrytera nästa utvecklare för det här?” — vanliga kunskaper betyder en sund marknad; exotiska betyder beroende.
• ”Vad händer när vi behöver ändra en kärnfunktion om tre månader?” — du vill höra att förändring är billig, inte fruktad.

Vanliga fällor som ser ut som goda idéer

Några mönster dyker upp så ofta att de är värda att namnge, eftersom var och en känns ansvarsfullt i stunden och kostar dig dyrt senare.

Att bygga för en skala du inte har. Lusten att ”göra det ordentligt” får grundare att arkitektera för miljoner användare innan de har tio. Varje bit av den framtidssäkringen är komplexitet du betalar för nu, i tid och pengar, för att lösa ett problem som kanske aldrig kommer. Bygg för de nästa hundra användarna. Omarkitektera när tillväxt gör det nödvändigt — och låt det vara ett lyckligt problem.

Att jaga det nyaste. Ett glänsande ramverk som släpptes förra månaden har inga meriter, tunn dokumentation och en liten community. Du kommer tillbringa dina nätter med att felsöka verktyget istället för att bygga din produkt. Låt andra vara de tidiga användarna; du har en verksamhet att leverera.

Att lägga ut på den billigaste, på vad den föredrar. Lägsta budet kommer ofta med en obskyr stack som bara det ena teamet kan. Den dag ni skiljs blir din produkt en ö ingen annan kan nå. Billigt i förväg, ruinerande senare. Insistera på etablerad, rekryterbar teknik även när du lägger ut — särskilt när du lägger ut.

När det faktiskt är dags att ompröva din stack

Inget av detta betyder ”ändra aldrig”. Det betyder ändra av verkliga skäl, uppmätta, inte inbillade. Du vet att det verkligen är dags att utveckla din stack när konkreta signaler dyker upp — inte när ett blogginlägg gör dig orolig.

Lägg märke till mönstret: verkliga skäl handlar om uppmätt smärta i din faktiska verksamhet. Falska skäl handlar om mode, jämförelse och rastlöshet. När en verklig signal väl dyker upp ändrar du en bit i taget — inte hela stacken i en heroisk omskrivning som stannar allt i sex månader. Evolution, inte revolution.

Vanliga frågor