A new SaaS project rarely starts with the thing that makes it interesting.

You open your editor because you have a product idea. Maybe it's a workflow tool, a niche CRM, an AI product, a developer utility, or a small internal tool you're turning into a business.

Then the setup begins.

Create the Next.js app. Configure TypeScript. Add the database. Set up authentication. Build a login page. Add OAuth. Figure out sessions. Add email verification. Set up transactional email. Work out password resets.

Then payments.

Then webhooks.

Then file uploads.

Then analytics.

Then error monitoring.

Then deployment.

A week later, you have a well-structured application with a polished authentication flow, billing infrastructure, analytics events, and absolutely no interesting product.

The tools for doing all of this have never been better. Yet developers keep rebuilding roughly the same foundation for every SaaS they start.

That raises a more useful question than "What's the best SaaS stack?"

Which parts of a SaaS should you build yourself, and which parts should you reuse?

That is the question this stack is really about.

The short answer

There isn't one correct SaaS architecture. A company with millions of users, a bootstrapped B2B product, and a weekend MVP have very different constraints.

For a typical web SaaS in 2026, though, a sensible baseline looks something like this:

This is an opinionated baseline, not a prescription.

You can build an excellent SaaS without half of these products. You can also use completely different technologies and make better decisions for your particular constraints.

The point is to know why each piece exists.

Next.js's App Router is built around React Server Components, Suspense and Server Functions, which makes it a reasonable default for applications that combine a public website, authenticated application, server-side logic and dynamic data in one codebase. ([Next.js][1])

PostgreSQL remains a particularly strong general-purpose choice because it combines relational modeling with features such as JSON types, indexing and extensibility. The project continues to maintain multiple supported releases, with PostgreSQL 18.6 released in August 2026. ([PostgreSQL][2])

The more interesting part, however, is not the list.

It's the reasoning behind it.

1. Framework: Next.js is a strong default, not a requirement

For a modern SaaS, the framework has to do more than render a landing page.

You usually need a marketing site, authentication, dashboards, server-side data access, API endpoints, background operations, webhooks, metadata, forms, and sometimes a public API.

A full-stack framework can keep much of that in one project.

That's where Next.js makes sense.

The App Router provides file-system routing and is designed around React Server Components and other newer React primitives. ([Next.js][1])

For a small team, that matters less because Next.js is fashionable and more because reducing the number of architectural boundaries reduces the number of things you have to operate.

You can have:

app/
  (marketing)/
  (auth)/
  dashboard/
  api/

and keep the application, its UI, server-side logic and route structure close together.

That's useful.

It doesn't mean Next.js is automatically the best choice.

A highly interactive client-heavy application may be perfectly happy with React + Vite and a separate API. A team already standardized on another backend framework may not gain anything by moving to Next.js. A service with unusual runtime requirements might also fit better elsewhere.

The mistake is choosing a framework before deciding what architecture your product actually needs.

For many web SaaS products, though, Next.js is a reasonable starting point because it lets one small team operate a lot of functionality without splitting the application into multiple repositories and deployment systems.

For deployment, Vercel is the obvious path because Next.js is its native framework and deployment is essentially zero-configuration. But Next.js can also be self-hosted, so this is a convenience trade-off rather than a technical requirement. ([Vercel][3])

2. TypeScript: the default is boring for a reason

TypeScript isn't an exciting architectural decision.

That's probably why it works so well.

As a SaaS grows, data moves through a lot of boundaries:

Database
   ↓
Server logic
   ↓
API / Server Action
   ↓
Client
   ↓
Analytics
   ↓
External service

Type errors caught while you're writing code are generally cheaper than discovering the same mismatch through a production bug.

TypeScript adds a type system on top of JavaScript, allowing the compiler to identify classes of unexpected behavior before runtime. ([TypeScript][4])

The real value becomes more obvious when the codebase gets larger.

You change a database model.

The type system tells you which parts of the application are now inconsistent.

You rename a property.

Your editor tells you where the old contract is still being used.

You introduce a billing state.

You can make the valid states explicit instead of passing arbitrary strings around.

