Full-Stack SaaS Dashboard with Next.js

A SaaS dashboard must not rely only on client-side checks such as hiding buttons or redirecting users after a component loads. If protected data is fetched before the auth check finishes, or if API routes do not verify the session independently, unauthorized users may still access sensitive endpoints. In a full-stack Next.js project, protection must exist at the route, server, and data-access layers.

Problematic approach:

          "use client";

          export default function DashboardPage() {
            const { user, loading } = useAuth();

            if (loading) {
              return <p>Loading...</p>;
            }

            if (!user) {
              redirect("/login");
            }

            return <Dashboard />;
          }

This protects the visible page after React runs, but it does not automatically protect API routes, server actions, or database queries. A user could still call an endpoint directly if that endpoint does not check authentication.

Better middleware-level protection:

          import { NextResponse } from "next/server";
          import type { NextRequest } from "next/server";

          export async function middleware(request: NextRequest) {
            const session = await getSessionFromRequest(request);

            const isDashboardRoute = request.nextUrl.pathname.startsWith("/dashboard");

            if (isDashboardRoute && !session) {
              const loginUrl = new URL("/login", request.url);

              return NextResponse.redirect(loginUrl);
            }

            return NextResponse.next();
          }

          export const config = {
            matcher: ["/dashboard/:path*", "/api/dashboard/:path*"]
          };

API route protection:

          export async function GET(request: Request) {
            const session = await requireUserSession(request);

            if (!session) {
              return Response.json(
                { message: "Unauthorized" },
                { status: 401 }
              );
            }

            const dashboardData = await getDashboardData({
              userId: session.user.id,
              teamId: session.team.id
            });

            return Response.json(dashboardData);
          }

Pay attention to: Protect the dashboard in several places: middleware for routes, server functions for data access, and API routes for every sensitive operation. Client-side redirects are useful for UX, but they are not enough for security.

SaaS dashboards often contain team-based or account-based data. A dangerous mistake is querying records only by ID and forgetting to check whether the current user belongs to the same team or tenant. This can create data leaks where one customer can access another customer's projects, invoices, users, or analytics by changing an ID in the URL.

Problematic query:

          export async function getProject(projectId: string) {
            return db.project.findUnique({
              where: {
                id: projectId
              }
            });
          }

This function answers the question “does this project exist?” but not “does this user have permission to view this project?”

Better tenant-scoped query:

          export async function getProjectForUser(params: {
            projectId: string;
            teamId: string;
          }) {
            return db.project.findFirst({
              where: {
                id: params.projectId,
                teamId: params.teamId
              }
            });
          }

Server action example:

          export async function updateProjectStatus(input: {
            projectId: string;
            status: "active" | "paused" | "completed";
          }) {
            const session = await requireSession();

            const project = await getProjectForUser({
              projectId: input.projectId,
              teamId: session.team.id
            });

            if (!project) {
              throw new Error("Project not found");
            }

            return db.project.update({
              where: {
                id: project.id
              },
              data: {
                status: input.status
              }
            });
          }

Pay attention to: Every dashboard query should be scoped by the authenticated user's account, team, workspace, or organization. Never trust a record ID by itself.

Dashboard metrics should be reliable. A common mistake is loading a large list of records into the browser and calculating all totals, charts, and summary cards on the client. This can be acceptable for a prototype, but it becomes slow and inconsistent as data grows. It can also expose more raw data than the current view actually needs.

Problematic approach:

          "use client";

          export function DashboardMetrics({ projects }) {
            const totalProjects = projects.length;

            const activeProjects = projects.filter((project) => {
              return project.status === "active";
            }).length;

            const completedProjects = projects.filter((project) => {
              return project.status === "completed";
            }).length;

            return (
              <MetricGrid
                total={totalProjects}
                active={activeProjects}
                completed={completedProjects}
              />
            );
          }

This forces the client to receive every project record before it can show simple counts. For large dashboards, this becomes inefficient.

Better server-side aggregation:

          export async function getDashboardMetrics(teamId: string) {
            const [totalProjects, activeProjects, completedProjects] = await Promise.all([
              db.project.count({
                where: { teamId }
              }),
              db.project.count({
                where: { teamId, status: "active" }
              }),
              db.project.count({
                where: { teamId, status: "completed" }
              })
            ]);

            return {
              totalProjects,
              activeProjects,
              completedProjects
            };
          }

