Den bedste tech stack til SaaS: min anbefaling og hvorfor

Hvis jeg skulle bygge en ny SaaS i dag, ville min SaaS tech stack være Laravel som backend, React via Inertia i frontenden, PostgreSQL eller MySQL som database, Stripe til abonnementer og managed hosting med data i EU. Det er ikke det mest spændende valg, men det bringer dig hurtigst frem til betalende kunder med færrest dele der kan gå i stykker.

Jeg arbejder selv i Laravel og React, så læs anbefalingen med det forbehold. Nedenfor forklarer jeg valgene, hvordan du selv træffer beslutningen i seks trin, og hvornår min anbefaling ikke passer til dig.

Den korte version: min stack lag for lag

Ingen af valgene er eksotiske, og det er med vilje. En SaaS lykkes eller fejler på om nogen vil betale for den, ikke på om databasen er moderne nok. Hver time der går med infrastruktur, er en time der ikke går med produktet eller med at tale med kunder.

Artiklen her handler om det tekniske fundament. Er du tidligere i processen, så start med min guide til at bygge en SaaS fra idé til betalende kunder.

Sådan vælger du tech stack til din SaaS i 6 trin

Min anbefaling er et udgangspunkt, ikke en facitliste. Sådan ville jeg gribe valget an hvis jeg sad på din side af bordet:

1. Start med hvem der skal bygge og vedligeholde produktet. Den bedste stack er den som din udvikler eller dit team kan levere hurtigt og sikkert i. En erfaren Python-udvikler bygger en bedre SaaS i Django end i et framework vedkommende skal lære undervejs. Spørg også hvem der skal overtage koden om tre år, og om du kan finde folk der kan.
2. Skriv produktets tunge krav ned. Skal det vise data i realtid, håndtere store datamængder, bruge AI, virke offline eller have en mobilapp? Den slags krav påvirker valget langt mere end smag. Ved du ikke helt hvad første version skal indeholde, så afgræns din SaaS-MVP før du vælger teknologi.
3. Vælg et backend-framework hvor det kedelige er løst. Login, roller, mails, køer, planlagte jobs og ændringer i databasen skal ikke bygges fra bunden. Laravel, Rails og Django har det hele med. En minimal Node.js-opsætning kræver at du selv samler og vedligeholder delene.
4. Vælg frontend ud fra interaktivitet og SEO. Ligger det meste af produktet bag et login, er en løsning som Inertia rigeligt. Skal mange offentlige sider kunne findes på Google, vejer Next.js tungere.
5. Vælg database og hosting med data i EU. Har du kunder i EU, er det enklest at have database, backups og filer i EU fra start. Det gør dig ikke GDPR-klar alene, men det fjerner mange spørgsmål fra kundernes it-afdeling.
6. Køb dig fri af alt der ikke er kerneproduktet. Betaling, transaktionsmails (kvitteringer, nulstilling af adgangskode), fejlovervågning og eventuelt login via en ekstern udbyder koster lidt i forhold til at bygge og vedligeholde det selv.

Hvorfor Laravel er mit standardvalg til backend

Laravel er et PHP-framework der har de fleste byggesten en SaaS skal bruge, enten indbygget eller som officielle pakker. Det betyder færre tredjepartspakker at holde opdateret og færre beslutninger i starten, hvor tiden er mest værdifuld.

Det konkrete:

• Laravels officielle starter kits giver dig login, registrering, nulstilling af adgangskode, e-mailbekræftelse og tofaktorgodkendelse fra første dag. De kan også sættes op med teams, så hver bruger kan høre til et eller flere teams. Det er præcis den struktur mange B2B-produkter skal bruge.
• Køer og planlagte jobs er indbygget, så mails, eksport, rapporter og synkronisering med andre systemer kører i baggrunden.
• Laravel Cashier håndterer abonnementer, prøveperioder, skift mellem planer, kuponer, fakturaer og webhooks (beskeder fra Stripe om fx fejlede betalinger). Der findes også en udgave til Paddle. Hvilken udbyder du skal vælge, gennemgår jeg i sammenligningen af Stripe, Paddle og danske betalingsløsninger.
• Økosystemet er modent. Der er dokumentation, pakker og mange udviklere der kan overtage koden, så du ikke er låst til én person.