This isn't glamorous work. It compounds over time.

3. UI: Tailwind and shadcn/ui are less about components than ownership

Tailwind CSS is useful because it keeps styling close to the component and lets you define your own design tokens instead of accepting a fixed visual language. Its current system is built around theme variables that generate the utility classes available to the project. ([Tailwind CSS][5])

shadcn/ui takes a different approach from conventional component libraries.

Instead of installing an opaque package and importing components forever, its CLI adds component source code directly into your project. You own that code and can modify it. ([Shadcn UI][6])

That distinction matters more than the component catalog.

A SaaS product usually needs to look like its own product.

You don't want your UI architecture to prevent you from changing a button, form, modal or data table six months later because the library's abstractions don't quite fit.

The combination of Tailwind and shadcn/ui gives you a useful middle ground:

Don't design every primitive from scratch, but don't surrender ownership of the UI either.

There are alternatives. Radix-based systems, Material UI, Chakra, Base UI and custom design systems can all be sensible depending on the project.

The important decision is not "which component library is best?"

It's "how much of my UI am I prepared to own?"

4. Authentication is where "simple" products start getting complicated

Authentication looks like a screen.

It isn't.

A production authentication system quickly becomes a collection of edge cases:

• sessions;
• cookies;
• password hashing;
• OAuth callbacks;
• email verification;
• password reset;
• account linking;
• revoked sessions;
• expired tokens;
• suspicious login behavior;
• authorization;
• organization membership.

You can build all of this yourself.

You probably shouldn't.

The problem with custom authentication isn't that a competent developer can't write a login system. They can.

The problem is that authentication has a very poor risk-to-reward ratio for custom engineering.

The interesting software in your SaaS isn't the session cookie.

Mature auth libraries also tend to expose the less obvious parts of the system. Better Auth, for example, supports multiple authentication methods and account linking, and its documentation explicitly deals with the security implications of implicit OAuth linking and provider verification. ([Better Auth][7])

That's the sort of complexity you usually discover after launch rather than during the first afternoon of development.

Build your authorization model.

Build your permissions.

Build the user experience around identity.

Don't spend your product's early development cycles inventing authentication infrastructure.

5. PostgreSQL is still the sensible default

There is a recurring temptation in early SaaS development to pick a database because a particular feature sounds convenient.

That is usually backwards.

Start with the shape of your data.

A SaaS commonly has relationships like:

User
 ├── Projects
 ├── Subscriptions
 ├── Files
 ├── API keys
 └── Activity

Relational databases are very good at this.

PostgreSQL is mature, extensible and designed for complex data workloads. It also gives you the option to mix conventional relational data with more flexible structures such as jsonb when the domain actually calls for it. PostgreSQL's documentation specifically notes that jsonb supports indexing and is generally preferable to plain json for most applications. ([PostgreSQL][2])

That makes PostgreSQL a good default partly because it doesn't force you to predict everything about the product upfront.

You can start relational.

Add indexes when queries require them.

Use JSON where it makes sense.

Add extensions when the problem demands them.

And keep the option of running far beyond the scale of a typical early-stage SaaS.

6. Drizzle vs Prisma: this is mostly a question of preference

ORM arguments tend to become strangely religious.

They don't need to.

Both Drizzle and Prisma give TypeScript developers a way to work with relational databases without hand-writing every database interaction.

The meaningful distinction is how much abstraction you want.

Drizzle has a SQL-oriented style and keeps your schema and queries relatively close to the underlying database concepts. Its documentation also provides relational query APIs on top of that model. ([Drizzle ORM][8])

Prisma leans harder into a schema-driven developer experience with generated, typed access to your data and an increasingly opinionated tooling ecosystem. ([Prisma][9])

For a SaaS starter, I generally prefer the ORM that makes the database easier to inspect and reason about rather than the one that hides the most database details.

That preference can lead you to Drizzle.

It can also lead you to Prisma.

The important part is being able to answer these questions:

• Where is the source of truth for the schema?
• How are migrations generated?
• Can I inspect the SQL?
• Can I recover from a bad migration?
• Can another developer understand the data model without learning a proprietary abstraction first?