Typed dashboard response:

          export interface DashboardMetricsDto {
            totalProjects: number;
            activeProjects: number;
            completedProjects: number;
            conversionRate: number;
          }

          export async function DashboardPage() {
            const session = await requireSession();
            const metrics = await getDashboardMetrics(session.team.id);

            return <DashboardOverview metrics={metrics} />;
          }

Pay attention to: Let the server or database prepare dashboard summaries. Send the client exactly what it needs for cards, charts, and tables instead of exposing and recalculating large raw datasets in the browser.

SaaS billing is not finished when the user returns from Stripe Checkout. A subscription can be created, updated, canceled, renewed, failed, or paused after the redirect. If your app updates subscription status only on the checkout success page, the dashboard may show the wrong plan. Real billing state should be synchronized through webhooks and processed idempotently.

Problematic approach:

          export default async function CheckoutSuccessPage() {
            const session = await requireSession();

            await db.team.update({
              where: {
                id: session.team.id
              },
              data: {
                plan: "pro"
              }
            });

            return <p>Subscription activated!</p>;
          }

This assumes that reaching the success page means the subscription is fully valid. It also ignores future billing events such as cancellation or failed payment.

Better webhook structure:

          export async function POST(request: Request) {
            const body = await request.text();
            const signature = request.headers.get("stripe-signature");

            const event = stripe.webhooks.constructEvent(
              body,
              signature,
              process.env.STRIPE_WEBHOOK_SECRET
            );

            if (event.type === "checkout.session.completed") {
              await syncCheckoutSession(event.data.object);
            }

            if (event.type === "customer.subscription.updated") {
              await syncSubscription(event.data.object);
            }

            if (event.type === "customer.subscription.deleted") {
              await markSubscriptionCanceled(event.data.object);
            }

            return Response.json({ received: true });
          }

Idempotency guard:

          async function processStripeEvent(eventId: string, handler: () => Promise<void>) {
            const existingEvent = await db.stripeEvent.findUnique({
              where: { id: eventId }
            });

            if (existingEvent) {
              return;
            }

            await handler();

            await db.stripeEvent.create({
              data: {
                id: eventId,
                processedAt: new Date()
              }
            });
          }

Pay attention to: Subscription state should come from trusted billing events, not from a client redirect. Store Stripe customer IDs, subscription IDs, current plan, status, and processed event IDs.

SaaS dashboards are full of tables, charts, cards, filters, and user actions. A frequent mistake is designing only the “data exists” state. But real dashboards must handle first-time users with no data, restricted users with limited permissions, slow API responses, failed requests, and filtered tables that return no rows.

Problematic rendering:

          export function ProjectsTable({ projects }) {
            return (
              <table>
                <tbody>
                  {projects.map((project) => (
                    <tr key={project.id}>
                      <td>{project.name}</td>
                      <td>{project.status}</td>
                      <td>{project.createdAt}</td>
                    </tr>
                  ))}
                </tbody>
              </table>
            );
          }

If projects is empty, the table becomes blank. If the user does not have permission to create projects, the UI may still show a button they cannot use.

Better state-aware component:

          export function ProjectsSection({
            projects,
            loading,
            error,
            canCreateProject
          }) {
            if (loading) {
              return <DashboardTableSkeleton rows={6} />;
            }

            if (error) {
              return (
                <DashboardAlert
                  title="Projects could not be loaded"
                  description="Refresh the page or try again later."
                />
              );
            }

            if (!projects.length) {
              return (
                <EmptyState
                  title="No projects yet"
                  description="Create your first project to start seeing dashboard metrics."
                  action={
                    canCreateProject
                      ? { label: "Create project", href: "/dashboard/projects/new" }
                      : null
                  }
                />
              );
            }

            return <ProjectsTable projects={projects} />;
          }

Permission-aware action:

          function ProjectActions({ project, permissions }) {
            return (
              <div>
                {permissions.canEditProject && (
                  <Button href={`/dashboard/projects/${project.id}/edit`}>
                    Edit
                  </Button>
                )}

                {permissions.canDeleteProject && (
                  <DeleteProjectButton projectId={project.id} />
                )}
              </div>
            );
          }

Pay attention to: Dashboards need complete UI states. Design loading, error, empty, restricted, and filtered-empty states before the interface becomes large.