Ulemperne skal også med. PHP har et dårligt ry fra gamle dage, og enkelte investorer og udviklere rynker på næsen. Laravel har faste konventioner for hvordan tingene skal bygges, og går du imod dem, bliver det tungt. Og består dit team af JavaScript-udviklere, er det sjældent klogt at tvinge dem over i PHP.

Hvordan du holder kundernes data adskilt (multi-tenancy), er en beslutning for sig som du bør træffe tidligt, uanset framework.

React via Inertia eller Next.js?

Det er her mange projekter bliver gjort mere komplicerede end nødvendigt.

Med Inertia skriver du brugerfladen i React, mens routing, adgangskontrol og datahentning bliver i Laravel. Brugeren får en hurtig app der ikke genindlæser siden ved hvert klik, og du får én kodebase, ét sted at sætte i drift og intet separat API at versionere og sikre. Laravels React starter kit bygger på React 19, TypeScript, Tailwind og komponentbiblioteket shadcn/ui, så du starter ikke fra et tomt lærred.

Next.js er et stærkt framework, og jeg arbejder også i det. Jeg vælger det typisk når:

• offentlige sider er en stor del af selve produktet, fx profiler, opslag eller en markedsplads der skal findes på Google
• hele teamet er JavaScript-udviklere og skal kunne arbejde i alle lag
• frontenden skal tale med flere backends eller et eksisterende API

Prisen er ofte to kodebaser: Next.js i frontenden og et API bagved. Next.js kan sagtens køre uden for Vercel, men Next.js' egen guide til at hoste frameworket selv viser at du selv skal håndtere cache, krypteringsnøgler og versionsforskelle så snart du kører flere servere. Det er ikke svært, men det er mere at holde styr på. Vil du have hele billedet, har jeg skrevet en sammenligning af Laravel og Next.js.

Består teamet af PHP-udviklere, er Livewire et tredje spor: dynamiske skærme uden at skrive ret meget JavaScript. Og markedsføringssiden med forside, priser og blog behøver ikke ligge i selve appen. Den kan sagtens være en simpel hjemmeside for sig.

Database, køer og hosting i EU

PostgreSQL og MySQL kan begge bære langt de fleste SaaS-produkter i mange år, og Laravel understøtter begge. Vælg den din udvikler kender bedst, og brug energien på at designe tabellerne ordentligt i stedet for at diskutere databaser. Til køer og cache anbefaler jeg Redis eller Valkey, der er en open source-videreførelse af Redis.

Hosting bør være managed, så du ikke selv skal opdatere servere midt om natten. Der er to realistiske spor:

• Laravel Cloud er en fuldt administreret platform hvor Laravel står for servere, skalering og vedligehold. Prisen starter ved 5 dollars om måneden plus forbrug, og der er regioner i bl.a. Frankfurt og Irland. Deres eget regneeksempel for en tidlig SaaS-MVP lander omkring 34 dollars om måneden.
• Forge er et værktøj hvor du lejer din egen server hos en udbyder med datacenter i EU, og Forge står for opsætning og udrulning. Du får mere kontrol og ofte en lavere pris ved stabil trafik, men også mere ansvar.

AWS med egne containere og Kubernetes ville jeg vente med til der er en person hvis job det er at drive det. Jeg sammenligner mulighederne grundigere i artiklen om hosting af SaaS.

Det jeg ikke ville bygge på dag ét

Spildtid i nye SaaS-projekter skyldes sjældent et forkert framework. Oftere skyldes den arkitektur der er bygget til 100.000 brugere før produktet har ti. Det her ville jeg springe over i første version:

• Microservices. En monolit, altså én samlet applikation, er hurtigere at bygge, teste og fejlsøge. Del den først op når en del af systemet har et konkret behov.
• Kubernetes og hjemmebygget infrastruktur. Det kræver en der kan drive det, og den person har du sjældent i starten.
• Et separat API "for en sikkerheds skyld". Byg det når en mobilapp eller en integrationspartner faktisk skal bruge det.
• Egen betalingsmotor eller hjemmebygget login. Stripe og gennemprøvede pakker har løst det bedre end du når på et par uger.
• En native mobilapp fra start. En responsiv webapp er nok til at finde ud af om nogen vil betale.
• Det nyeste framework på markedet. Noget der kun er et år gammelt, har færre svar på nettet og færre udviklere der kan overtage koden.