The database will outlive several UI frameworks.

Choose an ORM that keeps you close enough to it that you can still make decisions confidently.

7. Payments: Stripe and Polar solve different problems

"Add Stripe" is not a billing strategy.

A real SaaS billing system has to answer more questions:

• What happens when a subscription renews?
• What happens when payment fails?
• Who owns the customer record?
• Where are invoices generated?
• How are cancellations handled?
• How are entitlements updated?
• Who handles sales tax?
• What does the customer portal look like?
• What happens when your webhook arrives late or twice?

Stripe is extremely flexible here.

Its subscription system supports recurring payments, Checkout, customer portals, webhooks and Stripe Tax, among other pieces. ([Stripe Docs][10])

The flexibility is the advantage.

It's also the responsibility.

A Merchant of Record is a different model. The MoR is the entity legally responsible for a transaction, including responsibilities around the sale itself and, depending on the arrangement, taxes, refunds and disputes. ([Stripe Docs][11])

Polar positions itself as a Merchant of Record and states that it assumes liability for international sales tax compliance on sales through its platform. ([Polar][12])

That creates a real trade-off.

For an enterprise product with unusual billing requirements, Stripe's flexibility can be decisive.

For a small software company selling subscriptions globally, reducing tax and billing administration can be worth more than having every possible billing primitive.

Neither is universally better.

8. Email should almost always be somebody else's problem

Transactional email is one of those systems that seems trivial until production finds the edge cases.

You need:

• domain authentication;
• deliverability;
• templates;
• retry behavior;
• bounce handling;
• verification links;
• password resets;
• billing notifications;
• email event tracking.

A service like Resend gives you an API specifically for sending email, plus domain and webhook functionality around it. ([Resend][13])

This is exactly the type of infrastructure I wouldn't build.

There is almost no strategic advantage in owning your own SMTP infrastructure for a small SaaS.

Your users don't care that you wrote the mail queue.

They care that the password-reset email arrives.

9. File storage belongs outside the database

Putting user-uploaded files directly into PostgreSQL is usually a sign that you're making the database responsible for something it wasn't chosen to do.

Store metadata in PostgreSQL.

Store the actual object somewhere designed for objects.

For example:

PostgreSQL
----------------
file_id
user_id
name
mime_type
size
storage_key

Object Storage
----------------
storage_key → actual bytes

Cloudflare R2 is one practical option. It exposes an S3-compatible API, so existing S3 tooling can be reused, and Cloudflare currently advertises no egress fees for R2 storage. ([Cloudflare Docs][14])

As of August 2026, standard R2 storage is listed at $0.015 per GB-month, with request charges for Class A and Class B operations and no egress bandwidth charges. ([Cloudflare Docs][15])

There are plenty of alternatives.

Amazon S3 is the obvious one.

Cloudinary makes more sense for image-heavy products.

Supabase Storage can be convenient when you're already deeply invested in Supabase.

The architectural principle stays the same:

The database stores the record about the file. Object storage stores the file.

10. Analytics and monitoring are not the same thing

This is one of the most common infrastructure mistakes in early SaaS applications.

A product can have excellent analytics and terrible monitoring.

It can also have excellent monitoring and no idea what users are doing.

They answer different questions.

Analytics asks:

What are users doing?

Examples:

signup_started
signup_completed
project_created
checkout_started
subscription_started
feature_used

You use this to understand funnels, retention and behavior.

PostHog's product analytics, for example, is built around events, funnels, retention, paths, lifecycle analysis and related product insights. ([PostHog][16])

Monitoring asks:

What is broken?

Examples:

TypeError
Database timeout
Webhook failure
500 response
Slow server action

That's where something like Sentry belongs.

The distinction sounds obvious, but architecture gets messy when teams treat analytics as a generic logging system.

I want both.

I also want the events to share a sensible vocabulary.

A messy analytics taxonomy becomes technical debt surprisingly quickly.

Define event names intentionally.

Track the events that correspond to actual product decisions, not every click on every div.

