How to Build a SaaS in Next.js (2026)

How to Build a SaaS in Next.js in 2026

Building a SaaS in Next.js sounds simple until you sit down and list everything you actually need. Auth, billing, dashboard, settings, team management, an empty-state experience, dark mode, mobile, accessibility, error states, loading states, role-based access, audit logs, and a marketing site that converts. That's roughly 30 to 50 screens before you've written a single line of business logic.

This guide walks the realistic path from zero to a production-ready SaaS in Next.js — what to build, in what order, and where you can skip a month of frontend work by starting from a kit instead of scratch.

Or skip the build entirely: get every kit for $499

If you're shipping more than one product, All Access unlocks every Next.js kit on thefrontkit. The SaaS Starter Kit (auth, dashboard, settings, 35+ screens), plus CRM, HR, Kanban, E-commerce, AI UX, Blog CMS, and 7 more. One-time payment, lifetime access, no subscription.

See All Access for $499 →

What a Real Next.js SaaS Actually Needs

Before writing code, count what has to exist for your SaaS to feel like a product instead of a demo.

Authenticated App Shell

Every SaaS lives inside an app shell — sidebar, topbar, main content area, profile menu, notifications. The shell carries:

Responsive sidebar that collapses on tablet and becomes a drawer on mobile
Persistent topbar with search, notifications, and a user menu
Active route highlighting so users always know where they are
Breadcrumbs for nested routes
Theme toggle that respects prefers-color-scheme on first load
Keyboard shortcuts at least for navigation (g d for dashboard, g s for settings, ? for help)

The shell itself is usually 4 to 6 components but they touch every screen. Get the shell wrong and the whole product feels off.

Auth Screens

The unsexy critical path. Six screens at minimum:

