DEV Community: Syed Muhammad Ali

Build a Todo App with Next.js 16 and Supabase (2026 Guide)

Syed Muhammad Ali — Mon, 15 Jun 2026 19:00:00 +0000

In this guide, we’ll build a production-ready Todo App using:

Next.js 16
Supabase
TypeScript
Tailwind CSS
Server Actions
Authentication
Row Level Security (RLS)

This tutorial focuses more on logic and architecture rather than UI design.

By the end of this guide, you'll have:

Authentication with Supabase
Protected routes
Todo CRUD operations
Row Level Security (RLS)
Form validation with Zod
Server Actions
Secure session handling

What We’re Building

Our Todo App will include:

User Registration
User Login
Protected Dashboard
Create Todo
Complete Todo
Delete Todo
Secure Database Access with RLS

Prerequisites

Before starting, make sure you have:

Node.js installed
A Supabase account
Basic understanding of React and Next.js

Folder Structure

proxy.ts
src
├── actions
│   ├── auth.ts
│   └── todo.ts
├── app
│   ├── layout.tsx
│   ├── (auth)
│   │   ├── layout.tsx
│   │   ├── login
│   │   │   └── page.tsx
│   │   ├── register
│   │   │   └── page.tsx
│   ├── (private)
│   |   ├── layout.tsx
│   |   ├── page.tsx
│   |   ├── create
│   │   │   └── page.tsx
├── components
│   ├── form-error.tsx
│   ├── input.tsx
│   ├── loading-button.tsx
│   ├── navbar.tsx
│   └── todo-actions.tsx
├── utils
│   ├── supabase
│   |   ├── client.ts
│   |   ├── proxy.ts
│   |   └── server.ts
│   ├── validators
│   |   ├── auth.ts
│   │   └── todo.ts

Create a Next.js 16 Project

Run the following command:

npx create-next-app@latest todo-app

Choose options according to your preferences.

Recommended setup:

TypeScript
Tailwind CSS
App Router
React Compiler
src/ directory

Now move into the project:

cd todo-app

Setup Supabase

Go to Supabase Dashboard:

Create a New Project

Click New Project
Enter project name
Enter database password
Select region
Enable automatic RLS
Click Create Project

Add Environment Variables

Inside your project Dashboard:

Under Get Connected section
Click Frameworks

Copy the environment variables.

Create .env.local in your project root:

NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=

Install Supabase Packages

Run:

npm install @supabase/supabase-js @supabase/ssr

We’ll also install Zod later for validation.

Understanding Supabase Clients

Supabase provides two client types:

Browser Client

Used inside Client Components.

Server Client

Used inside:

Server Components
Server Actions
Route Handlers

Create Supabase Browser Client

Create:

/src/utils/supabase/client.ts

import { createBrowserClient } from "@supabase/ssr";

export const createClient = () =>
  createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
  );

Create Supabase Server Client

Create:

/src/utils/supabase/server.ts

import { createServerClient } from "@supabase/ssr";
import { cookies } from "next/headers";

export async function createClient() {
  const cookieStore = await cookies();

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },

        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options)
            );
          } catch {
            // Ignore if called from Server Component
          }
        },
      },
    }
  );
}

Setup Supabase Session Middleware

Create:

/src/utils/supabase/proxy.ts

import { createServerClient } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";

export async function updateSession(request: NextRequest) {
  let supabaseResponse = NextResponse.next({
    request,
  });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },

        setAll(cookiesToSet, headers) {
          cookiesToSet.forEach(({ name, value }) =>
            request.cookies.set(name, value)
          );

          supabaseResponse = NextResponse.next({
            request,
          });

          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options)
          );

          Object.entries(headers).forEach(([key, value]) =>
            supabaseResponse.headers.set(key, value)
          );
        },
      },
    }
  );

  await supabase.auth.getClaims();

  return supabaseResponse;
}

Setup Next.js Middleware

Create:

/src/proxy.ts

import { type NextRequest } from "next/server";
import { updateSession } from "@/utils/supabase/proxy";

export async function proxy(request: NextRequest) {
  return await updateSession(request);
}

export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico (favicon file)
     * Feel free to modify this pattern to include more paths.
    */
    "/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)",
  ],
};

Create Route Groups

We’ll use route groups for better organization.

app
 ├── (auth)
 └── (private)

Route groups help organize routes without affecting URLs.

Learn more about Nextjs Route Groups.

Create Auth Layout

Create:

/app/(auth)/layout.tsx

export default function AuthLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <div className="bg-gray-900 flex items-center justify-center flex-1">
      {children}
    </div>
  );
}

Create Login Page

Create:

/app/(auth)/login/page.tsx

"use client";

import { login } from "@/actions/auth";
import FormError from "@/components/form-error";
import Input from "@/components/input";
import LoadingButton from "@/components/loading-button";
import Image from "next/image";
import Link from "next/link";
import { useActionState } from "react";

export default function Login() {
  const [state, formAction] = useActionState(login, {
    errors: {
      email: [],
      password: [],
      formError: "",
    },
    data: {
      email: "",
      password: "",
    },
  });

  return (
    <div className="flex flex-col justify-center w-full">
      <div className="sm:mx-auto sm:w-full sm:max-w-sm">
        <Image
          src="https://tailwindcss.com/plus-assets/img/logos/mark.svg?color=indigo&shade=500"
          alt="Logo"
          className="mx-auto"
          width={50}
          height={50}
        />

        <h2 className="mt-10 text-center text-2xl/9 font-bold tracking-tight text-white">
          Sign in to your account
        </h2>
      </div>

      <div className="mt-10 sm:mx-auto sm:w-full sm:max-w-sm">
        <form action={formAction} className="space-y-6">
          <Input
            defaultValue={state?.data?.email || ""}
            name="email"
            type="email"
            label="Email address"
          />

          <FormError errors={state.errors.email} />

          <Input
            defaultValue={state?.data?.password || ""}
            name="password"
            type="password"
            label="Password"
          />

          <FormError errors={state.errors.password} />

          <LoadingButton title="Sign in" />

          <FormError errors={state?.errors?.formError} />
        </form>

        <p className="mt-10 text-center text-sm/6 text-gray-400">
          Not a member?{" "}
          <Link
            href="/register"
            className="font-semibold text-indigo-400 hover:text-indigo-300"
          >
            Register
          </Link>
        </p>
      </div>
    </div>
  );
}

Important Note About Input Names

The name attribute is extremely important because we later access form values using:

formData.get("email")

If names don’t match, your form won’t work correctly.

Create Reusable Input Component

Create:

/src/components/input.tsx

interface InputProps {
  name: string;
  label?: string;
  type?: string;
  defaultValue?: string;
  required?: boolean;
}

const Input = ({
  name,
  label,
  type = "text",
  defaultValue,
  required = true,
}: InputProps) => {
  return (
    <div>
      {label && (
        <label
          htmlFor={name}
          className="block text-sm/6 font-medium text-gray-100"
        >
          {label}
        </label>
      )}

      <div className="mt-2">
        <input
          id={name}
          type={type}
          name={name}
          defaultValue={defaultValue}
          required={required}
          autoComplete={type === "email" ? "email" : undefined}
          className="block w-full rounded-md bg-white/5 px-3 py-1.5 text-base text-white outline-1 outline-white/10"
        />
      </div>
    </div>
  );
};

export default Input;

Create Loading Button

Create:

/src/components/loading-button.tsx

"use client";

import { useFormStatus } from "react-dom";

const LoadingButton = ({
  title,
  className = "",
}: {
  title: string;
  className?: string;
}) => {
  const { pending } = useFormStatus();

  return (
    <button
      disabled={pending}
      type="submit"
      className={`cursor-pointer flex w-full justify-center rounded-md bg-indigo-500 px-3 py-1.5 text-white ${className}`}
    >
      {pending ? "Loading..." : title}
    </button>
  );
};

export default LoadingButton;

What is useFormStatus?

useFormStatus() gives information about the latest form submission state.

We use it to:

Disable button while submitting
Show loading state
Prevent duplicate submissions

Create Form Error Component

Create:

/src/components/form-error.tsx

export default function FormError({
  errors,
}: {
  errors?: string | string[];
}) {
  if (!errors || (Array.isArray(errors) && errors.length === 0)) {
    return null;
  }

  return (
    <p aria-live="polite" className="text-sm text-red-500">
      {typeof errors === "string" ? errors : errors.join(", ")}
    </p>
  );
}

Install Zod

Run:

npm install zod

Create Auth Validation Schema

Create:

/src/utils/validators/auth.ts

import z from "zod";

export const authSchema = z.object({
  email: z.email(),
  password: z
    .string()
    .min(6, "Password must be at least 6 characters long")
    .max(100, "Password must not exceed 100 characters"),
});

Create Login Action

Create:

/src/actions/auth.ts

"use server";

import { redirect } from "next/navigation";
import { createClient } from "@/utils/supabase/server";
import { authSchema } from "@/utils/validators/auth";