11. AI should be an integration layer, not your entire architecture

AI applications encourage a different kind of technical coupling.

A developer picks a model provider, calls its API directly from five places, stores provider-specific configuration in business logic, then discovers three months later that the model is too expensive or unavailable for a particular workload.

Now changing providers means rewriting the application.

That's avoidable.

An abstraction layer doesn't make models interchangeable in some magical sense. Models have different capabilities, quality, pricing, latency and tool-calling behavior.

The point is to isolate the provider-specific part.

The Vercel AI SDK is useful here because its core APIs sit above individual model integrations. It supports functions such as generateText and streamText, with provider and model selection occurring behind the SDK interface. ([AI SDK][17])

A simple architecture is:

Product feature
      ↓
AI service
      ↓
AI SDK
      ↓
Model provider

That also makes experimentation easier.

Use one model for classification.

Another for generation.

A cheaper one for background tasks.

A better one for high-value user requests.

The abstraction doesn't remove the trade-offs. It makes the trade-offs easier to change.

12. i18n is mostly about making a decision early

Not every SaaS needs ten languages.

Many only need one.

That doesn't mean internationalization should always be ignored.

Localization tends to become painful when text is scattered throughout the codebase:

<h1>Welcome back</h1>

becomes:

<h1>{t("welcomeBack")}</h1>

only after hundreds of screens have already been written.

Then formatting dates, pluralization, currency, URLs and metadata gets involved.

Libraries such as next-intl provide localization primitives designed specifically for Next.js, including message handling, formatting and locale-aware routing. ([Next Intl][18])

You don't need to localize the application on day one.

You do want to avoid making localization structurally impossible.

A good compromise is to decide early:

We support one language now, but the application architecture doesn't assume one language forever.

That's usually enough.

13. Deployment should be boring

A deployment system is successful when you stop thinking about it.

That's an underrated property.

For a Next.js SaaS, Vercel is an obvious default because the framework and platform are closely integrated. Vercel describes Next.js deployment there as zero-configuration while also noting that Next.js can be self-hosted. ([Vercel][3])

That doesn't mean Vercel is mandatory.

You may choose:

• AWS;
• Cloudflare;
• Railway;
• Fly.io;
• a VPS;
• Kubernetes;
• Docker on your own infrastructure.

Those decisions become more justified when your requirements demand them.

The mistake is adopting operational complexity because it feels more "serious."

A startup with five hundred users doesn't need a distributed infrastructure architecture designed around the problems of a company with fifty million.

Use the simplest deployment system that satisfies your actual constraints.

You can always make the system more complicated.

You can't easily make an organization forget a process it has already built around.

14. What should you actually build yourself?

This is the part that matters more than the technology list.

A useful distinction is between product infrastructure and product differentiation.

Build these

Core product logic

The thing that solves the user's problem.

Domain-specific workflows

The steps, rules and interactions that make your product different from a generic CRUD application.

User experience

The places where customers feel the quality of your software.

Your internal business rules

Pricing logic, permissions, workflow states and whatever makes the product yours.

Reuse these

Authentication

Unless identity itself is your product.

Payment infrastructure

Unless you're building billing software.

Email delivery

Unless you're building email infrastructure.

Object storage

Unless you're building storage infrastructure.

Analytics

Unless analytics is the product.

Error monitoring

Unless observability is the product.

There's an obvious principle underneath this:

Infrastructure should support the product, not become the product.

Of course there are exceptions.

A security company may need custom authentication.

A developer platform may need to build its own storage layer.

A fintech may have reasons to control pieces of its payments architecture.

The decision isn't "never build infrastructure."

The decision is:

Are we building this because it's strategically important, or because nobody has connected it yet?

Those are very different reasons.

15. From scratch vs boilerplate vs SaaS starter

There are three common ways to approach a new SaaS foundation.

Build everything from scratch

You choose every dependency, every folder, every integration and every convention.

The upside is control.

The downside is that your first milestone often becomes "finish the foundation."

This approach is excellent when the architecture itself is part of the problem you're trying to solve.