Sign up with email + password, OAuth providers (Google, GitHub at minimum), and a friendly empty state
Log in with the same providers, remember-me, and a "forgot password" link that actually works
Forgot password → email → reset flow
Email verification (or magic link, if you're going passwordless)
Two-factor authentication setup for users who want it
Account-locked / suspicious-activity screens for security incidents

Each one has loading states, error states, and accessibility quirks. Build them once, use them forever.

Dashboard

The first screen users see after login. Most SaaS dashboards fail because they look impressive on day one and useless on day thirty. The pattern that holds up:

Empty state for new users — clear next-action CTAs, not just "no data yet"
Key metrics at the top — three to five that matter, with comparison to a prior period
Recent activity feed so returning users see what happened since they were away
Quick actions (create, invite, configure) accessible without navigating
Charts and trends that summarize the last week or month at a glance

A dashboard should answer "what should I do next?" in three seconds. If users have to think, the design is wrong.

Settings

Settings is the most underbuilt section of every early SaaS. The categories that need to exist:

Profile — name, email, photo, preferences
Account — email change, password change, delete account flow
Team — invite, role assignment, removal, pending invites
Billing — current plan, payment method, invoices, upgrade/downgrade
Notifications — granular preferences across email, in-app, and push
Integrations — connected accounts (Slack, Google, Linear) with disconnect
API keys — generate, label, revoke, scope
Audit log — who did what, when (compliance asks for this)
Webhooks — endpoints, secrets, delivery history

Most teams build profile + billing on day one and ignore the rest for six months. Then the support tickets start.

Billing

Stripe is the default. The screens you need:

Plan picker — clear pricing tiers with feature comparison
Checkout — usually embedded Stripe Checkout or Stripe Elements
Current plan view — what you're on, when it renews, what it costs
Invoices — list with download links
Payment method — update card, change billing email
Upgrade / downgrade flow — prorate or schedule the change
Cancellation — with a save-the-customer survey

Connect Stripe webhooks for subscription events. Failed payment recovery emails alone will save more revenue than any acquisition channel.

Marketing Site

Often underweighted because engineers want to skip it. Reality: marketing pages convert more than the product UX in the first six months.

Landing page with hero, value props, social proof, pricing, FAQ, CTA
Pricing page with comparison table and an "annual saves X percent" toggle
Feature pages — one per major capability, optimized for search
About page with the team and the story
Blog for content marketing (where this article lives, for instance)
Docs linked but separate
Legal — privacy, terms, refund, cookie, support, shipping

Run Core Web Vitals on every marketing page. Lighthouse should pass at 90+ for SEO to work.

Tech Stack: The Defaults That Actually Hold Up in 2026

Framework: Next.js 16. App Router. Server Components by default. Route handlers for API endpoints.

UI library: shadcn/ui + Tailwind CSS v4. Radix primitives underneath for accessibility. Style as you go.

Auth: Clerk, Auth.js, or Supabase Auth. Clerk is the fastest to set up and prettiest out of the box. Auth.js is the open-source default. Supabase Auth pairs well with the database.

Database: Postgres via Supabase, Neon, or Vercel Postgres. Drizzle ORM or Prisma. Drizzle is faster, Prisma has better tooling. Pick based on team familiarity.

Payments: Stripe. Don't fight it. Razorpay if India-first.

Hosting: Vercel. It's worth the cost for the developer experience. Self-host on Coolify or Railway if you have specific needs.

Email: Resend or Postmark. React Email for templates.

File storage: Cloudflare R2 or Supabase Storage. S3 is the fallback.

Background jobs: Inngest, Trigger.dev, or Vercel Cron. Inngest is the most ergonomic. Vercel Cron is enough for simple schedules.

Observability: PostHog for product, Sentry for errors, Better Stack for uptime.

This stack is boring and that's a feature. Every component is well-documented, well-supported, and won't break in a year.

Build Path 1: From Scratch (8 to 12 Weeks)

Roughly the order to build in:

Week 1-2: Auth + app shell. Get login working, get the sidebar/topbar in place, build the empty dashboard. Resist building features yet.

Week 3-4: Settings + team. Profile, account, team invites. This is where most of the form complexity lives.

Week 5-6: Billing. Stripe integration, plan picker, checkout, invoices, webhooks. Test the failed payment flow before shipping.

Week 7-8: Core feature. Whatever your SaaS actually does. By now the chrome is built and you can focus on the differentiator.

Week 9-10: Marketing site. Landing, pricing, feature pages. SEO setup with proper schema.

Week 11-12: Polish. Empty states, error states, loading states, dark mode pass, accessibility audit, performance pass, deploy pipeline.

That's a competent solo engineer or a small team going at full speed. Realistic for most teams is closer to 14 to 18 weeks because of the long tail of "oh, we also need..." moments.

Build Path 2: Using a SaaS Starter Kit (1 Week)

The reason starter kits exist. The SaaS Starter Kit ships:

Auth screens (login, signup, forgot, reset, OTP, 2FA) — accessible, themeable
App shell (sidebar, topbar, drawer on mobile) with dark mode wired in
Dashboard with empty states, metric cards, recent activity, quick actions
Settings (profile, account, team, billing, notifications, API keys, audit log, webhooks)
Billing UI (plan picker, checkout, invoices, payment method) ready for Stripe wiring
Marketing site (landing, pricing, features, about, blog index, docs index, legal)
Component library (forms, tables, dialogs, command palette, toasts) all WCAG AA
35+ pages on Next.js 16, Tailwind v4, shadcn/ui

The work that remains:

Wire your auth provider (Clerk, Auth.js, Supabase Auth) into the existing screens
Connect your database and replace seed data with real queries
Wire Stripe webhooks for actual billing
Build your differentiating feature on top of the existing chrome

That last bullet is the only week you couldn't have skipped. Everything before it is a week of integration instead of three months of building.

Step-by-Step Build from the Kit

If you go the kit route, the realistic week:

Day 1: Setup. Clone, install, run locally. Configure environment variables for your hosting target. Replace logo, colors, and brand name.

Day 2: Auth wiring. Pick your provider. Replace the auth handlers in the existing screens with real calls. Test login, signup, password reset end to end.

Day 3: Database. Set up Postgres (Supabase or Neon are the fastest). Define your schema. Replace seed data imports with database queries via Drizzle or Prisma.

Day 4: Billing. Create Stripe products and prices. Wire the checkout flow. Set up the webhook handler for subscription events. Test with Stripe's test cards.

Day 5: Your feature. Build the one screen your SaaS exists to provide.

Day 6: Marketing customization. Rewrite the landing copy, swap the screenshots, update pricing. Run Lighthouse on every page.

Day 7: Deploy. Push to Vercel, configure domains, set up monitoring. Beta-test with one customer.

The kit doesn't write your feature for you. It removes the eleven other weeks of work that everyone has to do.

Common Pitfalls

Building features before chrome. Tempting because features are the fun part. Don't. Chrome is harder than it looks, and feature work on top of weak chrome means rewriting both.

Skipping empty states. Day-one users see empty everything. A blank dashboard with no copy looks broken. Design empty states first, then fill them with real data.

Ignoring dark mode until late. Dark mode pass at the end means refactoring colors throughout the app. Use design tokens from day one so dark mode is a switch, not a project.

Building settings as one page. "We'll add tabs later." A single settings screen with 40 fields is unusable. Break it into sub-pages on day one.

Doing auth yourself. Almost no team should build auth from scratch in 2026. The edge cases (password reset tokens, OAuth callback flows, session refresh, 2FA recovery) are battle-tested by Clerk and Auth.js. Use them.

Underestimating the marketing site. "Engineering will build it in a sprint" turns into a quarter of design and copy iterations. Start the marketing build in parallel with the product, not after.

Forgetting webhooks for Stripe. The Stripe Checkout flow updates Stripe's database, not yours. Without webhooks, your application doesn't know the user paid. Wire them on day one of billing.

Building team functionality without permissions. A teammate who can view everything but edit nothing is impossible if your data model doesn't track roles. Define roles in the schema from day one.

Adjacent Reads

How to Choose a Next.js SaaS Starter Kit — evaluation rubric for kit selection
Best Next.js SaaS Starter Kits 2026 — head-to-head comparison
What Is a SaaS Starter Kit? — definitions
SaaS Starter Kit vs Building From Scratch — the build-vs-buy decision
Launch Your SaaS Faster with Production-Ready Components — broader argument

FAQ

How long does it take to build a SaaS in Next.js from scratch? A competent solo engineer at full speed builds a credible Next.js SaaS in 10 to 14 weeks. Realistic timelines, including the long tail of polish work, design iterations, and the inevitable "we also need..." surfaces, land closer to 14 to 20 weeks. The variance is mostly in the surrounding chrome (auth, settings, billing, marketing) rather than the unique feature. A SaaS starter kit removes 8 to 12 of those weeks by giving you the chrome.

What auth provider should I use for a Next.js SaaS? Three good defaults in 2026: Clerk for the fastest setup and prettiest UI, Auth.js (formerly NextAuth) for the open-source default and maximum control, and Supabase Auth if you're already using Supabase for the database. Clerk costs money but the developer time it saves is usually worth it for production SaaS. Auth.js is free but you'll spend a week on UI polish. Avoid rolling your own auth in 2026; the edge cases are not worth the effort.

Do I need a marketing site separate from the app? Yes, but built in the same codebase. The marketing pages (landing, pricing, features, about, blog, docs, legal) live at the root, the app lives under /dashboard or a subdomain. Sharing the codebase means your design system, components, and accessibility standards apply everywhere. Two separate codebases for marketing and product create drift within a quarter.

How do I handle teams and roles in a Next.js SaaS? Define teams as a first-class entity in your database from day one. Every resource (project, document, deal, whatever your app manages) belongs to a team, not directly to a user. Every user-team relationship has a role (owner, admin, member, viewer). Permissions check the role on every server action. Retrofitting teams into a user-owned data model is one of the most expensive refactors in SaaS engineering. Build it right the first time.

Can I deploy a Next.js SaaS without Vercel? Yes. Vercel is the easiest but not the only option. Coolify on a Hetzner box is the cheapest self-hosted approach. Railway and Render are managed alternatives. Cloudflare Pages with Next.js on Workers is increasingly viable. The trade-off is operational complexity vs cost. For a SaaS earning meaningful revenue, Vercel's $20/month per developer is the right default. For pre-revenue products learning what they are, self-hosting saves money but costs time.

How much should I customize a SaaS starter kit? Customize the surface (colors, logo, copy, fonts) immediately. Customize the architecture (data model, role system, billing logic) as you build features that need different shapes. Don't rewrite the kit's accessibility, dark mode, or component library in week one — that's where the kit pays off. The mental model: treat the kit like a furnished apartment. Move the furniture, paint the walls, but don't tear out the plumbing on day one.