export async function login(prev: unknown, formData: FormData) {
  const data = {
    email: formData.get("email") as string,
    password: formData.get("password") as string,
  };

  const validatedFields = authSchema.safeParse(data);

  if (!validatedFields.success) {
    return {
      data,
      errors: {
        ...validatedFields.error.flatten().fieldErrors,
        formError: "",
      },
    };
  }

  const supabase = await createClient();

  const { error } = await supabase.auth.signInWithPassword(
    validatedFields.data
  );

  if (error) {
    return {
      data,
      errors: {
        formError: error.message,
        email: [],
        password: [],
      },
    };
  }

  redirect("/");
}

Understanding the Login Action

Here’s what happens:

Get form values using formData
Validate using Zod
Call Supabase Auth API
Redirect user after successful login

Because this is a Server Action, we must use the server Supabase client.

Create Register Page

Create:

/app/(auth)/register/page.tsx

Use the same structure as login page but replace:

import { signup } from "@/actions/auth";

and:

<LoadingButton title="Sign up" />

Create Signup Action

Add this inside:

/src/actions/auth.ts

export async function signup(prev: unknown, formData: FormData) {
  const data = {
    email: formData.get("email") as string,
    password: formData.get("password") as string,
  };

  const validatedFields = authSchema.safeParse(data);

  if (!validatedFields.success) {
    return {
      data,
      errors: {
        ...validatedFields.error.flatten().fieldErrors,
        formError: "",
      },
    };
  }

  const supabase = await createClient();

  const { error } = await supabase.auth.signUp(validatedFields.data);

  if (error) {
    return {
      data,
      errors: {
        formError: error.message,
        email: [],
        password: [],
      },
    };
  }

  redirect("/");
}

Supabase may require email confirmation depending on project settings after signup.

Create Private Layout

Create:

/app/(private)/layout.tsx

import Navbar from "@/components/navbar";

export default function PrivateLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <>
      <Navbar />

      <div className="mt-16">{children}</div>
    </>
  );
}

Create Navbar

Create:

/src/components/navbar.tsx

import { logout } from "@/actions/auth";
import { createClient } from "@/utils/supabase/server";
import LoadingButton from "./loading-button";
import Link from "next/link";

const Navbar = async () => {
  const supabase = await createClient();

  const {
    data: { user },
  } = await supabase.auth.getUser();

  return (
    <div className="w-full flex items-center gap-4 p-4 bg-gray-800 justify-between">
      <div className="text-lg font-bold">
        Hi {user?.email}
      </div>

      <div className="flex items-center gap-4">
        <nav className="flex items-center gap-4">
          <Link href="/">Home</Link>
          <Link href="/create">Create Todo</Link>
        </nav>

        <form action={logout}>
          <LoadingButton title="Logout" />
        </form>
      </div>
    </div>
  );
};

export default Navbar;

Create Logout Action

Add this to:

/src/actions/auth.ts

export async function logout() {
  const supabase = await createClient();

  const { data: claimsData } = await supabase.auth.getClaims();

  if (claimsData?.claims) {
    await supabase.auth.signOut();
  }

  redirect("/login");
}

Protect Private Routes

Right now, users can manually access protected pages.

We need route protection.

Update:

/src/utils/supabase/proxy.ts

Replace this

await supabase.auth.getClaims()

With

const { data } = await supabase.auth.getClaims();

const user = data?.claims;
const publicRoutes = ["/login", "/register"];

if (user && publicRoutes.includes(request.nextUrl.pathname)) {
  const url = request.nextUrl.clone();
  url.pathname = "/";
  return NextResponse.redirect(url);
}

if (!user && !publicRoutes.includes(request.nextUrl.pathname)) {
  const url = request.nextUrl.clone();
  url.pathname = "/login";
  return NextResponse.redirect(url);
}

Understanding Logic

Here’s what happens:

Get User
Create Public Routes
First if block checks if the user is logged in & trying to access public routes then navigates user to Home
Second if block checks if the user is not logged in & trying to access private routes then navigates user to Login

How Route Protection Works

Public Routes

Anyone can access:

/login
/register

Private Routes

Only authenticated users can access them.

Additional Protection

Logged-in users cannot revisit auth pages.

Create Todos Table

Open:

Supabase Project Dashboard
From sidebar click SQL Editor

Run:

create table todos (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users(id) on delete cascade not null,
  title text not null,
  completed boolean default false,
  created_at timestamptz default now()
);

Add Row Level Security Policies

Run:

create policy "Users can view own todos"
on todos
for select
using (auth.uid() = user_id);

create policy "Users can insert own todos"
on todos
for insert
with check (auth.uid() = user_id);

create policy "Users can update own todos"
on todos
for update
using (auth.uid() = user_id);

create policy "Users can delete own todos"
on todos
for delete
using (auth.uid() = user_id);

Why RLS is Important

Without RLS:

Any user could access all data.

With RLS:

Users can only access their own data.

This is one of the most important security features in Supabase.

Create Todo Validation Schema

Create:

/src/utils/validators/todo.ts

import z from "zod";

export const todoSchema = z.object({
  title: z
    .string()
    .min(2, "Title must be at least 2 characters long")
    .max(100, "Title must not exceed 100 characters"),
});

Create Todo Form

Create:

/app/(private)/create/page.tsx

"use client";

import { createTodo } from "@/actions/todo";
import FormError from "@/components/form-error";
import Input from "@/components/input";
import LoadingButton from "@/components/loading-button";
import { useActionState } from "react";

const CreateTodo = () => {
  const [state, formAction] = useActionState(createTodo, {
    error: "",
    data: {
      title: "",
    },
  });

  return (
    <div className="mt-10 sm:mx-auto sm:w-full sm:max-w-sm">
      <form action={formAction} className="space-y-6">
        <Input
          defaultValue={state?.data?.title || ""}
          name="title"
          label="Todo Title"
        />

        <FormError errors={state?.error} />

        <LoadingButton title="Create Todo" />
      </form>
    </div>
  );
};

export default CreateTodo;

Create Todo Action

Create:

/src/actions/todo.ts

"use server";

import { todoSchema } from "@/utils/validators/todo";
import { createClient } from "@/utils/supabase/server";
import { redirect } from "next/navigation";

export async function createTodo(
  prev: unknown,
  formData: FormData
) {
  const supabase = await createClient();

  const data = {
    title: formData.get("title") as string,
  };

  const validatedFields = todoSchema.safeParse(data);

  if (!validatedFields.success) {
    return {
      data,
      error:
        validatedFields.error.flatten().fieldErrors.title?.[0],
    };
  }

  const {
    data: { user },
  } = await supabase.auth.getUser();

  if (!user) {
    return {
      data,
      error: "Please login first",
    };
  }

  const { error } = await supabase.from("todos").insert({
    title: validatedFields.data.title,
    user_id: user.id,
  });

  if (error) {
    return {
      data,
      error: error.message,
    };
  }

  redirect("/");
}

Understanding the Create Todo Action

Here’s what happens:

Get form values using formData
Validate using Zod
Get logged in user
Call Supabase Auth API
Redirect user after successful insert

Create Home Page

Move:

/app/page.tsx

to:

/app/(private)/page.tsx

Now update it:

import TodoActions from "@/components/todo-actions";
import { createClient } from "@/utils/supabase/server";

export default async function Home() {
  const supabase = await createClient();

  const { data } = await supabase
    .from("todos")
    .select("*")
    .order("created_at", {
      ascending: false,
    });

  return (
    <div className="overflow-x-auto rounded-2xl border border-gray-200 bg-white shadow-sm max-w-xl mx-auto">
      <table className="divide-y divide-gray-200 w-full">
        <thead className="bg-gray-50">
          <tr>
            {['Todo', 'Status', 'Actions'].map((header) => (
              <th
                key={header}
                className="px-6 py-4 text-left text-sm font-semibold text-gray-700">
                {header}
              </th>
            ))}
          </tr>
        </thead>

        <tbody className="divide-y divide-gray-100 bg-white">
          {data?.map((todo) => (
            <tr
              key={todo.id}
              className="transition-colors hover:bg-gray-50"
            >
              <td className="px-6 py-4">
                <p className="font-medium text-gray-900">
                  {todo.title}
                </p>
              </td>

              <td className="px-6 py-4">
                <span
                  className={`inline-flex rounded-full px-3 py-1 text-xs font-medium ${todo.completed
                    ? "bg-green-100 text-green-700"
                    : "bg-yellow-100 text-yellow-700"
                    }`}
                >
                  {todo.completed ? "Completed" : "Pending"}
                </span>
              </td>

              <td className="px-6 py-4">
                <TodoActions todoId={todo.id} isCompleted={todo.completed} />
              </td>
            </tr>
          ))}
        </tbody>
      </table>

      {data?.length === 0 && (
        <div className="py-10 text-center text-sm text-gray-500">
          No todos found
        </div>
      )}
    </div>
  );
}

We’re fetching todos in descending order so that the latest todo comes at top.

Create Todo Actions Component

Create:

/src/components/todo-actions.tsx

'use client';

import { handleTodoAction } from "@/actions/todo";
import { useActionState } from "react";