It's less attractive when the product is already clear and infrastructure isn't your competitive advantage.

Best for

Teams with unusual requirements, strong architectural preferences, or products where infrastructure is itself strategically important.

Use generic boilerplate

A boilerplate gives you a head start.

You might get authentication, a dashboard, a database and some components.

The problem is that many boilerplates solve the first 20 percent and leave you with the hardest architectural decisions.

You still have to understand how everything is connected.

Sometimes the code is so generic that replacing one piece creates more work than starting clean would have.

Best for

Developers who want a head start but still expect to reshape the architecture significantly.

Use a production-oriented SaaS starter

A more opinionated starter tries to solve not just the first screen, but the boring infrastructure around the first real product.

That can include:

Auth
Database
Billing
Email
Storage
Analytics
Monitoring
AI
i18n
Deployment

The advantage is not simply that some files already exist.

It's that somebody has already made the decisions between them.

That's a different type of leverage.

You're inheriting architecture, which means you're also inheriting assumptions.

That is the price.

A starter that makes a decision you disagree with can be worse than a blank repository.

So the quality of a SaaS starter shouldn't be measured only by how much code it contains.

It should be measured by how easy it is to understand, replace and extend.

16. How much time does all this infrastructure actually take?

This is where SaaS starter discussions often become dishonest.

Claims like "this saves you 40 hours" sound impressive, but they're difficult to defend.

A competent developer can connect a database quickly.

They can add Google OAuth quickly.

They can integrate Stripe quickly.

They can send an email quickly.

The problem is that production work isn't the first successful API call.

The real work looks more like this:

Integration
  ↓
Configuration
  ↓
Environment variables
  ↓
Error handling
  ↓
Webhooks
  ↓
Retries
  ↓
Edge cases
  ↓
Testing
  ↓
Production deployment
  ↓
Documentation
  ↓
Maintenance

Authentication works until password reset doesn't.

Billing works until a webhook is delivered twice.

Email works until the sending domain isn't configured correctly.

Uploads work until someone sends a 2 GB file.

Analytics works until event names become inconsistent.

That is where the time goes.

And even that isn't the whole value of a starter.

There is also the cost of repeated decisions.

Every new project asks some version of:

• Where should auth live?
• How should sessions work?
• Where do billing entitlements come from?
• How should webhooks be structured?
• Where do uploaded files go?
• How are environment variables organized?
• How does analytics get initialized?
• What is the folder structure?
• Which patterns do server and client code follow?

The value of a good foundation is partly that those decisions have already been made once.

You can still change them.

You just don't have to make them at 2 a.m. for the seventh time.

17. The stack behind Motoko Base

I kept running into this problem myself.

Every new SaaS project seemed to start with the same checklist.

I wasn't interested in making a giant template full of every possible feature. I wanted a foundation that handled the infrastructure I found myself rebuilding, while leaving the actual product architecture open.

That's what became Motoko Base.

The stack is intentionally opinionated:

Next.js
TypeScript
Tailwind CSS
shadcn/ui

Better Auth
PostgreSQL
Drizzle

Polar
Resend
Cloudflare R2

PostHog
Sentry

Vercel AI SDK
i18n

There is nothing uniquely magical about these choices.

That's the point.

They are ordinary technologies assembled into one coherent starting point.

The authentication layer should work with the database.

Billing should expose clear entitlements to the application.

Webhook handling should be treated as infrastructure, not scattered through product code.

Files should go to object storage.

Analytics and monitoring should be distinct.

AI integrations should be isolated from provider-specific code.

The goal is not to make every SaaS identical.

It is to remove the part where every developer spends the first few days rebuilding the same foundation.

Motoko Base is one implementation of that philosophy.

18. The bigger idea is composability

A fixed starter only solves part of the problem.

Because there isn't one universally correct stack.

You might want:

Stripe instead of Polar
Prisma instead of Drizzle
S3 instead of R2
Clerk instead of Better Auth
No AI at all
Two languages instead of one

That's perfectly reasonable.

The longer-term direction I'm interested in is therefore less about creating one "perfect" starter and more about making the foundation composable.

