Every few months someone posts a “what stack should I use for my SaaS?” thread and the replies devolve into a holy war. Having shipped a few small products and helped others pick theirs, I’ve come to believe the question is almost always the wrong one. The right question is: what does your team already know, and what will let you validate in four to six weeks?
That said, 2026 has a clearer landscape than 2021 did. The churn has slowed. Some choices have become obvious defaults, and I’ll walk through the ones I’d actually make if starting fresh today.
Frontend: stick with React unless you have a strong reason not to
The ecosystem around React is massive – Next.js, Remix, TanStack Router, a dozen UI component libraries, and more hiring options than any other framework. For a small SaaS, that hiring optionality matters even at day one, because you’re eventually going to hand something off or bring someone in.
Next.js 14+ with the App Router is my default. Server Components cut the amount of client-side JS you ship, which matters for perceived performance and Core Web Vitals. The file-based routing is predictable enough for a solo founder to maintain. If your app is highly interactive and server rendering buys you nothing, Remix is worth a look – its form handling model is genuinely good for CRUD-heavy dashboards.
For styling I’d pick Tailwind CSS with a headless component library like Radix UI or shadcn/ui. You get accessible primitives without fighting a design system someone else built. The component catalogue at ui.shadcn.com is worth bookmarking.
Backend: the boring stack wins
If your team writes TypeScript, a Node backend with Fastify or Express keeps the language consistent and reduces context switching. Fastify’s schema-based validation with JSON Schema is underrated – it documents your API while it validates it.
import Fastify from 'fastify'
const app = Fastify({ logger: true })
app.get('/health', async (req, reply) => {
return { status: 'ok' }
})
app.listen({ port: 3001, host: '0.0.0.0' })If you’re coming from Python, Django REST Framework is still a strong choice – it has the widest library support for things like background tasks, auth, and admin interfaces. FastAPI is faster and has better type hints, but the ecosystem around DRF (especially for auth and multi-tenancy) is deeper.
Go is worth considering if you expect high concurrency early or if you’re building something infrastructure-adjacent. The standard library covers a lot without dependencies, and deployment is a single binary. The tradeoff is slower initial development velocity.
Database: Postgres, almost always
Postgres is the right default for the vast majority of SaaS applications. It handles relational data, JSONB columns for semi-structured fields, full-text search, and with pgvector it now handles vector embeddings too. You can run it managed on AWS RDS, Neon, Supabase, or Railway. The operational knowledge is widely available.
The only time I’d reach for something else immediately is if the data model is fundamentally graph-shaped (consider Neo4j) or if you’re building a time-series product from the start (TimescaleDB or ClickHouse). For everything else, start Postgres and migrate later if you hit a genuine ceiling.
Use an ORM or query builder – raw SQL in application code without some abstraction becomes a maintenance problem. Prisma is popular in the TypeScript world and its migration tooling is solid. SQLAlchemy is the Python equivalent. Both generate the schema from your code and keep migrations version-controlled.
Auth: don’t build it yourself
Auth is one of the few areas where “buy vs. build” has a clear answer for a small SaaS: buy it. The edge cases in authentication – session fixation, CSRF, token rotation, magic links, SAML for enterprise customers – are genuinely hard to get right and not where you want to spend two sprints.
Clerk, Auth0, and Supabase Auth are all workable. Clerk has the best developer experience for Next.js specifically. Auth0 is better if you need SAML/SCIM for enterprise from day one. If you’re already on Supabase for the database, their auth is fine and saves you an integration.
Hosting and infrastructure
For the early stage, managed hosting beats infrastructure-as-code. Railway, Render, and Fly.io all let you deploy a Docker container with a database and get a working URL in an hour. Save Terraform and ECS for when you have actual scale reasons to invest in them.
Object storage is S3 or a compatible alternative (Cloudflare R2 is cheaper for egress-heavy use cases). CDN is Cloudflare – free tier is sufficient for most small SaaS apps.
The stack I’d actually use today
If I were starting a B2B SaaS solo or with one other person in 2026, I’d use: Next.js + Tailwind + shadcn/ui on the frontend, Fastify with TypeScript on the backend, Postgres via Neon for the database, Prisma for ORM, Clerk for auth, and Fly.io or Railway for hosting. This stack lets two people move fast, has good hiring options when the team grows, and avoids building infrastructure that doesn’t differentiate the product.
The one thing I’d add that’s newer: budget time for observability from day one. A structured logger, error tracking like Sentry, and basic uptime monitoring cost almost nothing and save hours of debugging production issues blindly. More on that in a separate post.
The official Next.js docs are worth reading cover to cover once: nextjs.org/docs. And the Fastify documentation is unusually good for a Node framework: fastify.dev/docs.