const TodoActions = ({ todoId, isCompleted }: { todoId: string; isCompleted: boolean; }) => {
    const [_, action, isPending] = useActionState(handleTodoAction, undefined);

    const completeTodo = () => action({ todoId, action: "complete" });
    const deleteTodo = () => action({ todoId, action: "delete" });

    return (
        <form className="flex justify-end gap-3">
            {!isCompleted &&
                <button
                    formAction={completeTodo}
                    disabled={isPending}
                    className="rounded-lg disabled:opacity-50 bg-blue-500 px-4 py-2 text-sm font-medium text-white transition hover:bg-blue-600"
                >
                    Complete
                </button>
            }
            <button
                formAction={deleteTodo}
                disabled={isPending}
                className="rounded-lg disabled:opacity-50 bg-red-500 px-4 py-2 text-sm font-medium text-white transition hover:bg-red-600"
            >
                Delete
            </button>
        </form>
    )
}

export default TodoActions

Complete and Delete Todo Action

Add inside:

/src/actions/todo.ts

import { revalidatePath } from "next/cache";

export async function handleTodoAction(prev: unknown, data: { todoId: string; action: "delete" | "complete" }) {

    const { todoId, action } = data;

    if (!todoId) return;

    const supabase = await createClient()
    const { data: { user } } = await supabase.auth.getUser();

    if (!user) return;

    if (action === 'delete') {
        await supabase
            .from("todos")
            .delete()
            .eq("id", todoId)
            .eq("user_id", user.id);
    } else {
        await supabase
            .from("todos")
            .update({
                completed: true,
            })
            .eq("id", todoId)
            .eq("user_id", user.id);
    }
    revalidatePath('/');
}

Final Result

You now have a fully functional Todo App with:

Next.js 16
Supabase Authentication
Protected Routes
Server Actions
Zod Validation
Secure RLS Policies
CRUD Operations

Conclusion

This project demonstrates a modern full-stack architecture using:

Next.js 16
Server Actions
Supabase
RLS
Authentication

Even though it’s a simple Todo App, the structure is production-ready and scalable.

You can now build larger applications using the same architecture and patterns.

Useful Resources

Source Code: View on GitHub

How to Add Clerk Authentication in Next.js 16 (2026 Guide)

Syed Muhammad Ali — Sun, 14 Jun 2026 19:00:00 +0000

Introduction

Authentication is one of the most important parts of modern web applications. Whether you're building a SaaS product, admin dashboard, marketplace, or social platform, you need a secure way to manage users, sessions, and protected routes.

In this guide, you'll learn how to add authentication to your Next.js 16 app using Clerk. We’ll cover:

Setting up Clerk in Next.js 16
Creating sign-in and sign-up pages
Protecting private routes
Accessing authenticated users in server components
Protecting server actions
Adding social login
Understanding route groups and dynamic routes

By the end, you’ll have a complete authentication system running in your app.

Why Use Clerk for Authentication?

Building authentication from scratch is time-consuming and error-prone. You need to handle:

Password hashing
Sessions
Social login
Email verification
Security best practices
Protected routes
User management

Instead of reinventing all of this, Clerk provides a production-ready authentication system with prebuilt UI components and secure session handling.

Key Features of Clerk

Prebuilt authentication UI
User management dashboard
Social login providers
Session management
Route protection
Server-side authentication helpers
Easy integration with Next.js

Clerk works extremely well with the App Router in Next.js 16 and makes authentication much simpler.

What You’ll Build

In this tutorial, we’ll create:

Sign-in page
Sign-up page
Protected private routes
Navbar with auth state
Server-side user authentication
GitHub OAuth login

Prerequisites

Before starting, make sure you have:

Node.js installed
Basic knowledge of React and Next.js
A Clerk account

Create a Next.js Project

Create a new Next.js app using:

npx create-next-app@latest clerk-auth

Choose the options according to your preferences.

For this tutorial, we’re using:

TypeScript
Tailwind CSS
React Compiler
src/ directory

Install Clerk

Install Clerk in your project:

npm install @clerk/nextjs

Project Folder Structure

Your project structure will look like this:

root/
    .env.local

src/
  proxy.ts

  app/
    layout.tsx
    globals.css

    (private)/
      layout.tsx
      page.tsx

    (public)/
      layout.tsx

        sign-in/[[...sign-in]]/
          page.tsx

        sign-up/[[...sign-up]]/
          page.tsx

  components/
    navbar.tsx

Add Clerk Middleware

Create a proxy.ts file.

If you’re using the src directory, place it inside src/proxy.ts.

src/proxy.ts

import { clerkMiddleware } from '@clerk/nextjs/server'

export default clerkMiddleware();

export const config = {
  matcher: [
    // Skip Next.js internals and static files
    '/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)',

    // Always run for API routes
    '/(api|trpc)(.*)',

    // Clerk frontend API routes
    '/__clerk/(.*)',
  ],
}

What Does This Middleware Do?

The Clerk middleware:

Handles authentication sessions
Detects signed-in users
Protects routes
Works with both client and server components

The matcher ensures middleware runs only where necessary.

Wrap Your App with ClerkProvider

Now wrap your application with ClerkProvider.

src/app/layout.tsx

import { ClerkProvider } from '@clerk/nextjs'

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body className="min-h-full flex flex-col">
        <ClerkProvider>
          {children}
        </ClerkProvider>
      </body>
    </html>
  )
}

Why Use ClerkProvider?

ClerkProvider gives your entire application access to:

Authentication state
User sessions
Clerk UI components
Server helpers

Without it, Clerk components won’t work.

Create a Navbar Component

Now let’s create a navigation bar that changes depending on whether the user is logged in.

src/components/navbar.tsx

import {
  Show,
  SignInButton,
  SignUpButton,
  UserButton,
} from '@clerk/nextjs'

const Navbar = () => {
  return (
    <header className="flex justify-end items-center p-4 gap-4 h-16 shadow-md">
      <Show when="signed-out">
        <SignInButton />

        <SignUpButton>
          <button className="bg-[#6c47ff] text-white rounded-full font-medium text-sm sm:text-base h-10 sm:h-12 px-4 sm:px-5 cursor-pointer">
            Sign Up
          </button>
        </SignUpButton>
      </Show>

      <Show when="signed-in">
        <UserButton />
      </Show>
    </header>
  )
}

export default Navbar

Understanding the Clerk Components

`Show`

The Show component conditionally renders content based on authentication state.

<Show when="signed-in">

<Show when="signed-out">

`SignInButton`

Opens the Clerk sign-in flow.

`SignUpButton`

Opens the Clerk sign-up flow.

`UserButton`

Displays the authenticated user avatar and account menu.

Clerk has a lots of built in UI components that’s already do the heavy lifting, learn more Clerk’s UI Components.

Add Navbar to Root Layout

Update your root layout:

src/app/layout.tsx

import { ClerkProvider } from '@clerk/nextjs'
import Navbar from '@/components/navbar'

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body>
        <ClerkProvider>
          <Navbar />
          {children}
        </ClerkProvider>
      </body>
    </html>
  )
}

Start the Development Server

Run:

npm run dev

You’ll see a Clerk popup in the bottom-left corner.

Click:

Configure your application

You’ll be redirected to the Clerk dashboard.

Create a Clerk Application

After logging into Clerk:

Enter your application name
Create the application
Copy your environment variables

Add Environment Variables

Create a .env.local file.

.env.local

NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_****
CLERK_SECRET_KEY=***

After adding them, restart your development server.

Create a Custom Sign-In Page

Now let’s create our own sign-in route.

src/app/(public)/sign-in/[[...sign-in]]/page.tsx

import { SignIn } from '@clerk/nextjs'

const Login = () => {
  return <SignIn />
}

export default Login

Understanding the Route Structure

Route Groups

(public)

This is a Route Group in Next.js.

Route groups help organize routes without affecting the URL.

Learn more about Nextjs Route Groups.

Dynamic Catch-All Routes

[[...sign-in]]

This is a dynamic catch-all route.

It allows Clerk to handle multiple auth-related routes internally.

Learn more about Nextjs Dynamic Routes.

Create a Custom Sign-Up Page

src/app/sign-up/[[...sign-up]]/page.tsx

import { SignUp } from '@clerk/nextjs'

export default function Page() {
  return <SignUp />
}

Redirect Clerk Buttons to Custom Pages

Right now, the buttons still redirect to Clerk-hosted pages.

To fix this, update .env.local.

.env.local

NEXT_PUBLIC_CLERK_SIGN_IN_URL=/sign-in
NEXT_PUBLIC_CLERK_SIGN_UP_URL=/sign-up

Now the buttons will redirect to your custom routes.

Learn more about these environment variables and how to customize Clerk's redirect behavior in this dedicated clerk redirect guide.

Render User Information in a Server Component

Now let’s display the logged-in user’s name.

Move your homepage into a private route group:

app/(private)/page.tsx

And add

import { currentUser } from '@clerk/nextjs/server'

const Home = async () => {
  const user = await currentUser()

  return (
    <div className='mt-3 text-2xl'>
      Welcome {user?.fullName}
    </div>
  )
}

