The "best stack for a SaaS" question is the wrong question. There isn't one. The right question is "best stack for my specific situation," and the answer depends on what your product does, who'll work on it later, and how much complexity your business can tolerate.
I've watched founders pick stacks based on three terrible criteria: what their friend used, what was on Hacker News last month, and what an over-eager developer suggested because it's what they personally enjoy working with. None of these produce good outcomes. The stack you pick today is the stack you'll be living with for at least 3 years. Picking it on vibes is how you end up rebuilding from scratch in year 2.
This article is a decision framework, not a single recommendation. The framework filters by what your product does, then narrows by your specific constraints.
The four product archetypes
Most SaaS products fall into one of these four archetypes. Pick the one that matches your product, and you've eliminated 80% of the "should I use X?" noise.
Archetype 1: Content-heavy / SEO-driven
Your product depends on having lots of pages indexed by Google. Marketplaces, directories, content sites with user-generated content, course platforms, recipe sites, real-estate portals, job boards.
The dominant constraint: every page needs to render fast for Google's crawler and rank well in search results.
Pick: Next.js + Postgres on Vercel + Supabase. Or Astro for the marketing-only parts. The static-site-generation and incremental-static-regeneration features in modern React frameworks were designed for exactly this use case. Laravel works too, but you'll fight it for the SEO performance that Next.js gives you for free.
What to avoid: heavy single-page-application setups where Google sees an empty <div id="root"></div> and can't index anything. This was a fashionable choice in 2018 and is now a rookie mistake.
Archetype 2: Transactional / workflow-heavy
Your product is mostly about users creating things, organising things, and sharing them with teammates. Project management tools, CRMs, internal tools, booking systems, billing platforms, invoicing apps.
The dominant constraint: lots of forms, lots of database operations, lots of admin functionality, lots of role-based permissions.
Pick: Laravel + MySQL on Render or DigitalOcean App Platform. Battle-tested patterns for the boring parts (auth, admin panels with Filament, queues, scheduling, email). The Laravel ecosystem has every common need solved 10 different ways. You'll move fast.
Rails works equally well for this archetype. Pick whichever you can hire for in your market. Don't pick Django unless you have a specific reason — the ecosystem is smaller, the patterns less unified, and you'll feel it in month 6.
What to avoid: Node + Express + Postgres + custom-everything. You'll be reimplementing things Laravel ships with for free, and you'll still be doing it in V2 when you should be shipping features.
Archetype 3: Real-time / event-driven
Your product is about live updates, live data, live collaboration. Chat apps, multiplayer tools, live dashboards, IoT bridges, streaming products, anything with WebSockets at the centre.
The dominant constraint: persistent connections, low-latency message delivery, horizontal scaling for connection counts.
Pick: Node (Express or Fastify) + Postgres on Fly.io, or Phoenix LiveView (Elixir) on Fly.io if you have access to Elixir talent. Fly.io specifically because their architecture is built for low-latency global deployments — the WebSocket use case is in their DNA.
Phoenix LiveView is the technically superior choice for real-time, but only pick it if you're confident you can hire Elixir developers. Most markets can't.
What to avoid: trying to bolt real-time onto Laravel or Rails with Pusher or Ably as an afterthought. It works, but you'll outgrow it. If real-time is core, pick a real-time-native stack.
Archetype 4: E-commerce
You're selling physical or digital products with a checkout, inventory, shipping, taxes, returns, customer accounts.
The dominant constraint: don't reinvent commerce. The platform decisions made by Shopify, WooCommerce, BigCommerce, and Medusa already encode 15+ years of commerce-specific learnings.
Pick: Shopify (yes, even for "custom" needs), or Medusa.js if you genuinely need open-source flexibility that Shopify can't deliver.
What to avoid: building e-commerce from scratch in Laravel, Rails, or Next.js. Founders consistently underestimate the depth of commerce: tax calculation, shipping zones, returns flows, abandoned carts, inventory edge cases, fraud, payment retries. The custom stack will need 18 months of work to match what Shopify does in week one. Don't.
The exception: if your product is not commerce but has a small commerce component (like a SaaS that takes monthly payments), use Stripe + your main stack. Stripe handles the commerce; your stack handles everything else. Don't add e-commerce as a feature unless commerce is the product.
The constraints that override archetype defaults
Once you've picked your archetype's default stack, four constraints can shift the recommendation:
Constraint 1: who will work on this in 12 months?
The single most important variable in long-term stack maintenance.
If you're hiring locally in a small market (Adelaide, Manchester, Boston suburbs), check the local market depth for each stack. PHP/Laravel and JavaScript/Node have the deepest pools. Rails has narrower pools but consistently strong talent. Python/Django has strong pools in data-heavy markets.
If you're hiring globally (offshore or remote), all major stacks have deep talent pools — but the senior tier of Laravel and Node is unusually deep in Eastern Europe, Latin America, and Southeast Asia. Rails senior tier is more concentrated in North America. This affects pricing and availability for senior hires.
If you're flying solo for the next 2 years, pick the stack you'll personally be most productive in, regardless of market depth. You'll cross the hiring bridge later.
Constraint 2: deploy and ops capacity
Some stacks have boring, paid-hosting deploy stories. Some require real DevOps work.
Boring deploys (just git push): Vercel for Next.js, Render or Heroku or Railway for Laravel/Rails/Node, Fly.io for everything. These add $20–200/month to your costs but eliminate weekend ops time.
Requires DevOps: bare AWS, bare Google Cloud, self-hosted Kubernetes. These look cheaper on paper and cost dramatically more in time. Skip until you're at meaningful scale and have full-time DevOps.
The instinct to "save money on hosting" by self-hosting is one of the most expensive mistakes early founders make. Your time is worth more than the $50–200/month a managed platform charges.
Constraint 3: founder-facing tooling
How easy is it for you (the non-technical founder) to look at the database, see what's happening, change a config, run a one-off task?
Strong founder tooling: Laravel-Filament, Django Admin, Rails ActiveAdmin, Forest Admin (works on most stacks). You can browse data, edit records, run common actions.
Weak founder tooling: Next.js + Prisma. You'll need to learn SQL or hire a developer for every "can you check the database for X" question.
If you'll be in the admin daily, this matters a lot. If you've got an EA who'll handle it, less so.
Constraint 4: what's your time-to-first-customer?
Some stacks ship faster than others for a given developer. The ranking, roughly:
- No-code (Bubble, Softr, Glide) — ship in days
- Laravel-Filament or Rails with default scaffolding — ship in weeks
- Next.js + Supabase — ship in weeks (slightly slower than #2 because UI work is hand-rolled)
- Bare Node + Postgres — ship in months (you're building defaults that other stacks ship with)
- Custom microservices in Go or Rust — ship in quarters (and you've made an architectural mistake)
If your timeline is "I need a paying customer in 3 months," the stack matters less than picking from the top of this list.
The fashion-versus-function table
Stacks that are fashionable in 2026 vs stacks that are functional. The overlap is partial.
| Stack | Fashion | Function | When to pick | |---|---|---|---| | Next.js + Supabase | High | High | Content-heavy, SEO-driven products | | Laravel + MySQL | Low | Very high | Transactional, workflow-heavy products | | Rails + Postgres | Medium | Very high | Same as Laravel; pick by hiring market | | Phoenix LiveView | High | High | Real-time products with Elixir talent access | | Bun + Hono | Very high | Unproven | Don't pick this for production yet | | Astro + content collections | High | High | Marketing-only sites, content-heavy with simple interactions | | Django + DRF | Medium | High | Data-heavy products, products with ML components | | Remix | Medium | High | Same niche as Next.js; pick by team preference | | Svelte/SvelteKit | High | Medium | Smaller team productivity, growing ecosystem | | Nuxt 3 | Medium | High | Same niche as Next.js for Vue-preferring teams | | Bare Node + Express | Low | Medium | Don't pick this for greenfield SaaS in 2026 | | Go + bare HTTP | Low | High (specific cases) | High-throughput infrastructure, not user-facing apps | | Rust + Actix or Axum | High | Medium (overkill) | Don't pick this for SaaS unless you need it specifically |
The pattern: fashionable stacks aren't usually wrong, they're just often premature for a small team. Stable stacks (Laravel, Rails, mature Next.js) ship product. Cutting-edge stacks ship technical content for the founder's blog while the product slips.
My actual recommendation, by founder situation
If I were starting a SaaS today as a solo founder, here's what I'd pick by situation:
Solo non-technical founder, $15k budget, 8-week timeline: Bubble or Softr first to validate. If validated, hire a developer for Laravel-Filament + MySQL on Render.
Technical founder who can ship code, content-heavy product: Next.js + Postgres + Supabase on Vercel. Build it yourself.
Technical founder, transactional product: Rails or Laravel — whichever you know better. Don't switch frameworks for the project.
Bootstrapped team of 2–3, ambitious feature set: Laravel-Filament for the admin/operations side, Next.js for the public-facing side, both on Render or Fly. Two stacks done well beats one stack stretched thin.
VC-backed startup with $250k+ engineering budget: any of the above. The stack matters less when you have engineers to throw at problems. Pick what you can hire for fastest.
E-commerce of any kind: Shopify. Stop reading this article and go set up Shopify.
What about AI-first stacks?
The 2026 question I keep getting: "should I build my SaaS on top of an LLM API?" The answer depends on what your SaaS does.
If your product's core value is AI generation (writing tools, image tools, chat tools, summarisation), then yes — your stack now includes an LLM provider (OpenAI, Anthropic, Mistral, or whichever) and possibly a vector database (Pinecone, Weaviate, Postgres+pgvector). Otherwise everything else above still applies.
If your product happens to use AI for some features but isn't primarily an AI product, treat the LLM as a third-party API like Stripe or SendGrid. Don't restructure your whole stack around it. Use OpenAI or Anthropic SDKs in your existing Laravel/Rails/Next.js codebase.
Don't fall for "you must rebuild on an AI-native stack." Most "AI-native stacks" are repackaged Next.js + Vercel functions + an LLM API key. Your existing stack can do that.
What to do next
Once you've picked the stack, the next decisions are scope (how big is V1) and team (who builds it). The companion articles cover both:
- The Three Meanings of MVP — and Which One You Actually Need
- Hourly vs Fixed-Price vs Retainer: Which Pricing Model for Your Build?
If you'd like to talk about a specific build and what stack would suit you, the first call is free — see Full-Stack for Bootstrappers or Full-Stack for SaaS Startups.
---
Part of the Full-Stack Development for Solo Founders pillar guide.