For most SaaS products in 2026, the best tech stack is a deliberately boring one: TypeScript, React and Next.js for the web app, PostgreSQL from a managed host, an auth library or provider, billing chosen by where you sell, a proper email service, and hosting next to the database. Add React Native or Flutter only when a phone app is due. Call AI models from the server, behind one function you can swap.
I'm not neutral, so here's my bias up front: I build in TypeScript, React and Next.js, and in React Native or Flutter for phones. This is the method behind my MVP development for startups, written so you can use it with any team.
It's for founders and product leads about to start a SaaS build or brief someone who will. If your team already ships a stack well, keep it. Once it's live, improving INP in Next.js is the speed work I do first.
The best tech stack for SaaS, layer by layer
A stack is seven decisions, and they don't cost the same to get wrong. Moving a live product to another database is a project; swapping an email provider isn't. So I think hardest where change is expensive.
On the free 30 minute intro call, I ask six questions before I name a single tool:
- Who maintains this after I hand it over, and what do they already write?
- Where are your first customers, and must their data stay in one region?
- Will you sell to companies that expect single sign-on?
- Are you selling self-serve plans in many countries?
- Is a phone app due in the next twelve months?
- Will an AI model see customer data?
The answers choose most of the stack.
Front end: React and Next.js, and when something else is fine
The current releases are Next.js 16.4, out on 6 October 2026, and React 19.3, out on 9 September 2026. A SaaS usually needs a signed-in app, server code near the data and indexed public pages; Next.js does all three in one TypeScript codebase.
The stronger argument is hiring. In the 2026 Stack Overflow Developer Survey, 41.5% of the 10,281 people who answered the web framework question had done extensive work in React and 20.6% in Next.js; TypeScript was at 43.8% of 14,099 on the languages question.
The counterweight: the State of JavaScript 2025 meta-framework results say Next.js keeps gaining ground while losing satisfaction. Among 2,110 answers on pain points, 241 named Next.js, second only to "excessive complexity" at 303. I recognise it: server and client components, caching rules, a rendering model that kept moving through 16.x. So a screen uses a framework feature only when it needs one.
When is something else fine?
- The app sits wholly behind a login. A React single-page app built with Vite is simpler to host and reason about.
- Your team already ships Rails, Laravel or Django. Keep it. A team that knows its tools beats my preference.
- The heavy lifting is Python machine learning. Put a Python API such as FastAPI behind a React front end; FastAPI rose from 14.8% to 18.5% in the survey between 2025 and 2026.
- It's the marketing site. It needn't share the app's stack at all.
Front-end quality depends less on the framework than on code matching the design. That discipline is most of how I build SaaS web apps in Next.js, and the steps are in how I take a Figma file to Next.js.
Mobile: React Native or Flutter
First ask whether version one needs an app at all. For most SaaS products a responsive web app proves the job.
When it's due, both options are mature. React Native 0.87 shipped on 11 August 2026, and its docs now recommend starting new apps with a framework, naming Expo. Flutter 3.47 shipped a day later.
| Question | Leans React Native | Leans Flutter |
|---|---|---|
| Sharing code with a Next.js web app? | Yes: same language, same React | Little beyond API contracts |
| Identical screens on every phone? | Uses each platform's own views | Draws its own pixels |
| What does your team write? | TypeScript or JavaScript | Dart |
The language pool is lopsided: in the 2026 survey, 62.0% had used JavaScript and 43.8% TypeScript, against 4.9% for Dart. Flutter's web FAQ also says it doesn't suit text-rich static sites, so a Flutter app usually sits beside a separate website. I compared the two SDK by SDK in Flutter vs React Native for Arabic apps.
Back end and database: why PostgreSQL is my default
The database outlives every other choice: front ends get redesigned, but your customers' tables stay for years. Why PostgreSQL:
- SaaS data is relational. Accounts own users, users hold roles, plans produce invoices; foreign keys and transactions keep that consistent.
- Tenant isolation in the database. Row security policies restrict which rows a user can see or change. I treat them as a second wall behind the checks in code.
- Flexible parts without a second database. The `jsonb` type holds settings and payloads, and pgvector stores embeddings for AI search beside the data.
- Portability. Every major host runs it, so leaving a host means moving data, not rewriting queries.
In the same survey, PostgreSQL was the most used database, at 57.9% of 12,061 respondents, and the most admired, at 62.3%. The survey's time series runs from 32.9% in 2018, when MySQL led with 58.7%, to 43.6% against 46.9% in 2022, and 57.9% against 35.1% in 2026. Answer options shift a little each year, so read it as a trend.
Check versions on day one. The PostgreSQL versioning page lists 18 as current (18.6), supported until 14 November 2030, with 5 years of support per major version. PostgreSQL 19 reached its fourth beta on 24 September 2026, and 14 stops receiving fixes on 12 November 2026. Start new products on 18.
Where to run it is a question of fit:
| Option | What it suits | What to watch |
|---|---|---|
| Supabase | Small teams wanting auth, storage and realtime on a full Postgres database | Its auth and policies tie you closer to it |
| Neon | Teams wanting a copy-on-write database branch per preview | Region choice against your customers |
| Your cloud's managed Postgres | Companies already in AWS, Google Cloud or Azure | More set-up falls to you |
| Cloudflare D1 | Read-heavy content with SQLite semantics | It isn't Postgres |
The site you're reading runs Next.js on Cloudflare Workers through OpenNext, with its posts in D1: one writer, mostly reads, no tenants. A SaaS holding customer data gets Postgres.
For server logic, I start inside Next.js. Its authentication guide says to treat Server Actions like public API endpoints, and I check every one that way. A separate back-end service waits until a second client or heavy background jobs need it.
Auth: use a library or a provider, and own the user table
Sign-in looks small and isn't. The same Next.js guide, updated 16 September 2026, recommends an authentication library over a custom build and lists a dozen. Each suits a different buyer:
- [Clerk](https://clerk.com/docs/guides/organizations/overview): B2B products wanting prebuilt sign-in and organisations (teams with members and roles).
- [WorkOS](https://workos.com/docs/sso): products sold to larger companies whose IT teams require SAML single sign-on.
- [Supabase Auth](https://supabase.com/docs/guides/auth): products already on Supabase, working with the same database and row policies.
- [Better Auth](https://www.better-auth.com/docs/introduction): teams wanting an open-source TypeScript framework inside their own app, on their own database; the Auth.js project is now part of it.
Whatever you pick, your own user and organisation IDs live in your Postgres tables, and the provider's ID appears in one place only. Then changing provider is a migration of one table, not every table.
Payments and email: where money and trust leak
Payments. The first decision is who the seller is. With a processor such as Stripe Billing (subscriptions, invoicing, usage-based billing), your company is the seller, so sales tax and VAT registrations are your job. A merchant of record resells your product and takes that on: Paddle describes itself as one for SaaS, and Stripe's Managed Payments handles sales tax, VAT and GST in more than 80 countries for digital products.
A processor fits invoiced B2B in a few countries and custom contracts; a merchant of record fits a small team selling self-serve plans worldwide. Check eligibility lists first. Either way, I read payment status from the provider's webhook, never from the thank-you page. For an MVP, start on hosted checkout pages, as in how to scope an MVP before you build.
Email. Password resets have to arrive. Gmail's sender guidelines, in force since 1 February 2024, ask every sender for SPF or DKIM and a spam rate below 0.3%. Above 5,000 messages a day to Gmail, you need SPF, DKIM and DMARC, and marketing mail needs one-click unsubscribe. I keep product email apart from newsletters, as Postmark's separate transactional and broadcast streams do, so a bad campaign can't sink a reset email.
Hosting and edge: put the code next to the data
Much of a SaaS's speed comes down to one distance: server code to database. Vercel's function region docs say new projects run functions in Washington, D.C. (iad1) by default and advise placing them near your data source. Database in Frankfurt? Move the functions there.
Hosting is now the easiest layer to change. Next.js 16.2 made its Adapter API stable, announced on 25 March 2026 and built with OpenNext, Netlify, Cloudflare, AWS Amplify and Google Cloud; Vercel's own adapter uses the same contract. I host on Vercel, Cloudflare or your cloud, with accounts in your company's name.
Then there's patching. On 8 October 2026 the Next.js team announced an out-of-band security update for 14 October, fixing two critical and one high-severity flaw in upstream dependencies. Whoever looks after the app must ship that within days, so write it into the handover plan.
Analytics and AI APIs: rent them, wrap them
Analytics. Product analytics, such as PostHog, shows how people use the product: who adopted a feature, who came back. You need it from launch, with a handful of named events in the scope so the build includes them.
AI APIs. On the 2026 survey's LLM question, 74.6% of 11,895 respondents had used Anthropic models for work, 74.3% OpenAI and 54.5% Google: shares well over 100% combined, so people mix. Assume you will too. I call models only from the server, one function per task, with the model name in configuration; the AI SDK, for example, standardises calls across providers. I log model, tokens and time per call to Postgres, so switching is a settings change and a test run. If customer data reaches a model, say so in the scope and check the provider's data terms.
What to avoid deciding too early
Most stack regret comes from building for scale that never came. These can wait for a measured problem:
| Decision | Why it can wait | The signal to decide |
|---|---|---|
| Microservices | One app and one database go a long way | A part needs its own scaling or team |
| Multi-region database | One region near first customers is enough | Far-away users report slow pages; a residency law makes it day one |
| A separate vector database | pgvector keeps embeddings next to the data | Measured search speed or volume problems |
| Native Swift and Kotlin apps | Cross-platform covers most products | A platform feature the framework can't reach |
A decision table by stage
Each stage needs a different amount of stack:
| Layer | Prototype | MVP | First 1,000 customers | Scale |
|---|---|---|---|---|
| Front end | Clickable Figma prototype | Next.js on a small component library | Tests on sign-in and billing | Same codebase, split by team |
| Mobile | None | Responsive web | React Native or Flutter if asked | Native modules where needed |
| Database | Sample data | Managed PostgreSQL 18, one region | Restores tested, slow queries fixed | Read replicas, a warehouse |
| Auth | A fake user | Library or provider | Organisations, roles, multi-factor | SAML for enterprise deals |
| Payments | None | Hosted checkout and portal | Processor or merchant of record settled | Usage plans, invoicing |
| None | Transactional provider, SPF, DKIM, DMARC | Marketing on its own stream | Spam rate monitored | |
| Hosting | Preview links | One region by the database | Error alerts, a patch routine | Regions where customers are |
| AI | A playground prompt | One server function, one provider | Logging, cost limits, failure states | A second provider, quality tests |
Where I would start
Answer the six questions in writing. Name the three expensive layers with one reason each, then pick the rented services by fit. That page goes into the scope, so nobody reopens it in sprint four.
If you'd like me to design and build on it, bring that page to a free intro call about my design and build work for SaaS founders, or read how I work first. A written scope and one fixed quote follow, with the repository and accounts in your name.
Frequently asked questions
What is the best tech stack for a SaaS startup in 2026?
For most: TypeScript, React and Next.js, managed PostgreSQL, an auth library or provider, a processor or merchant of record for billing, a transactional email service, and hosting in the database's region. Add React Native or Flutter when a phone app is due. If your team already ships another stack well, keep it.
Is Next.js good for SaaS?
Yes, when the product needs sign-in, server logic and indexed pages in one TypeScript codebase, and its wide use helps hiring. It is also complex: in State of JS 2025 it was the most named pain point after complexity itself. For an app wholly behind a login, a React single-page app can be simpler.
Should I use PostgreSQL or MongoDB for a SaaS?
I default to PostgreSQL because SaaS data is relational: accounts, users, roles, plans and invoices. It also offers row security, jsonb for flexible fields and pgvector for embeddings. MongoDB suits data that is genuinely document-shaped. In the 2026 Stack Overflow survey, 57.9% of database respondents used PostgreSQL and 19.0% MongoDB.
Should I build my own authentication?
No. The Next.js docs recommend an authentication library over a custom build. Sessions, resets, verification, multi-factor and single sign-on take far longer to get right than they look. Pick a library or provider by your buyer (self-serve users, B2B teams, enterprises needing SAML) and keep your own user IDs.
Do I need a mobile app for my SaaS MVP?
Usually not. A responsive web app proves the core job for most SaaS products, and one codebase is cheaper to change while you learn. Build a phone app when users need it away from a desk, offline or with the camera, then choose React Native or Flutter by your team's language.
Should I use Stripe or a merchant of record like Paddle?
It depends on who should be the seller. With Stripe Billing as your processor, your company sells and handles sales tax and VAT registrations. A merchant of record, such as Paddle or Stripe Managed Payments, resells your product and takes on that tax work. Invoiced B2B suits a processor; self-serve plans sold worldwide suit a merchant of record.
Sources and method
I read every source on 13 October 2026. Survey figures cover all respondents to each question; options change yearly, so I compare trends. Vendor descriptions follow their own docs; I rank none. The stage table and cost ratings are my judgement, not measured data.
- Stack Overflow, Developer Survey 2026, technology data and methodology (30,903 responses, fielded 23 June to 5 August 2026), date read 13 October 2026: survey.stackoverflow.co, survey.stackoverflow.co
- Devographics, State of JavaScript 2025, meta-frameworks, date read 13 October 2026: 2025.stateofjs.com
- Vercel, Next.js blog: 16.4, Adapter API, security update notice, date read 13 October 2026: nextjs.org, nextjs.org, nextjs.org
- Vercel, Next.js authentication guide, function regions and AI SDK docs, date read 13 October 2026: nextjs.org, vercel.com, ai-sdk.dev
- React, versions page, date read 13 October 2026: react.dev
- Meta, React Native 0.87 release and set-up docs, date read 13 October 2026: reactnative.dev, reactnative.dev
- Google, Flutter what's new and web FAQ, date read 13 October 2026: docs.flutter.dev, docs.flutter.dev
- PostgreSQL Global Development Group, versioning, 19 Beta 4, row security and JSON docs, date read 13 October 2026: postgresql.org, postgresql.org, postgresql.org, postgresql.org
- pgvector, vector extension for Postgres, date read 13 October 2026: github.com
- Supabase, database and Auth docs, date read 13 October 2026: supabase.com, supabase.com
- Neon, branching docs, date read 13 October 2026: neon.com
- Cloudflare, D1 docs, date read 13 October 2026: developers.cloudflare.com
- Clerk and WorkOS, Organizations and SSO docs, date read 13 October 2026: clerk.com, workos.com
- Better Auth, introduction, and Auth.js home, date read 13 October 2026: better-auth.com, authjs.dev
- Stripe, Billing and Managed Payments docs, date read 13 October 2026: docs.stripe.com, docs.stripe.com
- Paddle, What is Paddle, date read 13 October 2026: developer.paddle.com
- Google, Gmail email sender guidelines, date read 13 October 2026: support.google.com
- Postmark, message streams, date read 13 October 2026: postmarkapp.com
- PostHog, product analytics docs, date read 13 October 2026: posthog.com
Tags: Tech stack, SaaS, Next.js, PostgreSQL, Startups