export default Home

Why Use `currentUser()`?

currentUser() works inside Server Components and allows you to securely access authenticated user data.

This is one of the best parts of using Clerk with Next.js App Router.

Protect Private Routes

Right now, unauthenticated users can still access your pages.

Let’s fix that.

Update your proxy.ts.

src/proxy.ts

import {
  clerkMiddleware,
  createRouteMatcher,
} from '@clerk/nextjs/server'

const isPublicRoute = createRouteMatcher([
  '/sign-in(.*)',
  '/sign-up(.*)',
])

export default clerkMiddleware(async (auth, req) => {
  if (!isPublicRoute(req)) {
    await auth.protect()
  }
})

export const config = {
  matcher: [
    '/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)',
    '/(api|trpc)(.*)',
    '/__clerk/(.*)',
  ],
}

How Route Protection Works

We created a public route matcher:

const isPublicRoute = createRouteMatcher([
  '/sign-in(.*)',
  '/sign-up(.*)',
])

Everything except those routes becomes protected.

await auth.protect()

If the user is not authenticated, Clerk automatically redirects them to the sign-in page.

Protect Server Actions

You can also secure server actions using Clerk’s auth() helper.

dummy-server-action.ts

'use server'

import { auth } from '@clerk/nextjs/server'

export const dummyAction = async () => {
  // Check if user is authenticated
  const { isAuthenticated } = await auth()

  if (!isAuthenticated) {
    return {
      error: 'Please login',
    }
  }

  // Database logic here
}

Why Protect Server Actions?

Even if your UI is protected, server actions should still verify authentication because users can manually send requests.

This adds an additional security layer.

Add GitHub Authentication

Clerk also supports social authentication providers like:

GitHub
Google
Discord
Microsoft
Apple

Let’s enable GitHub login.

Enable GitHub Login in Clerk

Go to your Clerk dashboard:

Select your application
Open the Configure tab
Click SSO Connections
Click Add Connection
Select GitHub
Enable:
- Sign-in
- Sign-up
Save the connection

Now users can authenticate using GitHub.

Important Production Note

When deploying to production, you should also enable:

Use Custom Credentials

This requires configuring your own GitHub OAuth credentials.

Follow this clerk doc on How to setup Github Custom Credentials.

Tip

If the built-in Clerk UI components don’t fully match your design requirements, you can create fully custom authentication flows using Clerk APIs. For more information, see the custom flow guide.

Common Mistakes to Avoid

Forgetting ClerkProvider

Without ClerkProvider, Clerk components won’t work.

Incorrect Middleware Location

If using src/, place middleware inside:

src/proxy.ts

Missing Environment Variables

Always restart your development server after changing .env.local.

Not Protecting Server Actions

Client-side protection alone is not enough.

Always validate authentication on the server.

Final Thoughts

You now have a complete authentication system in your Next.js 16 application using Clerk.

You learned how to:

Install Clerk
Create sign-in and sign-up pages
Protect routes
Access users in server components
Secure server actions
Add GitHub authentication

Clerk removes a huge amount of complexity from authentication and integrates extremely well with modern Next.js applications.

If you're building production-grade applications, Clerk is one of the fastest and safest ways to add authentication.

Next Steps

Helpful Resources

How to Integrate Stripe Payment Element with Next.js 16 (2026 Edition)

Syed Muhammad Ali — Sat, 13 Jun 2026 19:00:00 +0000

Stripe Payment Element is one of the best ways to accept payments in modern web applications. It keeps sensitive card information on Stripe servers, helping reduce PCI (Payment Card Industry) compliance complexity.

In this beginner-friendly guide, you'll learn how to integrate Stripe Payment Element with Next.js 16 using:

App Router
Server Actions
Payment Intents
Stripe Webhooks
TypeScript

By the end of this guide, you'll have a fully working checkout flow.

What We Are Building

In this tutorial, we'll create a simple SaaS pricing page with two packages:

Package	Price
Harmony	$399
Legacy	$599

When the user clicks a package:

A Stripe Payment Intent will be created
Stripe Payment Element will appear
User enters payment details
Payment is confirmed
Stripe webhook handles payment success

This guide mainly focuses on the Stripe integration rather than UI design, so we will keep the UI simple.

Two Ways to Accept Payments in Stripe

Stripe provides two main checkout methods.

1. Stripe Hosted Checkout

Stripe hosts the entire checkout page.

User flow:

Your Website → Stripe Checkout → Back to Your Website

This method is easier to set up. I've full guide covering this method please visit How to Integrate Stripe Hosted Checkout with Nextjs 16
.

