Välja teknikstack för SaaS utan att ångra sig
Av CodexierPublicerad 5 min läsning
Stacken du väljer för en SaaS-produkt är ett rekryteringsbeslut, ett driftbeslut och ett riskbeslut förklätt till ett tekniskt. Grundare ångrar stackar inte för att tekniken var dålig utan för att ingen i Sverige gick att rekrytera för att underhålla den, för att datan hamnade utanför EU, eller för att den enda utvecklare som förstod den slutade. Den här guiden ger dig ett sätt att välja som du kan försvara om två år.
Det korta svaret
Stackvalet är en av leveranserna i vår MVP-planering, och det är oftast det kortaste avsnittet, eftersom svaret för de flesta produkter inte är exotiskt.
Därför vinner beprövad teknik tidigt
Varje teknik rymmer ett fast antal överraskningar: buggar, saknade bibliotek, egenheter i driften, säkerhetsvarningar. Mogna, brett använda verktyg har fått de flesta av sina överraskningar hittade och nedskrivna av andra. Ett nytt ramverk har dem fortfarande kvar att upptäcka, och du hittar dem veckan före en kunddemo. Före produkt- och marknadspassning är uppmärksamhet er knappa resurs, och stacken ska förbruka så lite av den som möjligt.
Beprövat betyder också sökbart. När en utvecklare kör fast klockan elva på kvällen är frågan om svaret redan finns på nätet. För PostgreSQL, React och Node gör det det. För förra årets modernaste körmiljö gör det kanske inte det.
Val av frontend, backend och databas
| Lager | Standardval vi rekommenderar | Rimliga alternativ | Välj alternativet när |
|---|---|---|---|
| Frontend | React med TypeScript (Next.js eller Vite) | Vue, Svelte | Teamet redan kan det väl |
| Backend | TypeScript på Node, eller samma ramverks serversida | Python (Django, FastAPI), .NET, Go | Tung data- eller ML-bearbetning, eller befintlig kompetens i teamet |
| Databas | PostgreSQL, driftad | MySQL, SQLite för små verktyg | Nästan aldrig för SaaS; dokumentdatabaser bara för data som verkligen är dokumentformad |
| Inloggning | En driftad leverantör med BankID-stöd om ni säljer i Sverige | Bygga eget | Aldrig för en MVP |
| Drift | Driftad plattform med EU-regioner | Egen server, Kubernetes | Ni har en driftperson och ett skäl |
Plattformar av typen backend-as-a-service, som Supabase eller Firebase, kan ersätta backend- och databaslagren för en MVP. De kortar första versionen avsevärt; priset är hur mycket logik som låses in i deras konventioner, vilket vi går igenom i vår separata jämförelse av de två.
Drift och datalagring inom EU
Svenska och europeiska kunder, särskilt offentlig sektor, vård och finans, frågar var datan lagras innan de skriver på. Är svaret en amerikansk region för att det var standard i installationsguiden förlorar ni affären eller påbörjar en flytt. Välj en leverantör med EU-regioner, lägg databas, säkerhetskopior och fillagring där, och kontrollera att loggning och felspårning gör detsamma. Datalagring i EU är inte samma sak som GDPR-efterlevnad, men det är frågan köparna ställer först, och ett bra svar signalerar att ni kan resten.
- Databas och säkerhetskopior i en EU-region, med ett dokumenterat återställningstest.
- Filuppladdningar i EU-lagring; många produkter glömmer det och har dokumenten i en amerikansk hink.
- Tredjepartstjänster med behandling i EU eller ett tecknat biträdesavtal: mejlutskick, felspårning, analys, supportchatt.
- Ett stycke om datalagring färdigt för säkerhetsenkäten varje större kund kommer att skicka.
Risk vid rekrytering och överlämning
Ställ en fråga till varje kandidatstack: om utvecklaren som valde den slutar nästa månad, hur många inom räckhåll kan ta över? Sök på teknikens namn på svenska jobbsajter och räkna. TypeScript, React, PostgreSQL, Python och .NET ger långa listor. Nischade språk och ramverk ger korta, och varje utvecklare på den listan vet att ni saknar alternativ. Samma logik gäller byråer: en stack som bara en studio i landet arbetar med är en inlåsning, oavsett vad avtalet säger.
Överlämningsrisken minskar mer av vanor än av val: en README som startar projektet från noll, dokumenterade miljövariabler, en driftsättning som en ny person kan köra första dagen, och inga manuella steg på en server som bara en person känner till.
Stackar vi undviker för en MVP
Mikrotjänster från dag ett
Tio tjänster för en produkt utan användare mångfaldigar arbetet med driftsättning, övervakning och felsökning. Börja med en driftsättbar enhet och dela när en verklig flaskhals dyker upp.
Ett ramverk som släpptes i år
Ni blir obetalda testare. Vänta tills rekryteringsmarknaden och biblioteken kommit ikapp.
Egenbyggd inloggning och betalning
Båda är lösta problem med säkerhetskonsekvenser. Använd en leverantör för inloggning, BankID och kortbetalningar.
En stack vald för en framtid ni inte har
Att designa för miljoner användare före tio betalande lägger till månader. Ert första skalningsproblem blir inte det ni förutspådde.
När ni inte behöver något stackbeslut alls: kan produkten valideras med ett no-code-verktyg, ett kalkylblad och en landningssida, gör det först och välj stack när ni vet vad ni bygger. Och levererar teamet redan tryggt i en mogen stack vi inte listat, behåll den; teamets vana slår våra standardval. Ligger ni mellan de fallen, boka ett samtal och beskriv produkten; vårt planeringsarbete till fast pris finns på prissidan.
Vanliga frågor
Är Next.js ett tryggt standardval för en svensk B2B-SaaS?
Ja, för de flesta produkter med ett webbgränssnitt. Det är brett använt, lätt att rekrytera för och driftas väl i EU-regioner hos flera plattformar. Den viktigaste försiktigheten är att inte ta in varje ny renderingsfunktion på en gång; håll arkitekturen enkel tills produkten behöver mer.
Ska vi använda Supabase eller bygga egen backend?
För en MVP med standardbehov tar en backend-as-a-service-plattform er snabbare till en första version och med mindre kod att underhålla. Bygg egen backend när domänlogiken är komplex, när ni behöver bakgrundsbearbetning plattformen inte erbjuder, eller när en kund kräver drift plattformen inte kan ge.
Hur lägger vi till BankID i stacken?
Via en BankID-ombud eller identitetsleverantör i stället för direktintegration; den direkta vägen kräver ett certifikatavtal med en bank och mer driftarbete än en MVP bör ta på sig. Välj en inloggningsleverantör med stöd för svenskt BankID från start, så är stackfrågan avgjord.
Kan vi byta stack senare?
Delar av den, ja. Att byta frontend-ramverk eller driftleverantör är ett avgränsat projekt. Att byta databas eller backendspråk är en omskrivning. Därför förtjänar databasen och backendspråket mest eftertanke och frontend minst.
Väljer ni stack för en produkt ni snart ska bygga?
Beskriv produkten, teamet och var kunderna finns. På en kvart säger vi vilken stack vi skulle använda, vad vi skulle undvika och om en planeringsfas är värd det innan ni skriver kod.
Boka ett kostnadsfritt 15-minuterssamtal