De samme fravalg gælder funktionerne. Se min liste over funktioner din SaaS ikke har brug for ved lancering.

Hvornår min anbefaling ikke passer

Laravel og React er ikke svaret på alt. Vælg noget andet i disse situationer:

• Dit team kender allerede en anden stack godt, fx .NET, Django eller Rails. Brug den. Gevinsten ved at skifte er mindre end prisen.
• Hele teamet skriver TypeScript. Så er en ren TypeScript-stack med Next.js, en Node.js-backend og PostgreSQL et fornuftigt valg, fordi alle kan arbejde i alle lag.
• Produktet er bygget omkring maskinlæring eller egne AI-modeller. Python har det stærkeste økosystem til det. Skal du bare kalde færdige AI-tjenester via deres API, klarer Laravel det fint.
• Kernen i produktet er samarbejde i realtid, fx flere der redigerer det samme dokument på én gang. Laravel har sin egen websocket-server (Reverb) til notifikationer og live-opdateringer, men et produkt hvor realtid er hele pointen, kan have brug for værktøjer bygget specifikt til det.
• Du har ikke valideret idéen endnu. Så er det for tidligt at vælge stack. En landingsside, et forsalg eller en manuel udgave af ydelsen fortæller dig mere end kode.

Det betyder også at en Laravel-udvikler som mig ikke altid er det rigtige valg. Har du et JavaScript-team der mangler en ekstra hånd, bør du finde en der arbejder i præcis den stack.

Næste skridt: tjek din stack før du bygger

Gå listen igennem før den første linje kode bliver skrevet. Den passer til min anbefaling, men også til de fleste andre stacks.

Kan du sætte flueben ved det hele, er fundamentet på plads. Mangler der flere, eller er du i tvivl om valget passer til dit produkt, kan du se hvordan jeg arbejder med udvikling af SaaS-produkter. Ved større projekter starter jeg med et betalt forprojekt til fast pris, hvor omfang og teknologi bliver afklaret før der skrives kode. Og koden er din fra første dag.

Ofte stillede spørgsmål

Kan jeg skifte tech stack senere?+

Ja, men det er sjældent en god forretning at skrive det hele om. Det realistiske er at skifte dele ud gradvist: flytte hosting, ombygge frontenden skærm for skærm eller trække en tung funktion ud i en separat tjeneste. En fuld omskrivning tager ofte længere end planlagt, og imens får kunderne intet nyt. Derfor betaler det sig at vælge noget kendt fra starten.

Er PHP ikke forældet?+

Nej. PHP udvikles aktivt og får en ny version med nye funktioner hvert år, og Laravel er i 2026 på version 13. Det dårlige ry stammer fra en tid hvor meget PHP blev skrevet uden framework og uden tests. Moderne PHP med typer, automatiske tests og et framework som Laravel er et sikkert valg til en SaaS. Det vigtigste er at der findes udviklere der kan arbejde i det, og det gør der.

Hvad koster det at drive stacken om måneden?+

I starten typisk få hundrede kroner om måneden til hosting, som regneeksemplet fra Laravel Cloud ovenfor viser. Dertil kommer transaktionsgebyrer til betalingsudbyderen, en mailtjeneste og fejlovervågning, der ofte har gratis niveauer i begyndelsen. Den store post er udvikling og vedligehold, ikke servere.

Kan jeg bygge min SaaS med et AI-værktøj som Lovable i stedet?+

Til at teste en idé og lave en klikbar prototype hurtigt, ja. Til et produkt med betalende kunder skal du have styr på login, rettigheder, betaling, backups og sikkerhed, og det er netop dér genererede prototyper ofte mangler noget. En almindelig vej er at bruge prototypen til at validere idéen og derefter få bygget den rigtige version på en kendt stack.

Hvilken stack skal jeg vælge hvis jeg også vil have en mobilapp?+

Start med en responsiv webapp, og byg API'et når mobilappen faktisk er på vej. Laravel fungerer fint som backend for en app skrevet i React Native, så forretningslogikken kan genbruges. Skal appen bruge telefonens funktioner meget, er React Native eller en native app det rigtige. Ellers kan en PWA (en webapp der kan installeres på telefonen) række langt.