2. Stripe Payment Element (What We'll Use)

Stripe checkout form is embedded directly inside your website.

Benefits:

Better UX
Fully customizable
No redirect before payment

Create a Next.js 16 Project

Run:

npx create-next-app@latest myapp

Choose your preferred setup.

Recommended:

TypeScript
App Router
src directory
React Compiler

Install Stripe Packages

Run:

npm install stripe @stripe/react-stripe-js @stripe/stripe-js

These packages help us:

Package	Purpose
stripe	Server-side Stripe SDK
@stripe/react-stripe-js	React components for Stripe
@stripe/stripe-js	Loads Stripe in browser

Stripe Setup

Create Stripe Server Instance

Create:

lib/stripe/server.ts

import Stripe from "stripe";

export const stripe = new Stripe(
  process.env.STRIPE_SECRET_KEY!,
  {
    apiVersion: "2026-04-22.dahlia",
  }
);

What Does This Do?

This creates a Stripe instance on the server side.

We'll use this object to:

Create Payment Intents
Handle webhooks
Access Stripe APIs securely

Create Stripe Client Instance

Create:

lib/stripe/client.ts

import { loadStripe } from "@stripe/stripe-js";

export const stripePromise = loadStripe(
  process.env.NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY!
);

Why Do We Need This?

Stripe Payment Element runs in the browser.

This file loads Stripe safely on the client side.

Get Stripe API Keys

Go to the Stripe Dashboard:

Open the sidebar
Enable Test Mode

This gives you test keys instead of live keys.

You should use:

sk_test_
pk_test_

while developing locally.

Create Environment Variables

Create:

.env.local

STRIPE_SECRET_KEY=sk_test_xxx
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_xxx
NEXT_PUBLIC_APP_URL=http://localhost:3000

Understanding Environment Variables

Why NEXT_PUBLIC_?

Variables that start with NEXT_PUBLIC_ can be accessed on the client side.

This is safe for publishable Stripe keys.

Important:

Never expose your Stripe Secret Key to the client side.

Create Package Constants

Create:

lib/constants/package-tier.ts

export const PKG_TIER = {
  HARMONY: "harmony",
  LEGACY: "legacy",
} as const;

export const PACKAGES = {
  harmony: {
    id: "harmony",
    name: "Harmony",
    price: 399,
  },

  legacy: {
    id: "legacy",
    name: "Legacy",
    price: 599,
  },
};

export type PkgTierType = keyof typeof PACKAGES;

Why Store Package Data in One File?

This is a very important practice.

Instead of hardcoding package names and prices everywhere in your app, we keep everything in one place.

Benefits:

Easier maintenance
Easier updates
Less bugs
Better scalability

For example:

If later you rename:

Harmony → Premium

You only update one file.

Create Checkout Form

Create:

src/components/checkout-form.tsx

"use client";

import {
  PaymentElement,
  useElements,
  useStripe,
} from "@stripe/react-stripe-js";

import { useState, SubmitEvent } from "react";

export function CheckoutForm() {
  const stripe = useStripe();
  const elements = useElements();

  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  const handleSubmit = async (e: SubmitEvent<HTMLFormElement>) => {
    e.preventDefault();

    if (!stripe || !elements) return;

    setLoading(true);
    setError(null);

    const result = await stripe.confirmPayment({
      elements,
      confirmParams: {
        return_url:
          `${process.env.NEXT_PUBLIC_APP_URL}/checkout/success`,
      },
      redirect: "always",
    });

    if (result.error) {
      setError(result.error.message || "Payment failed");
      setLoading(false);
      return;
    }

    setLoading(false);
  };

  return (
    <form
      onSubmit={handleSubmit}
      className="space-y-4"
    >
      <PaymentElement />

      {error && (
        <div className="text-red-500 text-sm">
          {error}
        </div>
      )}

      <button
        type="submit"
        disabled={!stripe || loading}
        className="w-full rounded-md bg-black px-4 py-3 text-white disabled:opacity-50"
      >
        {loading ? "Processing..." : "Pay Now"}
      </button>
    </form>
  );
}

Understanding the Checkout Form

What is PaymentElement?

PaymentElement is Stripe's prebuilt checkout UI.

It automatically supports:

Cards
Apple Pay
Google Pay
Bank payments
Many regional payment methods

depending on your Stripe settings.

Important:
Some methods may not work in development mode.

What Happens on Form Submit?

When the user clicks the Pay button:

stripe.confirmPayment()

Stripe:

Validates card details
Processes payment
Handles authentication
Redirects user after success

Why Use return_url?

After payment, Stripe redirects the user to your payment success page.

Example:

/checkout/success

Create Stripe Provider

Create:

src/components/stripe-provider.tsx

import { Elements } from "@stripe/react-stripe-js";
import { stripePromise } from "@/lib/stripe/client";
import { ReactNode } from "react";

interface Props {
  children: ReactNode;
  clientSecret: string;
}

export function StripeProvider({
  children,
  clientSecret,
}: Props) {
  return (
    <Elements
      stripe={stripePromise}
      options={{
        clientSecret,
        appearance: {
          theme: "night",
        },
      }}
    >
      {children}
    </Elements>
  );
}

Customizing Stripe Appearance

You can customize:

Theme
Colors
Fonts
Border radius
Input styles

using the appearance object.

For more appearance options please visit Stripe Appearance API Docs

Create Payment Intent Server Action

Create:

lib/actions/create-payment-intent.ts

"use server";

export async function createPaymentIntent() {}

What Are Server Actions?

Before creating the payment intent, let's quickly understand Server Actions.

Server Actions are asynchronous functions that run on the server.

They help us:

Handle forms
Access databases
Call APIs securely
Mutate data

without creating traditional API routes.

Create Package List Component

Create:

src/components/package-list.tsx

"use client";

import { useActionState } from "react";

import { CheckoutForm } from "@/components/checkout-form";
import { StripeProvider } from "@/components/stripe-provider";

import { createPaymentIntent } from "@/lib/actions/create-payment-intent";

import { PACKAGES } from "@/lib/constants/package-tier";

export default function PackageList() {
  const [state, action, isPending] = useActionState(createPaymentIntent, { clientSecret: "", error: "" });

  return (
    <div>
      <form action={action}>
        {Object.values(PACKAGES).map(
          (pkg) => (
            <button
              key={pkg.id}
              type="submit"
              name="packageTier"
              value={pkg.id}
              disabled={
                isPending ||
                !!state?.clientSecret
              }
            >
              {pkg.name}
            </button>
          )
        )}
      </form>

      {state?.error && (
        <div>{state.error}</div>
      )}

      {state?.clientSecret && (
        <StripeProvider
          clientSecret={
            state.clientSecret
          }
        >
          <CheckoutForm />
        </StripeProvider>
      )}
    </div>
  );
}

Important: The name attribute is very important inside form on button element. Later we’ll access value from form data in our server action using this name attribute.

Understanding useActionState

useActionState():

connects forms with Server Actions
manages loading state
handles server responses

It accepts:

your action function
initial state

And returns:

current state
form action
pending state

Why Use "use client"?

Hooks only work in client components.

Since we're using:

useActionState()

we must add:

"use client"

Add Component to Homepage

import PackageList from "@/components/package-list";

export default function Page() {
  return <PackageList />;
}

Update Server Action

Now let's add the actual logic.

"use server";

import { stripe } from "@/lib/stripe/server";

import {
  PACKAGES,
  PkgTierType,
} from "../constants/package-tier";

export async function createPaymentIntent(
  prev: unknown,
  formData: FormData
): Promise<{
  clientSecret?: string;
  error?: string;
}> {
  try {
    const pkgTier =
      formData.get("packageTier");

    if (
      typeof pkgTier !== "string" ||
      !(pkgTier in PACKAGES)
    ) {
      return {
        error: "Invalid package tier",
      };
    }

    const pkg =
      PACKAGES[pkgTier as PkgTierType];

    const paymentIntent =
      await stripe.paymentIntents.create({
        amount: pkg.price * 100,

        currency: "usd",

        automatic_payment_methods: {
          enabled: true,
        },

        metadata: {
          packageTier: pkgTier,
        },
      });

    if (!paymentIntent.client_secret) {
      return {
        error:
          "Failed to create payment intent",
      };
    }

    return {
      clientSecret:
        paymentIntent.client_secret,
    };
  } catch (err) {
    return {
      error:
        err instanceof Error
          ? err.message
          : "Something went wrong",
    };
  }
}

Now let’s understand this action:

Firstly it has two parameters prev we’re not using this, our default state this paramater is provided by useActionState and second formData this paramater is provided by form element.

Now we’ll use that same name attribute packageTier we provided inside form element to get the package that user has clicked on. After validation we’ll create stripe payment intent now let’s understand stripe object.

Understanding Payment Intents

A Payment Intent represents a payment session in Stripe.

It tracks:

Payment amount
Currency
Payment status
Payment method
Authentication steps

Why Multiply Amount by 100?

Stripe expects amounts in cents.

Price	Stripe Amount
$10	1000
$399	39900

What is Metadata?

Metadata allows us to attach extra information to payments.

Example:

metadata: {
  packageTier: pkgTier
}

This becomes very useful later inside webhooks.

What Does automatic_payment_methods Do?

When enabled:

automatic_payment_methods: {
  enabled: true
}

Stripe automatically shows compatible payment methods.

This is the easiest and recommended approach.

Stripe Webhooks

Now the checkout works.

But we still need a secure way to confirm payments.

This is where webhooks come in.

What Are Stripe Webhooks?

Stripe webhooks are server endpoints that Stripe calls automatically whenever events happen.

Examples:

Payment succeeded
Payment failed
Subscription renewed

Webhooks are extremely important because:

Never trust frontend payment success alone.

Always verify payments on the server.

Create Webhook Route

Create:

src/app/api/webhook/route.ts

Configure Webhook in Stripe Dashboard

From Stripe Dashboard:

Developers → Webhooks → Add Destination

Select Events

Choose:

payment_intent.succeeded
payment_intent.payment_failed

Add Webhook URL

Example:

https://yourdomain.com/api/webhook

Localhost Webhook Problem

Stripe cannot access localhost directly.

For local development, use:

ngrok
Stripe CLI

to expose your localhost server publicly. For more info please check:

Add Webhook Secret

Copy the signing secret.

Add to .env.local:

STRIPE_WEBHOOK_SECRET=whsec_xxx

Create Webhook Route Logic

export async function POST(req: Request) {
    try {
        const payload = await req.text();
        const sig = (await headers()).get('stripe-signature')!;
        let event;
        try {
            event = stripe.webhooks.constructEvent(payload, sig, endpointSecret);
        } catch (err) {
            const errorMessage = err instanceof Error ? err.message : 'Unknown error';
            return NextResponse.json(
                { message: `Webhook Error: ${errorMessage}` },
                { status: 400 }
            );
        }
        switch (event.type) {
            case "payment_intent.succeeded": {
                const paymentIntent = event.data.object as Stripe.PaymentIntent;

                if (paymentIntent.status !== 'succeeded') {
                    return NextResponse.json(
                        { message: 'Payment not completed' },
                        { status: 200 }
                    );
                }

                const pkgTier = paymentIntent.metadata?.packageTier;
                console.log("pkgTier", pkgTier);
                console.log("Payment success", paymentIntent.id);

                // Update database
                // Mark order paid
                // Send email
                // Trigger fulfillment

                break;
            }

            case "payment_intent.payment_failed": {
                console.log("Payment failed");
                break;
            }
        }

        return NextResponse.json({ message: 'Received' }, { status: 200 });

    } catch (err) {
        const error = err instanceof Error ? err.message : 'Something went wrong';
        console.error('error', error);

        return NextResponse.json(
            { error },
            { status: 500 }
        );
    }
}

Understanding the Webhook

Why Use req.text()?

Stripe requires the raw request body for signature verification.

In App Router:

await req.text()

works correctly without additional body parser configuration.

What Does constructEvent Do?

stripe.webhooks.constructEvent()

This verifies that the webhook request actually came from Stripe.

Without this verification, anyone could fake webhook requests.

Important Production Tip

Stripe may send the same webhook event multiple times.

Always:

Store Stripe event IDs
Ignore duplicate events

This prevents duplicate orders or emails.

Why Webhooks Matter

Your webhook is the safest place to:

Mark orders as paid
Save payment records
Send confirmation emails
Start product fulfillment

Never trust only frontend success pages.

Why Stripe expects 200

Notice in each return statement status is mostly 200.

When Stripe sends a webhook event, it waits for your server response.

200–299 → Stripe marks event as delivered successfully

400–499 → Stripe assumes your request is invalid

500+ → Stripe assumes your server failed

If Stripe does NOT get a 2xx response, it retries the webhook multiple times automatically.

Testing Stripe Payments

Use these test cards.

Successful Payment

4242 4242 4242 4242

Declined Card

4000 0000 0000 0002

3D Secure

4000 0025 0000 3155

Production Best Practices

Best Practice	Why It Matters
Use Webhooks	Never trust client-side payment success
Validate Metadata	Prevent invalid purchases
Store Event IDs	Avoid duplicate processing
Use HTTPS	Required for secure payments
Keep Secret Keys Server Side	Prevent security leaks

Final Thoughts

Stripe Payment Element is one of the best ways to build modern checkout flows according to your website theme in Next.js applications.

You now know how to:

Create Payment Intents
Use Stripe Payment Element
Handle payments
Use Server Actions
Verify Stripe webhooks
Build a production-ready checkout flow

This setup works great for:

SaaS products
Digital products
Agencies
AI tools
Membership websites

I hope this guide helps you build your own Stripe integration successfully.

Useful Resources

React useActionState Docs: https://react.dev/reference/react/useActionState
Next.js Server Actions Docs: https://nextjs.org/docs/app/getting-started/mutating-data
Stripe Payment Element Docs: https://docs.stripe.com/payments/payment-element

Continue Learning

If you'd like to learn more about stripe, check out these tutorials:

How to Integrate Stripe Checkout with Next.js 16 (2026 Edition)

Syed Muhammad Ali — Fri, 12 Jun 2026 03:34:38 +0000

If you're building a SaaS product with Next.js, one of the fastest and most reliable ways to accept payments is by using Stripe Checkout.

In this guide, you'll learn how to integrate Stripe Checkout with Next.js 16 using:

App Router
Server Actions
TypeScript
Stripe Webhooks
Hosted Checkout Pages

By the end, you'll have a fully working Stripe payment flow with webhook handling and order verification.

What We’re Building

In this tutorial, we’ll build a simple SaaS pricing flow where users can purchase one of two packages:

Harmony
Legacy

When a user clicks a checkout button:

A Stripe Checkout Session will be created
The user will be redirected to Stripe’s hosted checkout page
After payment, Stripe redirects the user back to your website
Stripe sends a webhook event to your Next.js application
Your app verifies the payment and creates an order

This guide focuses mainly on Stripe + Next.js integration rather than UI design.

Two Ways to Integrate Stripe Checkout

1. Hosted Stripe Checkout

In this method:

Users are redirected to a secure checkout page hosted by Stripe
Stripe handles payment security and PCI compliance
After payment, users are redirected back to your website

This is the easiest and safest option for most SaaS applications.

2. Embedded Stripe Checkout

In this approach:

Stripe Checkout is embedded directly inside your website
You can customize the UI more deeply
No external redirect is required

This guide focuses on the hosted checkout approach but I've full guide covering this second method please visit How to Integrate Stripe Payment Element with Nextjs 16

Create a Next.js 16 Project

Create a new Next.js application:

npx create-next-app@latest myapp

Choose the options that fit your setup.

Recommended:

TypeScript
App Router
src/ directory
React Compiler

Install Stripe

Install the official Stripe SDK:

npm install stripe

Configure Stripe Server SDK

Create the following file:

src/lib/stripe/server.ts

Add this code:

import Stripe from 'stripe';

export const stripe = new Stripe(
  process.env.STRIPE_SECRET_KEY!,
  {
    apiVersion: '2026-04-22.dahlia'
  }
);

This initializes the Stripe SDK using your secret API key.

Get Your Stripe API Keys

Go to:

https://dashboard.stripe.com

Enable Test Mode from the dashboard.

Copy your:

sk_test_... secret key
pk_test_... publishable key

Configure Environment Variables

Create a .env.local file in your project root:

STRIPE_SECRET_KEY=sk_test_****
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_****
NEXT_PUBLIC_APP_URL=http://localhost:3000

Important Notes

STRIPE_SECRET_KEY should only be used on the server
NEXT_PUBLIC_ variables are exposed to the client
Always switch to live keys before production deployment

Create Products in Stripe

Inside the Stripe dashboard:

Go to Product Catalog
Click Create Product
Enter:
- Product name
- Pricing
- Currency
- Billing type

If users pay once:

Select One-off

If users subscribe monthly/yearly:

Select Recurring

Copy Stripe Price IDs

After creating products:

Open the product
Click the three-dot menu
Click Copy Price ID

Add them to .env.local:

NEXT_PUBLIC_STRIPE_HARMONY_PRICE_ID=price_xxx
NEXT_PUBLIC_STRIPE_LEGACY_PRICE_ID=price_xxx

Create Package Constants

Create:

src/lib/constants/package-tier.ts

Add:

export const PKG_TIER = {
  HARMONY: 'harmony',
  LEGACY: 'legacy'
} as const;

export const PACKAGES = {
  harmony: {
    id: 'harmony',
    name: 'Harmony',
    description: 'The complete memorial song',
    price: 399,
    turnaroundHours: 72,
    maxRevisions: 2,
    stripePriceId: process.env.NEXT_PUBLIC_STRIPE_HARMONY_PRICE_ID!,
    features: [
      'Custom AI-generated memorial song',
      'Two rounds of lyric revisions',
      'Single-photo video with scrolling lyrics',
      'Social media versions'
    ]
  },

  legacy: {
    id: 'legacy',
    name: 'Legacy',
    description: 'Their full story, beautifully told',
    price: 599,
    turnaroundHours: 96,
    maxRevisions: 3,
    stripePriceId: process.env.NEXT_PUBLIC_STRIPE_LEGACY_PRICE_ID!,
    features: [
      'Everything in Harmony',
      'Multi-photo slideshow video',
      'Video revisions',
      'Social media versions'
    ]
  }
};

export type PkgTierType = keyof typeof PACKAGES;

Why Use Constants Instead of Hardcoded Strings?

Avoid writing values like "harmony" everywhere in your app.

Using constants:

reduces bugs
improves autocomplete
makes refactoring easier
keeps your app scalable

Create a Server Action

Create:

src/lib/actions/start-checkout.ts

Add:

"use server";

export async function startCheckout() {

}

What Are Server Actions?

Server Actions are asynchronous functions executed on the server in Next.js.

They are commonly used for:

form submissions
database mutations
payment processing
secure backend logic

Official docs:
https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations

Create Package UI

Create:

src/components/package-list.tsx

Add:

'use client';

import { useActionState } from "react";
import { startCheckout } from "@/lib/actions/start-checkout";
import { PACKAGES } from "@/lib/constants/package-tier";

export default function PackageList() {
  const [state, action, isPending] = useActionState(
    startCheckout,
    { error: '' }
  );

  return (
    <div>
      <form action={action}>
        {Object.values(PACKAGES).map(pkg => (
          <button
            key={pkg.id}
            type="submit"
            name="packageTier"
            value={pkg.id}
            disabled={isPending}
            className="border border-gray-300 p-3 disabled:opacity-50"
          >
            {isPending ? 'Redirecting...' : pkg.name}
          </button>
        ))}
      </form>

      {state?.error && (
        <div className="text-red-500">
          {state.error}
        </div>
      )}
    </div>
  );
}

Understanding useActionState

useActionState():

connects forms with Server Actions
manages loading state
handles server responses

It accepts:

your action function
initial state

And returns:

current state
form action
pending state

Render Packages on Home Page

Update your homepage:

import PackageList from "@/components/package-list";

export default function Page() {
  return <PackageList />;
}

Create Stripe Checkout Session

Now update:

src/lib/actions/start-checkout.ts

"use server";

import { redirect } from "next/navigation";
import { PACKAGES, PkgTierType } from "../constants/package-tier";
import { stripe } from "../stripe/server";

export async function startCheckout(
  prev: unknown,
  formData: FormData
) {
  try {
    const pkgTier = formData.get('packageTier') as PkgTierType;

    if (!pkgTier || !PACKAGES[pkgTier]) {
      return { error: 'Invalid package tier' };
    }

    const session = await stripe.checkout.sessions.create({
      mode: 'payment',

      line_items: [
        {
          price: PACKAGES[pkgTier].stripePriceId,
          quantity: 1
        }
      ],

      success_url:
        `${process.env.NEXT_PUBLIC_APP_URL}/checkout/success?session_id={CHECKOUT_SESSION_ID}`,

      cancel_url:
        `${process.env.NEXT_PUBLIC_APP_URL}/`,

      metadata: {
        packageTier: pkgTier
      },

      customer_creation: 'always',

      billing_address_collection: 'auto',

      phone_number_collection: {
        enabled: true
      }
    });

    if (!session.url) {
      throw new Error('Failed to create checkout session');
    }

    redirect(session.url);

  } catch (err) {
    return {
      error:
        err instanceof Error
          ? err.message
          : 'Failed to checkout'
    };
  }
}

Understanding the Checkout Session

mode

mode: 'payment'

Used for one-time payments.

For subscriptions use:

mode: 'subscription'

line_items

Defines what the user is purchasing.

success_url

Where Stripe redirects users after successful payment.

cancel_url

Where Stripe redirects users after cancellation.

metadata

Useful for attaching:

package IDs
user IDs
internal references

customer_creation

Automatically creates Stripe customers.

Important Security Note

Never trust prices coming from the frontend.

Always:

validate product IDs
validate Stripe price IDs
verify payments server-side

Create Stripe Webhook Route

Create:

src/app/api/webhook/route.ts

Configure Stripe Webhooks

Inside Stripe dashboard:

Go to Developers
Click Webhooks

Click Add Destination
Enter:

https://yourdomain.com/api/webhook

Select:
checkout.session.completed
Copy the signing secret

Add to .env.local:

STRIPE_WEBHOOK_SECRET=whsec_xxx

Test Webhooks Locally

Install the Stripe CLI:

https://docs.stripe.com/stripe-cli

Run:

stripe listen --forward-to localhost:3000/api/webhook

Stripe will generate a webhook signing secret for local development.

Implement the Webhook Handler

Add:

import { PACKAGES } from "@/lib/constants/package-tier";
import { stripe } from "@/lib/stripe/server";
import { headers } from "next/headers";
import { NextResponse } from "next/server";
import Stripe from "stripe";

const endpointSecret =
  process.env.STRIPE_WEBHOOK_SECRET!;

export async function POST(req: Request) {
  try {
    const payload = await req.text();

    const sig =
      (await headers()).get('stripe-signature')!;

    let event: Stripe.Event;

    try {
      event = stripe.webhooks.constructEvent(
        payload,
        sig,
        endpointSecret
      );

    } catch (err) {
      const errorMessage =
        err instanceof Error
          ? err.message
          : 'Unknown error';

      return NextResponse.json(
        { message: `Webhook Error: ${errorMessage}` },
        { status: 400 }
      );
    }

    if (event.type === 'checkout.session.completed') {

      const session =
        event.data.object as Stripe.Checkout.Session;

      if (session.payment_status !== 'paid') {
        return NextResponse.json(
          { message: 'Payment not completed' },
          { status: 200 }
        );
      }

      const pkgTier =
        session.metadata?.packageTier;

      const customerDetails =
        session.customer_details;

      const customerEmail =
        customerDetails?.email;

      if (!pkgTier || !(pkgTier in PACKAGES)) {
        throw new Error('Invalid package tier');
      }

      if (!customerEmail) {
        throw new Error('Customer email required');
      }

      // Create database order here
      // Send confirmation email here
    }

    return NextResponse.json(
      { message: 'Received' },
      { status: 200 }
    );

  } catch (err) {

    const error =
      err instanceof Error
        ? err.message
        : 'Something went wrong';

    console.error(error);

    return NextResponse.json(
      { error },
      { status: 500 }
    );
  }
}

Why Use `req.text()`?

In Next.js App Router route handlers, we can safely use:

await req.text()

Unlike Pages Router, no additional body-parser configuration is required.

Prevent Duplicate Orders

Stripe automatically retries failed webhooks.

Always store:

Stripe event IDs
checkout session IDs

before processing orders.

This prevents:

duplicate emails
duplicate orders
duplicate fulfillment

Subscription Webhook Events

This guide focuses on one-time payments.

If you're using subscriptions, also listen for:

invoice.paid
customer.subscription.updated
customer.subscription.deleted

Test Your Checkout

Start your Next.js app:

npm run dev

Click one of your package buttons.

You should:

Redirect to Stripe Checkout
Complete payment
Return to your website
Receive webhook events successfully

Final Thoughts

You now have a fully working Stripe Checkout integration using:

Next.js 16
App Router
Server Actions
Stripe Webhooks
TypeScript

This setup is scalable, production-friendly, and ideal for SaaS applications.

From here you can expand into:

subscriptions
invoices
customer portals
usage billing
Stripe Connect
embedded checkout

Useful Resources

Stripe Documentation: https://docs.stripe.com
Next.js Documentation: https://nextjs.org/docs
Stripe Checkout Docs: https://docs.stripe.com/payments/checkout

Continue Learning

If you'd like to learn more about stripe, check out these tutorials:

SaaS Starter Architecture with Next.js 2026

Syed Muhammad Ali — Fri, 12 Jun 2026 03:27:17 +0000

You've got the idea. You're pumped. You open your terminal, run npx create-next-app, and then... you stare at a blank page.tsx wondering — where do I even begin?

This is the silent killer of SaaS projects. Not the idea. Not the tech. The architecture. Most developers start hacking features together and three weeks in, the codebase is a mess of spaghetti — auth logic mixed with UI, API calls scattered everywhere, no clear structure. It's painful to extend and even more painful to hand off.

The good news? A solid SaaS architecture isn't complicated. It's just a set of decisions made upfront — decisions about folders, responsibilities, and boundaries. Get those right and building features becomes fast, predictable, and even enjoyable.

By the end of this guide, you'll have a clear, production-ready SaaS folder structure with authentication, billing, protected routes, and a dashboard layout — all wired together with Next.js App Router, TypeScript, Tailwind CSS, and React Compiler.

Why Most SaaS Projects Fall Apart Early

Here's the honest truth: most developers (even experienced ones) start with a feature-first mindset. They add auth, then billing, then a dashboard — each piece bolted on without a plan. It works for a while. Then it doesn't.

The problems that show up:

You can't tell where business logic lives (is it in the component? the API route? a hook?)
Protected and public pages share the same layout, causing weird rendering bugs
Adding a new feature means touching five different files across three folders
Onboarding a new developer takes days just to explain the structure

The fix isn't a framework or a library. It's deliberate architecture — deciding upfront how your app is organized and what each layer is responsible for.

What We're Building

A scalable SaaS starter with:

✅ App Router (Next.js latest)
✅ React Compiler (automatic optimization — no manual useMemo / useCallback)
✅ TypeScript (strict mode)
✅ Tailwind CSS
✅ Authentication-ready structure (works with Clerk, Auth0, NextAuth, etc.)
✅ Billing-ready structure (works with Stripe)
✅ Separate layouts for marketing, auth, and dashboard
✅ Proxy-based route protection

Prerequisites

Before we start, make sure you have:

Node.js 20+ installed
Basic familiarity with Next.js App Router
A fresh Next.js project (we'll scaffold one below)

Step 1: Scaffold the Project

Let's create a fresh Next.js app with all the defaults we need.

Run the following command:

npx create-next-app@latest saas-starter

Choose options according to your preferences.

Recommended setup:

TypeScript
Tailwind CSS
App Router
React Compiler
src/ directory

React Compiler

React Compiler automatically optimizes your components — it's like having a senior dev go through your entire codebase and add useMemo and useCallback everywhere they're needed. You get that for free.

⚠️ Common Mistake: Don't manually add useMemo or useCallback when React Compiler is enabled. It'll do it better than you. Adding them manually can actually interfere with the compiler's optimizations.

Step 2: Plan the Folder Structure

This is the most important step. A well-thought-out folder structure acts like a map — anyone who opens the project immediately knows where everything lives.

Here's the structure we're going for:

saas-starter/
├── src/
│   ├── app/
│   │   ├── (marketing)/          # Public-facing pages (landing, pricing, about)
│   │   │   ├── page.tsx          # Homepage
│   │   │   ├── pricing/
│   │   │   │   └── page.tsx
│   │   │   └── layout.tsx        # Marketing layout (navbar, footer)
│   │   │
│   │   ├── (auth)/               # Auth pages (login, signup, forgot password)
│   │   │   ├── login/
│   │   │   │   └── page.tsx
│   │   │   ├── signup/
│   │   │   │   └── page.tsx
│   │   │   └── layout.tsx        # Minimal auth layout (just centered card)
│   │   │
│   │   ├── (dashboard)/          # Protected app pages (only logged-in users)
│   │   │   ├── dashboard/
│   │   │   │   └── page.tsx
│   │   │   ├── settings/
│   │   │   │   └── page.tsx
│   │   │   └── layout.tsx        # Dashboard layout (sidebar, topbar)
│   │   │
│   │   ├── api/                  # API routes (backend endpoints)
│   │   │   ├── webhooks/
│   │   │   │   └── stripe/
│   │   │   │       └── route.ts
│   │   │   └── user/
│   │   │       └── route.ts
│   │   │
│   │   ├── layout.tsx            # Root layout (fonts, global providers)
│   │   └── globals.css
│   │
│   ├── components/
│   │   ├── ui/                   # Reusable UI primitives (Button, Input, Modal)
│   │   ├── marketing/            # Components only used on marketing pages
│   │   ├── dashboard/            # Components only used in the dashboard
│   │   └── shared/               # Components used everywhere (Avatar, Logo)
│   │
│   ├── lib/
│   │   ├── auth.ts               # Auth helper functions
│   │   ├── stripe.ts             # Stripe client setup
│   │   ├── db.ts                 # Database client setup
│   │   └── utils.ts              # General utility functions
│   │
│   ├── hooks/                    # Custom React hooks
│   ├── types/                    # TypeScript type definitions
│   └── proxy.ts                  # Route protection logic
└── .env.local                    # Environment variables (never commit this!)

Let's break down the key decisions here:

Route Groups (marketing), (auth), (dashboard) — The parentheses are a Next.js feature. They let you group routes without affecting the URL. So app/(marketing)/pricing/page.tsx lives at /pricing, not /marketing/pricing. The real power is that each group gets its own layout.tsx — meaning your dashboard gets a sidebar, your auth pages get a clean centered layout, and your marketing pages get a navbar. No mixing.

lib/ folder — This is where your "glue code" lives. Auth helpers, database clients, Stripe setup. These are not components, not hooks — they're plain functions and configurations that any part of the app can import.

types/ folder — All your TypeScript interfaces and types live here. This prevents the chaos of defining type User = {...} in five different files.

Important: In Next.js 16, Middleware has been renamed to Proxy. In older versions, you'll see middleware.ts used instead.

Step 3: Set Up Route Groups & Layouts

Let's create the three layout files that power the different sections of the app.

Root Layout

The root layout wraps everything. It's the right place for global providers (auth context, theme, etc.) and fonts.

// app/layout.tsx
import type { Metadata } from "next";
import { Inter } from "next/font/google";
import "./globals.css";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
  title: {
    template: "%s | YourSaaS",
    default: "YourSaaS — The tagline goes here",
  },
  description: "Your SaaS description here.",
};

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body className={inter.className}>
        {/* Global providers go here (auth, theme, etc.) */}
        {children}
      </body>
    </html>
  );
}