Instead of:

Download this stack and accept every decision.

The better model is closer to:

Choose the pieces you need, and generate a project around those choices.

That naturally leads toward a CLI-based workflow.

The important abstraction isn't the CLI itself.

It's the idea that infrastructure should be modular.

A developer should be able to say:

Next.js
PostgreSQL
Drizzle
Better Auth
Stripe
R2
PostHog

and get a coherent project rather than manually wiring eight unrelated integrations together.

That is where SaaS starters become more interesting.

Not as giant repositories full of code, but as a way to package proven architectural decisions.

19. The real 2026 SaaS stack is smaller than it looks

One useful side effect of thinking in layers is realizing how little of the stack is actually yours.

A typical SaaS might contain fifteen technologies, but only a handful of them are where the company's engineering advantage lives.

Something like:

Your code
├── Domain logic
├── Product workflows
├── UX
└── Business rules

Managed infrastructure
├── Auth
├── Database
├── Billing
├── Email
├── Storage
├── Analytics
├── Monitoring
└── AI providers

That isn't a weakness.

It's normal software engineering.

Modern SaaS development is mostly composition.

The skill is not knowing how to rebuild every layer.

The skill is knowing where composition ends and differentiation begins.

20. A practical SaaS launch checklist

Before spending serious time on product features, I want the foundation to answer these questions.

Application

• [ ] Framework selected
• [ ] TypeScript configured
• [ ] Project structure agreed on
• [ ] UI system established

Data

• [ ] PostgreSQL configured
• [ ] ORM selected
• [ ] Migrations working
• [ ] Backups understood

Authentication

• [ ] Sessions working
• [ ] OAuth configured if needed
• [ ] Email verification decided
• [ ] Password reset working
• [ ] Authorization model defined
• [ ] Account linking behavior understood

Billing

• [ ] Billing provider selected
• [ ] Plans defined
• [ ] Entitlements defined
• [ ] Checkout working
• [ ] Customer portal available
• [ ] Webhooks verified
• [ ] Failed payments handled
• [ ] Tax strategy understood

Email

• [ ] Sending domain configured
• [ ] Transactional email provider connected
• [ ] Verification email working
• [ ] Password reset email working

Storage

• [ ] Object storage configured if needed
• [ ] Upload limits defined
• [ ] Access control defined
• [ ] Database metadata separated from file contents

Product analytics

• [ ] Analytics provider configured
• [ ] Core events defined
• [ ] Signup funnel tracked
• [ ] Activation event tracked
• [ ] Billing events tracked

Monitoring

• [ ] Error monitoring configured
• [ ] Production alerts configured
• [ ] Server-side errors captured
• [ ] Critical webhook failures visible

AI

• [ ] Model providers selected
• [ ] Provider integration isolated
• [ ] Token/cost tracking considered
• [ ] Failure behavior defined

Localization

• [ ] Language strategy decided
• [ ] User-facing strings structured for translation
• [ ] Dates, numbers and currencies considered

Deployment

• [ ] Production environment exists
• [ ] Environment variables documented
• [ ] Database migrations deploy safely
• [ ] Domain configured
• [ ] Logs available

None of this needs to be perfect.

It needs to be deliberate.

The stack is not the product

There is a certain irony to the modern SaaS ecosystem.

We have never had more tools for building software quickly.

And we have never had more ways to spend an entire week deciding which tools to use.

The answer isn't to stop caring about architecture.

It's to care about the right parts.

Use PostgreSQL because a relational database is a strong fit for the problem.

Use an authentication library because identity infrastructure is rarely your differentiator.

Use Stripe or Polar based on your billing and tax requirements, not because one is fashionable.

Use object storage for objects.

Use analytics to understand behavior and monitoring to understand failures.

Keep AI integrations replaceable.

Introduce localization structure before it becomes expensive to retrofit.

Deploy on the simplest platform that meets your requirements.

Then spend your engineering time on the thing somebody is actually paying you for.

That is what a modern SaaS stack should accomplish.

Not more infrastructure.

Less infrastructure standing between the idea and the product.

Motoko Base