Marketing Layout

// app/(marketing)/layout.tsx
import { Navbar } from "@/components/marketing/Navbar";
import { Footer } from "@/components/marketing/Footer";

export default function MarketingLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="flex min-h-screen flex-col">
      <Navbar />
      <main className="flex-1">{children}</main>
      <Footer />
    </div>
  );
}

Auth Layout

// app/(auth)/layout.tsx
export default function AuthLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="flex min-h-screen items-center justify-center bg-gray-50">
      <div className="w-full max-w-md px-4">{children}</div>
    </div>
  );
}

Dashboard Layout

// app/(dashboard)/layout.tsx
import { Sidebar } from "@/components/dashboard/Sidebar";
import { Topbar } from "@/components/dashboard/Topbar";

export default function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="flex h-screen overflow-hidden bg-gray-100">
      <Sidebar />
      <div className="flex flex-1 flex-col overflow-hidden">
        <Topbar />
        <main className="flex-1 overflow-y-auto p-6">{children}</main>
      </div>
    </div>
  );
}

💡 Why separate layouts matter: Without this, you'd need conditional logic inside a single layout to decide whether to show the sidebar. That gets messy fast. Route groups keep things clean — each section of your app has its own look, independently.

Step 4: Protect Routes with Proxy

Proxy — think of it as a security guard that stands at the entrance of your app. Every request passes through it before hitting a page. This is the perfect place to check: "Is this user logged in? If not, redirect them to /login."

// proxy.ts  (lives at the ROOT of your project, not inside /app)
import { NextRequest, NextResponse } from "next/server";

// These are the routes that require the user to be logged in
const protectedRoutes = ["/dashboard", "/settings", "/billing"];

// These are routes that logged-in users shouldn't see (e.g. login page)
const authRoutes = ["/login", "/signup"];

export function proxy(request: NextRequest) {
  const { pathname } = request.nextUrl;

  // Check for your auth token/session cookie
  // Replace "auth_token" with whatever your auth provider uses
  const isAuthenticated = request.cookies.has("auth_token");

  // If the user is trying to access a protected route but isn't logged in
  if (protectedRoutes.some((route) => pathname.startsWith(route))) {
    if (!isAuthenticated) {
      return NextResponse.redirect(new URL("/login", request.url));
    }
  }

  // If the user is already logged in and tries to visit /login or /signup
  if (authRoutes.includes(pathname) && isAuthenticated) {
    return NextResponse.redirect(new URL("/dashboard", request.url));
  }

  return NextResponse.next();
}

// Tell Next.js which paths this proxy should run on
export const config = {
  matcher: ["/((?!api|_next/static|_next/image|favicon.ico).*)"],
};

What's happening here, line by line:

protectedRoutes — the list of URL paths only logged-in users can visit
authRoutes — pages that make no sense for logged-in users (you're already in!)
request.cookies.has("auth_token") — checks if the auth cookie exists. Your auth provider (Clerk, NextAuth, etc.) will set this automatically
NextResponse.redirect(...) — sends the user to a different URL
matcher — tells proxy to skip static files and images (no need to auth-check a .png)

⚠️ Common Mistake: Forgetting the matcher config. Without it, proxy runs on every single request — including CSS files, images, and fonts. That's unnecessary overhead and can cause weird issues.

Step 5: Set Up the Types Folder

Define your core types once, use them everywhere. This prevents TypeScript errors and keeps your data shapes consistent.

// types/index.ts
export type User = {
  id: string;
  email: string;
  name: string;
  avatarUrl?: string;
  plan: "free" | "pro" | "enterprise";
  createdAt: Date;
};

export type Subscription = {
  id: string;
  userId: string;
  status: "active" | "cancelled" | "past_due" | "trialing";
  plan: "pro" | "enterprise";
  currentPeriodEnd: Date;
};

export type ApiResponse<T> = {
  data: T | null;
  error: string | null;
};

💡 Why a central types/ folder? If you define User in five files, changing one field means updating five places. One file, one source of truth.

Step 6: Set Up Core Lib Files

The lib/ folder holds your setup code — the stuff that's not a component but needs to exist before anything works.

Database (example with Supabase)

// lib/db.ts
import { createClient } from "@supabase/supabase-js";

// process.env is how you access environment variables in Next.js
// These are secret keys stored in your .env.local file — never hardcode them!
const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL!;
const supabaseKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!;

export const db = createClient(supabaseUrl, supabaseKey);

Stripe Client

// lib/stripe.ts
import Stripe from "stripe";

// The "!" tells TypeScript "trust me, this value exists"
export const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
  apiVersion: "latest supported version",
  typescript: true,
});

Utility Functions

// lib/utils.ts

// Combines Tailwind class names without conflicts
// Install clsx and tailwind-merge first: npm install clsx tailwind-merge
import { clsx, type ClassValue } from "clsx";
import { twMerge } from "tailwind-merge";

export function cn(...inputs: ClassValue[]): string {
  return twMerge(clsx(inputs));
}

// Format a date to a readable string
export function formatDate(date: Date): string {
  return new Intl.DateTimeFormat("en-US", {
    month: "long",
    day: "numeric",
    year: "numeric",
  }).format(date);
}

💡 The cn() function is one of the most used utilities in any Tailwind project. It lets you merge class names conditionally without worrying about conflicting Tailwind classes. Almost every component will use it.

Step 7: Environment Variables

Environment variables are secret keys and configuration values that your app needs but should never be publicly visible. Things like your database password, Stripe secret key, or auth secret.

Create a .env.local file at the root of your project:

# .env.local

# Authentication (example with Clerk)
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_...
CLERK_SECRET_KEY=sk_test_...

# Database (example with Supabase)
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

# Stripe
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_...
STRIPE_SECRET_KEY=sk_test_...
STRIPE_WEBHOOK_SECRET=whsec_...

# App
NEXT_PUBLIC_APP_URL=http://localhost:3000

⚠️ Critical: Add .env.local to your .gitignore immediately. If you push secret keys to GitHub, bad actors can find them and abuse your accounts. This is not hypothetical — it happens all the time.

Variables starting with NEXT_PUBLIC_ are exposed to the browser. Everything else is server-only. Never put secret keys in NEXT_PUBLIC_ variables.

Frequently Asked Questions

Can I use this structure with the Pages Router instead of App Router?

You can, but the route groups (marketing), (auth), and (dashboard) are an App Router feature — they won't work in Pages Router. With Pages Router you'd achieve similar separation using custom _app.tsx logic and manual layout wrappers, but it's messier. App Router is the recommended approach going forward.

Do I have to use Clerk or Supabase specifically?

Not at all. The architecture is auth-provider agnostic. Whether you use Clerk, NextAuth, Auth0, or Supabase Auth — the folder structure stays the same. You just swap out the cookie name in proxy.ts and the client setup in lib/auth.ts.

What if my app grows and the structure doesn't scale?

This structure handles the vast majority of SaaS apps well. If you hit a point where a single components/dashboard/ folder gets too crowded, break it into feature folders — e.g. components/dashboard/billing/, components/dashboard/team/. The core principle stays the same: group by where things are used.

Is React Compiler production-ready?

Yes. As of 2025, React Compiler is stable and recommended for new projects. It's been battle-tested by the Meta team on large-scale apps. Just remember — once it's on, stop writing manual useMemo and useCallback. Let the compiler do its job.

Where should I put shared API logic that multiple routes use?

Put it in lib/. For example, a lib/user.ts file with a getUserById(id) function that your API routes and server components can both import. This avoids duplicating database queries across files.

The Final Picture

Here's what you've got now:

Layer	What lives here
`app/(marketing)`	Landing page, pricing, about — with navbar & footer
`app/(auth)`	Login, signup — minimal centered layout
`app/(dashboard)`	Protected app pages — sidebar + topbar
`proxy.ts`	Route protection — redirects unauthenticated users
`lib/`	DB client, Stripe setup, utility functions
`types/`	Shared TypeScript types — User, Subscription, etc.
`components/`	UI organized by where it's used

This architecture scales. Whether you're building alone or with a team of five, adding a new feature means you know exactly which folder it belongs in. There's no guessing, no hunting through files, no spaghetti.

From here, the next steps are wiring in your auth provider of choice, setting up your Stripe webhook handler in app/api/webhooks/stripe/route.ts, and building out your dashboard pages. Each of those is its own focused task — and now you have a solid foundation to do them on.

Happy building. 🚀