DEV Community: Esimit Karlgusta

Google OAuth + Email Auth in Next.js — The Complete SaaS Authentication Guide (2026)

Esimit Karlgusta — Tue, 24 Mar 2026 14:32:00 +0000

Category: Authentication and Security
Primary Keyword: Google OAuth email authentication Next.js SaaS
Level: Beginner to Intermediate

Authentication is the front door of your SaaS. Get it wrong and users can't get in — or worse, the wrong users get in. Get it right and it becomes invisible: a smooth, trusted experience that sets the tone for everything that follows.

This guide covers the full authentication setup for a Next.js App Router SaaS: email and password login, Google OAuth, session management, protected routes, and secure API access. By the end, you'll have a production-ready auth layer you can drop into any project.

Why Authentication Is More Than Just a Login Form

Most tutorials show you how to render a login form. But in a real SaaS, authentication touches nearly every layer of your app:

Signup — creating a user record in your database
Login — verifying credentials and issuing a session
OAuth — delegating identity verification to Google
Session — persisting who is logged in across requests
Route protection — blocking unauthenticated access to the dashboard
API protection — securing your backend routes from anonymous requests
Role handling — distinguishing free users from paid subscribers

NextAuth.js (now Auth.js) handles most of this out of the box. Your job is to configure it correctly and wire it to your database and UI.

Setting Up NextAuth.js in the App Router

Start by installing the required packages:

npm install next-auth@beta @auth/mongodb-adapter mongoose bcryptjs

Note: Use next-auth@beta for full App Router support. The stable v4 has limited support for the App Router's server components and route handlers.

Create your auth configuration file:

// lib/authOptions.js
import NextAuth from 'next-auth';
import GoogleProvider from 'next-auth/providers/google';
import CredentialsProvider from 'next-auth/providers/credentials';
import { MongoDBAdapter } from '@auth/mongodb-adapter';
import clientPromise from '@/lib/mongodbClient';
import connectDB from '@/lib/mongodb';
import User from '@/models/User';
import bcrypt from 'bcryptjs';

export const authOptions = {
  adapter: MongoDBAdapter(clientPromise),
  providers: [
    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    }),
    CredentialsProvider({
      name: 'credentials',
      credentials: {
        email: { label: 'Email', type: 'email' },
        password: { label: 'Password', type: 'password' },
      },
      async authorize(credentials) {
        await connectDB();
        const user = await User.findOne({ email: credentials.email });
        if (!user || !user.password) return null;

        const isValid = await bcrypt.compare(credentials.password, user.password);
        if (!isValid) return null;

        return { id: user._id.toString(), email: user.email, name: user.name };
      },
    }),
  ],
  session: { strategy: 'jwt' },
  callbacks: {
    async jwt({ token, user }) {
      if (user) token.id = user.id;
      return token;
    },
    async session({ session, token }) {
      if (token) session.user.id = token.id;
      return session;
    },
  },
  pages: {
    signIn: '/auth/login',
    error: '/auth/error',
  },
  secret: process.env.NEXTAUTH_SECRET,
};

export const { handlers, auth, signIn, signOut } = NextAuth(authOptions);

Then expose the route handler:

// app/api/auth/[...nextauth]/route.js
import { handlers } from '@/lib/authOptions';
export const { GET, POST } = handlers;

This single file handles every auth request — login, logout, OAuth callbacks, session checks — automatically.

Configuring Environment Variables

Add these to your .env.local:

NEXTAUTH_URL=http://localhost:3000
NEXTAUTH_SECRET=your_random_secret_here

GOOGLE_CLIENT_ID=your_google_client_id
GOOGLE_CLIENT_SECRET=your_google_client_secret

MONGODB_URI=mongodb+srv://...

To generate a secure NEXTAUTH_SECRET:

openssl rand -base64 32

For GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET, head to console.cloud.google.com, create a project, enable the Google OAuth API, and add http://localhost:3000/api/auth/callback/google as an authorized redirect URI.

The User Model: Bridging Auth and Your Database

NextAuth's MongoDB adapter automatically creates accounts, sessions, and verification_tokens collections. But you also need a users collection that your app controls — for subscription status, preferences, and other SaaS-specific data.

// models/User.js
import mongoose from 'mongoose';

const UserSchema = new mongoose.Schema(
  {
    name: { type: String },
    email: { type: String, required: true, unique: true },
    password: { type: String }, // null for OAuth users
    image: { type: String },
    stripeCustomerId: { type: String },
    subscriptionStatus: {
      type: String,
      enum: ['active', 'past_due', 'canceled', 'trialing', null],
      default: null,
    },
    role: { type: String, enum: ['user', 'admin'], default: 'user' },
  },
  { timestamps: true }
);

export default mongoose.models.User || mongoose.model('User', UserSchema);

Key design decision: OAuth users have no password field. Email users have a hashed password. Your authorize function in CredentialsProvider checks for user.password before attempting bcrypt comparison — this prevents OAuth-only accounts from logging in via the credentials form.

Building the Signup Flow for Email Users

OAuth handles its own user creation automatically. For email/password, you need a signup API route:

// app/api/auth/signup/route.js
import connectDB from '@/lib/mongodb';
import User from '@/models/User';
import bcrypt from 'bcryptjs';

export async function POST(req) {
  await connectDB();
  const { name, email, password } = await req.json();

  if (!email || !password || password.length < 8) {
    return Response.json({ error: 'Invalid input' }, { status: 400 });
  }

  const existing = await User.findOne({ email });
  if (existing) {
    return Response.json({ error: 'Email already registered' }, { status: 409 });
  }

  const hashed = await bcrypt.hash(password, 12);
  await User.create({ name, email, password: hashed });

  return Response.json({ success: true }, { status: 201 });
}

A few things worth noting here:

Always hash passwords with bcrypt before storing. Never store plaintext.
Salt rounds of 12 is the current recommended minimum for production.
Return generic errors on failure — don't confirm whether an email exists to prevent enumeration attacks.

Building the Login and Signup UI

With NextAuth configured, your login page just needs to call signIn:

// app/auth/login/page.jsx
'use client';
import { signIn } from 'next-auth/react';
import { useState } from 'react';
import { useRouter } from 'next/navigation';

export default function LoginPage() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [error, setError] = useState('');
  const router = useRouter();

  async function handleEmailLogin(e) {
    e.preventDefault();
    const result = await signIn('credentials', {
      email,
      password,
      redirect: false,
    });

    if (result?.error) {
      setError('Invalid email or password');
    } else {
      router.push('/dashboard');
    }
  }

  return (
    <div className="min-h-screen flex items-center justify-center bg-base-200">
      <div className="card w-full max-w-sm shadow-xl bg-base-100">
        <div className="card-body">
          <h2 className="card-title text-2xl font-bold">Sign in</h2>

          {error && <div className="alert alert-error text-sm">{error}</div>}

          <form onSubmit={handleEmailLogin} className="flex flex-col gap-3">
            <input
              type="email"
              placeholder="Email"
              className="input input-bordered"
              value={email}
              onChange={(e) => setEmail(e.target.value)}
              required
            />
            <input
              type="password"
              placeholder="Password"
              className="input input-bordered"
              value={password}
              onChange={(e) => setPassword(e.target.value)}
              required
            />
            <button type="submit" className="btn btn-primary">
              Sign in with Email
            </button>
          </form>

          <div className="divider">OR</div>

          <button
            onClick={() => signIn('google', { callbackUrl: '/dashboard' })}
            className="btn btn-outline gap-2"
          >
            <svg className="w-5 h-5" viewBox="0 0 24 24">
              <path fill="#4285F4" d="M22.56 12.25c0-.78-.07-1.53-.2-2.25H12v4.26h5.92c-.26 1.37-1.04 2.53-2.21 3.31v2.77h3.57c2.08-1.92 3.28-4.74 3.28-8.09z"/>
              <path fill="#34A853" d="M12 23c2.97 0 5.46-.98 7.28-2.66l-3.57-2.77c-.98.66-2.23 1.06-3.71 1.06-2.86 0-5.29-1.93-6.16-4.53H2.18v2.84C3.99 20.53 7.7 23 12 23z"/>
              <path fill="#FBBC05" d="M5.84 14.09c-.22-.66-.35-1.36-.35-2.09s.13-1.43.35-2.09V7.07H2.18C1.43 8.55 1 10.22 1 12s.43 3.45 1.18 4.93l2.85-2.22.81-.62z"/>
              <path fill="#EA4335" d="M12 5.38c1.62 0 3.06.56 4.21 1.64l3.15-3.15C17.45 2.09 14.97 1 12 1 7.7 1 3.99 3.47 2.18 7.07l3.66 2.84c.87-2.6 3.3-4.53 6.16-4.53z"/>
            </svg>
            Continue with Google
          </button>

          <p className="text-center text-sm mt-2">
            Don't have an account?{' '}
            <a href="/auth/signup" className="link link-primary">Sign up</a>
          </p>
        </div>
      </div>
    </div>
  );
}

This gives you a clean DaisyUI login card with both authentication methods, error handling, and a redirect to the dashboard on success.

Protecting Routes with Middleware

The cleanest way to protect your dashboard is with Next.js middleware. It runs before any page renders and can redirect unauthenticated users server-side:

// middleware.js (root of project)
import { auth } from '@/lib/authOptions';

export default auth((req) => {
  const isLoggedIn = !!req.auth;
  const isOnDashboard = req.nextUrl.pathname.startsWith('/dashboard');

  if (isOnDashboard && !isLoggedIn) {
    return Response.redirect(new URL('/auth/login', req.nextUrl));
  }
});

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

This is a single file that silently redirects any unauthenticated request to /dashboard to the login page — before a single byte of the dashboard renders. No client-side flicker, no layout shift.

Securing API Routes

For API routes in your SaaS backend, check the session at the top of every handler:

// app/api/user/profile/route.js
import { getServerSession } from 'next-auth';
import { authOptions } from '@/lib/authOptions';
import connectDB from '@/lib/mongodb';
import User from '@/models/User';

export async function GET(req) {
  const session = await getServerSession(authOptions);
  if (!session) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  await connectDB();
  const user = await User.findOne({ email: session.user.email }).select('-password');

  return Response.json({ user });
}

Always exclude the password field when returning user data. The .select('-password') Mongoose modifier ensures it never leaves your server.

How This Fits Into the Zero to SaaS Journey

Authentication is the second major milestone in building a SaaS — right after project setup and right before connecting your database and billing layer. Without it, you can't identify who your users are, protect their data, or gate features behind a subscription.

If you're working through the Zero to SaaS course, this is where things start feeling real. You have a login page, a Google OAuth button, and a dashboard that only authenticated users can see. That's a real product foundation.

Once auth is working, the next step is wiring up Stripe subscriptions so you can start charging for access. Check out Build SaaS with Next.js and Stripe to continue the journey, or start from the beginning with the full Next.js SaaS tutorial.

Common Mistakes to Avoid

1. Using strategy: 'database' with the App Router
Database sessions require the adapter on every request, which adds latency. Use strategy: 'jwt' for serverless environments like Vercel — it's faster and scales better.

2. Not hashing passwords
This one is obvious but still happens. Always use bcrypt. Never MD5, never SHA-1, never plaintext.

3. Allowing credential login for OAuth-only accounts
If a user signed up with Google, they have no password. Your authorize function must check for user.password before calling bcrypt.compare, or it will throw a runtime error.

4. Forgetting to add the callback URL to Google Cloud Console
For production, you must add https://yourdomain.com/api/auth/callback/google to the authorized redirect URIs in Google Cloud. Missing this is the number one reason OAuth fails after deployment.

5. Exposing session data on the client without filtering
The JWT callback adds token.id to the session. Be deliberate about what ends up in the session object — don't forward sensitive fields like subscription details or internal IDs that clients don't need.

Pro Tips for Production

Add email verification for new email signups using NextAuth's built-in email provider or a service like Resend.
Rate limit your signup and login routes to prevent brute force attacks. Upstash Redis with @upstash/ratelimit is a clean serverless solution.
Set httpOnly and secure cookie flags — NextAuth does this by default in production when NEXTAUTH_URL uses HTTPS.
Log auth events — failed logins and new signups are worth tracking. Wire events.signIn and events.createUser in your NextAuth config to a logging service.
Test OAuth locally with ngrok if you need a real HTTPS callback URL for development.

Real-World Example: DevTrack SaaS

You're building DevTrack — a time tracking SaaS for freelance developers. Here's how auth plays out for two different users:

User A — Sarah (Google OAuth):
Sarah clicks "Continue with Google," approves the OAuth consent screen, and lands on the dashboard. NextAuth creates her user record automatically via the MongoDB adapter. No password stored. Her name and image are pulled from her Google profile.

User B — James (Email/Password):
James fills out the signup form with his email and a password. Your API route hashes it with bcrypt and saves it to MongoDB. He then logs in with those credentials. NextAuth's CredentialsProvider verifies the hash and issues a JWT session.

Both users end up with a session that contains { id, email, name }. Your dashboard doesn't need to care how they authenticated — it just checks session.user.

Action Plan: What to Build Next

✅ Install next-auth@beta, @auth/mongodb-adapter, and bcryptjs
✅ Create lib/authOptions.js with Google and Credentials providers
✅ Add all required environment variables to .env.local
✅ Set up Google OAuth credentials in Google Cloud Console
✅ Build the signup API route with bcrypt hashing
✅ Create the login page with email form and Google button
✅ Add middleware to protect /dashboard routes
✅ Secure all API routes with getServerSession
🔜 Add email verification for new signups
🔜 Connect auth to your subscription status check

Wrapping Up

Authentication in a Next.js SaaS isn't complicated — but it has a lot of moving parts that need to work together. You now have both email/password and Google OAuth wired up, a MongoDB-backed user model, protected routes via middleware, and secure API handlers.

The pattern is consistent across every route and component: get the session, check it exists, use it to identify the user. Everything else — subscriptions, dashboards, roles — builds on top of this foundation.

If you want to build this complete authentication layer as part of a full SaaS app — including Stripe billing, a Tailwind dashboard, and deployment to Vercel — the Zero to SaaS course walks you through it all, step by step.

The door is open. Let your users in.

Stripe Subscription Lifecycle in Next.js — The Complete Developer Guide (2026)

Esimit Karlgusta — Tue, 17 Mar 2026 13:26:46 +0000

Category: Stripe Payments and Billing
Primary Keyword: Stripe subscription lifecycle Next.js
Level: Intermediate

Most tutorials show you how to add Stripe to a Next.js app. Few show you what happens after the user subscribes — the renewals, failures, cancellations, and recovery flows that make or break a real SaaS business.

This guide walks you through the complete Stripe subscription lifecycle: from checkout session to webhook handling, customer portal integration, and automated churn recovery. If you're building a production SaaS, this is the article you wish you had on day one.

Why the Lifecycle Matters More Than the Checkout

When developers first integrate Stripe, they focus on the checkout form. Makes sense — you want to see money coming in. But a SaaS business lives and dies by what happens between payments.

Here's the reality of a subscription over 12 months:

A user subscribes (checkout)
Stripe charges them monthly (renewals)
A card expires or gets declined (payment failure)
Stripe retries and sends dunning emails (recovery)
The user wants to upgrade or downgrade (plan change)
The user cancels (churn)
The subscription ends at period end (access revocation)

If your app doesn't handle each of these events, you'll have users with broken access, missed revenue, and no way to debug any of it. Let's fix that.

Setting Up: What You Need Before Writing Code

Before diving into webhooks and lifecycle events, make sure your Next.js project has these pieces in place:

Stripe account with at least one Product and Price created in the dashboard
Stripe Node SDK installed: npm install stripe
Environment variables configured:

STRIPE_SECRET_KEY=sk_live_...
STRIPE_WEBHOOK_SECRET=whsec_...
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_live_...

A users collection in MongoDB with a field for stripeCustomerId and subscriptionStatus

Your user schema in Mongoose might look like this:

// models/User.js
import mongoose from 'mongoose';

const UserSchema = new mongoose.Schema({
  email: { type: String, required: true, unique: true },
  stripeCustomerId: { type: String },
  subscriptionId: { type: String },
  subscriptionStatus: {
    type: String,
    enum: ['active', 'past_due', 'canceled', 'trialing', 'incomplete', null],
    default: null,
  },
  currentPeriodEnd: { type: Date },
});

export default mongoose.models.User || mongoose.model('User', UserSchema);

This schema is the source of truth your app reads from. Stripe is the source of truth Stripe reads from. Your webhooks keep them in sync.

Step 1 — Creating the Checkout Session

When a user clicks "Subscribe," you create a Stripe Checkout Session via a Server Action or API route.

// app/api/stripe/checkout/route.js
import Stripe from 'stripe';
import { getServerSession } from 'next-auth';
import { authOptions } from '@/lib/authOptions';
import User from '@/models/User';
import connectDB from '@/lib/mongodb';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

export async function POST(req) {
  await connectDB();
  const session = await getServerSession(authOptions);
  if (!session) return new Response('Unauthorized', { status: 401 });

  const user = await User.findOne({ email: session.user.email });

  // Create or retrieve the Stripe customer
  let customerId = user.stripeCustomerId;
  if (!customerId) {
    const customer = await stripe.customers.create({ email: user.email });
    customerId = customer.id;
    await User.updateOne({ email: user.email }, { stripeCustomerId: customerId });
  }

  const checkoutSession = await stripe.checkout.sessions.create({
    customer: customerId,
    payment_method_types: ['card'],
    mode: 'subscription',
    line_items: [{ price: process.env.STRIPE_PRICE_ID, quantity: 1 }],
    success_url: `${process.env.NEXT_PUBLIC_APP_URL}/dashboard?success=true`,
    cancel_url: `${process.env.NEXT_PUBLIC_APP_URL}/pricing`,
  });

  return Response.json({ url: checkoutSession.url });
}

Key point: Always attach a customer ID to the session. This links the Stripe customer to your user record and makes every downstream webhook event traceable back to a user in your database.

Step 2 — Handling Webhooks: The Heart of the Lifecycle

Webhooks are how Stripe tells your app what happened. You don't poll Stripe — Stripe calls you. This means your webhook endpoint must be fast, idempotent, and reliable.

Here's the webhook handler that covers the full subscription lifecycle:

// app/api/stripe/webhook/route.js
import Stripe from 'stripe';
import { headers } from 'next/headers';
import connectDB from '@/lib/mongodb';
import User from '@/models/User';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

export async function POST(req) {
  const body = await req.text();
  const signature = headers().get('stripe-signature');

  let event;
  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET
    );
  } catch (err) {
    return new Response(`Webhook error: ${err.message}`, { status: 400 });
  }

  await connectDB();

  switch (event.type) {
    case 'checkout.session.completed': {
      const session = event.data.object;
      await User.updateOne(
        { stripeCustomerId: session.customer },
        { subscriptionId: session.subscription, subscriptionStatus: 'active' }
      );
      break;
    }

    case 'invoice.paid': {
      const invoice = event.data.object;
      const subscription = await stripe.subscriptions.retrieve(invoice.subscription);
      await User.updateOne(
        { stripeCustomerId: invoice.customer },
        {
          subscriptionStatus: 'active',
          currentPeriodEnd: new Date(subscription.current_period_end * 1000),
        }
      );
      break;
    }

    case 'invoice.payment_failed': {
      await User.updateOne(
        { stripeCustomerId: event.data.object.customer },
        { subscriptionStatus: 'past_due' }
      );
      // Optionally: trigger email notification here
      break;
    }

    case 'customer.subscription.deleted': {
      await User.updateOne(
        { stripeCustomerId: event.data.object.customer },
        { subscriptionStatus: 'canceled', subscriptionId: null }
      );
      break;
    }

    case 'customer.subscription.updated': {
      const sub = event.data.object;
      await User.updateOne(
        { stripeCustomerId: sub.customer },
        {
          subscriptionStatus: sub.status,
          currentPeriodEnd: new Date(sub.current_period_end * 1000),
        }
      );
      break;
    }
  }

  return new Response(JSON.stringify({ received: true }), { status: 200 });
}

The Five Events You Must Handle

Event	What It Means	What You Do
`checkout.session.completed`	User subscribed	Activate account
`invoice.paid`	Renewal succeeded	Extend `currentPeriodEnd`
`invoice.payment_failed`	Card declined	Set status to `past_due`
`customer.subscription.deleted`	Sub canceled or expired	Revoke access
`customer.subscription.updated`	Plan changed or paused	Sync status and dates

Missing any of these means your database will drift out of sync with Stripe — and users will either have access they shouldn't, or lose access they paid for.

Step 3 — Protecting Routes Based on Subscription Status

Once your webhook is syncing subscription status to MongoDB, protecting routes is straightforward. In your middleware or layout server component, check the user's subscriptionStatus:

// lib/getSubscriptionStatus.js
import { getServerSession } from 'next-auth';
import { authOptions } from '@/lib/authOptions';
import User from '@/models/User';
import connectDB from '@/lib/mongodb';

export async function getSubscriptionStatus() {
  await connectDB();
  const session = await getServerSession(authOptions);
  if (!session) return null;

  const user = await User.findOne({ email: session.user.email });
  return user?.subscriptionStatus ?? null;
}

In your dashboard layout:

// app/dashboard/layout.js
import { redirect } from 'next/navigation';
import { getSubscriptionStatus } from '@/lib/getSubscriptionStatus';

export default async function DashboardLayout({ children }) {
  const status = await getSubscriptionStatus();

  if (status !== 'active' && status !== 'trialing') {
    redirect('/pricing?reason=inactive');
  }

  return <>{children}</>;
}

This is clean, server-side, and requires zero client JavaScript. The redirect happens before the page renders.

Step 4 — The Customer Portal: Self-Service Billing

Instead of building a custom cancel or upgrade flow, use Stripe's hosted Customer Portal. It handles plan changes, payment method updates, and cancellations out of the box.

// app/api/stripe/portal/route.js
import Stripe from 'stripe';
import { getServerSession } from 'next-auth';
import { authOptions } from '@/lib/authOptions';
import User from '@/models/User';
import connectDB from '@/lib/mongodb';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

export async function POST(req) {
  await connectDB();
  const session = await getServerSession(authOptions);
  const user = await User.findOne({ email: session.user.email });

  const portalSession = await stripe.billingPortal.sessions.create({
    customer: user.stripeCustomerId,
    return_url: `${process.env.NEXT_PUBLIC_APP_URL}/dashboard/billing`,
  });

  return Response.json({ url: portalSession.url });
}

Add a "Manage Billing" button in your dashboard that calls this endpoint and redirects:

'use client';
async function openPortal() {
  const res = await fetch('/api/stripe/portal', { method: 'POST' });
  const { url } = await res.json();
  window.location.href = url;
}

<button onClick={openPortal} className="btn btn-outline">
  Manage Billing
</button>

When a user cancels through the portal, Stripe fires customer.subscription.updated (with cancel_at_period_end: true) and eventually customer.subscription.deleted — both of which your webhook already handles.

How This Fits Into the Zero to SaaS Journey

The subscription lifecycle is where your SaaS becomes a real business. Authentication gets users in the door. The dashboard keeps them engaged. But billing is where value exchange happens — and where most indie SaaS apps break down in subtle, expensive ways.

If you're following the Zero to SaaS course, this lesson sits at the midpoint: after authentication and database setup, before deployment. Getting this right before you ship means you won't be debugging ghost subscriptions at 2am after your first launch.

For a deeper look at setting up subscriptions from scratch, check out Stripe Subscriptions in Next.js and Build SaaS with Next.js and Stripe.

Common Mistakes to Avoid

1. Not verifying webhook signatures
Always use stripe.webhooks.constructEvent(). Without this, anyone can POST to your webhook endpoint and fake events.

2. Using checkout.session.completed as the only activation trigger
Checkout fires once. invoice.paid fires every renewal. If you only listen to checkout, your users lose access after the first billing cycle.

3. Storing subscription data only in Stripe
Your app should have a local copy of subscription status. Querying Stripe on every request adds latency and rate limit risk.

4. Not handling cancel_at_period_end
When a user cancels, Stripe sets this flag to true but keeps the subscription active until the period ends. If you immediately revoke access on cancel, you're giving a worse experience than Stripe's own dashboard promises the user.

5. Forgetting to test with the Stripe CLI
Run stripe listen --forward-to localhost:3000/api/stripe/webhook locally. Without this, you'll be deploying blind.

Pro Tips for Production

Idempotency: Stripe can send the same event more than once. Use event.id to deduplicate if needed.
Retry tolerance: Your webhook handler must return 200 quickly. Move heavy work (emails, database jobs) to a background queue.
Monitor failed webhooks: Stripe Dashboard > Developers > Webhooks shows every delivery attempt and failure reason. Check it after every deploy.
Grace period logic: Give past_due users 3–5 days before revoking access. Stripe's Smart Retries often recover these automatically.

Real-World Example: TaskFlow SaaS

Imagine you're building TaskFlow — a project management SaaS with a $19/month Pro plan.

A user named Marcus subscribes on March 1st. Here's what your system processes over the next 60 days:

March 1 — checkout.session.completed → Marcus's status set to active, currentPeriodEnd = April 1
April 1 — invoice.paid → Status remains active, currentPeriodEnd updated to May 1
May 1 — invoice.payment_failed → Card expired. Status → past_due. Stripe retries on May 4, May 8
May 8 — invoice.paid (retry success) → Status back to active
May 20 — Marcus opens portal, cancels. customer.subscription.updated fires with cancel_at_period_end: true
June 1 — customer.subscription.deleted → Status → canceled. Dashboard access removed.

Every step is automatic. Zero manual intervention. That's the power of a properly wired lifecycle.

Action Plan: What to Build Next

✅ Create a Stripe Product and Price in your dashboard
✅ Add stripeCustomerId and subscriptionStatus fields to your User model
✅ Build the /api/stripe/checkout route
✅ Deploy the webhook handler and verify with Stripe CLI
✅ Add subscription status check to your dashboard layout
✅ Wire up the Customer Portal endpoint
🔜 Add an email notification on invoice.payment_failed
🔜 Build a usage dashboard showing currentPeriodEnd

Wrapping Up

The Stripe subscription lifecycle isn't just a technical concern — it's your revenue pipeline. Every event maps to a moment in your customer's journey, and how you handle each one determines whether your SaaS feels professional or broken.

You now have the complete picture: checkout, renewals, failures, recovery, plan changes, and cancellations — all wired to your Next.js App Router app through a single, robust webhook handler.

If you want to go deeper and build this end-to-end alongside a full SaaS app — with authentication, a MongoDB backend, Tailwind UI, and Vercel deployment — the Zero to SaaS course walks you through every step in sequence, with real code and real decisions.

The billing layer is ready. Time to ship.

Beyond find(): Mastering MongoDB Aggregations for Real-Time SaaS Analytics

Esimit Karlgusta — Tue, 24 Feb 2026 09:04:22 +0000

Every successful SaaS reaches a point where simple CRUD operations are no longer enough. Your users want to see data: revenue growth, active user trends, or usage heatmaps. If you are fetching thousands of documents just to calculate a total in JavaScript, you are killing your application's performance.

In 2026, the senior-level approach is to push the computation to the database. By mastering MongoDB Aggregation Pipelines, you can transform millions of raw data points into actionable insights in milliseconds.

The Problem with Client-Side Logic

Imagine you have 50,000 transaction records. You want to display a chart of "Monthly Recurring Revenue (MRR) per Region."

The Junior Way: Fetch all 50,000 docs to the frontend, loop through them, and group by region. This will crash the user's browser and eat your bandwidth.
The Senior Way: Use an aggregation pipeline to filter, group, and sum the data directly on the database server, returning only the final 5-10 rows.

Deep Dive: Anatomy of a SaaS Analytics Pipeline

A powerful aggregation pipeline is built in stages. Here is how you should structure your queries for maximum efficiency.

1. The $match Stage (The Filter)

Always filter as early as possible. If you only need data from the last 30 days, discard everything else first to reduce the memory footprint of the remaining stages.

2. The $group Stage (The Engine)

This is where the magic happens. You can group by a specific field (like planId\) and use accumulators like $sum\, $avg\, or $max\.

3. The $project Stage (The Refinement)

Don't return the raw MongoDB structure. Use $project\ to rename fields and format data so it is ready for your frontend charting library (like Recharts or Chart.js) without further manipulation.

Key Benefits of Aggregation

Feature	Impact	Why It Matters
Server-Side Compute	Low Latency	Users get data-heavy dashboards instantly.
Reduced Payload	Saved Bandwidth	Mobile users won't drain data loading your app.
Complex Logic	Clean Code	Keep your Next.js API routes small and readable.

3 Pro-Level Aggregation Patterns

A. Calculating Churn Rate in One Query

You can use a $facet\ stage to run multiple pipelines simultaneously—one counting total users and another counting users with a canceled\ status—to calculate your churn percentage in a single trip to the database.

B. Time-Series Bucketization

Use the $bucket\ or $dateTrunc\ operators to group events into days, weeks, or months. This is essential for building "Growth Over Time" line graphs.

C. Join Logic with $lookup

While MongoDB is NoSQL, you often need to join collections (e.g., joining Transactions\ with UserProfiles\). The $lookup\ stage acts as your "Left Outer Join," allowing you to pull in related data seamlessly.

How SassyPack Helps

SassyPack doesn't just store data; it teaches you how to use it. Our advanced MERN performance optimization and scaling guide includes a library of battle-tested aggregation snippets for common SaaS metrics.

By using the SassyPack architecture for scalable workflows, you ensure that your analytics dashboard remains performant even as your events\ collection grows into the millions.

Action Plan: Optimize Your Dashboard Today

Identify Slow Queries: Use the MongoDB Atlas Profiler to find any query taking longer than 100ms.
Convert Loops to Aggregations: Find one place where you are .map()\ing over a large array to calculate a total and move it to a $group\ pipeline.
Use Indexes: Ensure every field used in a $match\ or $sort\ stage is properly indexed.

Conclusion

Your database is more than a bucket for JSON; it is a powerful computational engine. When you master aggregations, you unlock the ability to provide the "Big Data" insights that enterprise clients demand.

Stop wasting CPU cycles. Build a smarter, faster SaaS with SassyPack.

Stop Building Your Own Auth and Billing: Why You Are Actually Losing Money

Esimit Karlgusta — Tue, 24 Feb 2026 08:59:07 +0000

Stop Building Your Own Auth and Billing: Why You Are Actually Losing Money

It happens to the best of us. You have a killer SaaS idea. You open your IDE, initialize a new git repo, and start coding. But instead of building the feature that solves your customer's problem, you spend the next three nights configuring NextAuth.js, setting up Stripe webhooks, and fighting with PostgreSQL types.

Fast forward three weeks: you have a perfect login screen and a working "Manage Subscription" button, but zero users and zero core features.

In 2026, building your own boilerplate isn't "engineering excellence"—it is a form of procrastination.

The Architect's Debt

Every hour you spend on infrastructure that is identical across 99% of all SaaS apps is an hour you are not spending on your Unique Value Proposition (UVP). This is what I call "Architect's Debt."

When you build from scratch, you aren't just writing code; you are signing up for a lifetime of maintenance.

Who is monitoring your JWT rotation?
Who is updating your Stripe API version next year?
Who is fixing the hydration error in your mobile sidebar?

The "Ship First" Stack: MERN + Next.js

If you want to move from "Developer" to "Founder," you need a stack that favors velocity. The MERN stack (MongoDB, Express, React, Node.js) combined with Next.js is currently the most powerful engine for this.

Why this specific stack?

NoSQL Flexibility: MongoDB allows you to evolve your data schema as you find product-market fit without painful migrations.
Server Actions: Next.js eliminates the need for redundant boilerplate between your frontend and backend.
Edge Middleware: Security and redirects happen before the user even hits your server.

The 80/20 Rule of SaaS

80% of your SaaS code is "The Boring Stuff" (Auth, Billing, SEO, Emails).
20% is "The Secret Sauce" (Your actual product).

By using a starter kit like SassyPack, you start your project at the 80% mark. You aren't "cheating"; you are leveraging professional-grade scaffolding to ensure your foundation doesn't crumble when you hit your first 1,000 users.

How to Pivot Your Workflow Today

Stop Bikeshedding: It doesn't matter which CSS-in-JS library you use. Pick Tailwind and move on.
Use Managed Services: Don't host your own database. Use MongoDB Atlas. Don't build auth. Use a proven wrapper.
Focus on the "Aha!" Moment: What is the one thing your app does that makes a user say "Wow"? Build that first. Everything else should be a pre-built commodity.

Conclusion

The market doesn't care how beautiful your internal authentication middleware is. The market cares if you can solve its problems.

If you're ready to stop fighting your infrastructure and start shipping, check out SassyPack. It’s the boilerplate I built to ensure I never have to write a login form ever again.

What’s your take? Do you prefer building every layer yourself, or do you use a starter kit to get to market faster? Let's discuss in the comments.

From Todo App to Real SaaS in 2026: The RSC-First Playbook

Esimit Karlgusta — Tue, 17 Feb 2026 18:04:28 +0000

A Production-Ready Architecture Guide for Modern Next.js SaaS Builders

Introduction

You spend weeks building authentication and connecting your database. Then you realize your architecture cannot securely handle Stripe webhooks or scale MongoDB queries. You are exhausted and have not even built your core feature.

If you want a structured system instead of random tutorials, explore Zero to SaaS.

1. The Real Problem With Most SaaS Tutorials

Most tutorials teach Todo apps.

They skip:

Multi-tenant security
Subscription lifecycle management
Usage-based billing
Core Web Vitals optimization
Production deployment

2. The 2026 Shift: RSC-First Development

Modern SaaS products are built RSC-first using the Next.js App Router.

With this architecture:

The server handles sensitive logic
The client handles interaction
JavaScript bundles shrink
SEO improves automatically
Secrets never reach the browser

3. The Modern SaaS Stack

Next.js (App Router)
Tailwind CSS + DaisyUI
MongoDB
Stripe

If you want a guided technical walkthrough, see Build SaaS with Next.js and Stripe.

4. High-Intent Architecture With App Router

Static Landing Pages

Use Server Components for marketing pages.

Persistent Dashboard Layout

Create:

/dashboard/layout.tsx

Your sidebar persists. Only inner content updates.

Streaming UI

Add:

loading.tsx

Show instant skeleton states while data loads.

5. Database Layer: MongoDB + Server Actions

Use Server Actions instead of unnecessary API routes.

// app/dashboard/actions.ts
'use server'

import { dbConnect } from "@/lib/db";
import Project from "@/models/Project";
import { revalidatePath } from "next/cache";

export async function createProject(formData: FormData) {
  await dbConnect();
  const name = formData.get("name");

  const newProject = await Project.create({ 
    name, 
    ownerId: "user_123" 
  });

  revalidatePath("/dashboard");
  return { success: true };
}

6. Stripe Payment Lifecycle

Redirect users to Stripe Checkout
Create webhook at /api/webhook/stripe
Update subscription and usage in MongoDB

For a structured 14-day build roadmap, check Zero to SaaS 14 Day Course.

7. Deployment

Deploy using Vercel for seamless scaling.

8. Common Mistakes

Storing secrets in client components
Overcomplicating authentication
Ignoring hydration errors

9. Weekly Action Plan

Initialize Next.js project
Implement authentication
Build one core feature
Connect Stripe and handle webhooks

Ship clean. Ship scalable. Ship production-ready.

Why Zero to SaaS is the Best Alternative to CodeFast in 2026

Esimit Karlgusta — Wed, 11 Feb 2026 03:07:28 +0000

If you have spent any time in the indie hacker community lately, you have likely seen CodeFast—the "learn to code in 14 days" course that promise to turn anyone into a shipping machine. It is flashy, it is fast, and it is built by some of the most visible makers in the space.

But after helping hundreds of developers move from "tutorial hell" to "production reality," I have noticed a recurring pattern: Speed without structure leads to technical debt.

While CodeFast is great for a quick dopamine hit, if you are serious about building a sustainable, scalable business, there is a better way. Here is why Zero to SaaS has emerged as the premier alternative for developers who want to build products that last.

The Philosophy: Shipping vs. Scaling

The core difference between these two paths lies in their fundamental goal.

CodeFast is designed for the absolute sprint. It uses an "AI-first" approach that leans heavily on prompts to generate code. It is fantastic for moving fast, but it often leaves students with a "black box" application—they have a working product, but they don't truly understand why it works or how to fix it when the AI hallucinates.
Zero to SaaS is designed for the Full Lifecycle. It is workflow-driven. We don't just teach you how to prompt an AI to make a button; we teach you the Next.js App Router SaaS architecture required to handle complex data, multi-tenant security, and real-world performance.

1. Deep Dive vs. Surface Level

CodeFast’s 12-hour curriculum is impressive for its density, but it often skims over the "boring" parts that actually matter for a business: database indexing, secure middleware patterns, and subscription lifecycle management.

In Zero to SaaS, we take a more surgical approach to the stack:

Feature	CodeFast Approach	Zero to SaaS Approach
Architecture	Basic API routes	RSC-first (Server Components)
Database	Simple CRUD	Optimized MongoDB Schemas + Indexing
Payments	One-time/Basic Sub	Full Stripe Subscriptions in Next.js lifecycle
Logic	AI-generated snippets	Hand-crafted, modular Server Actions

2. The "AI Crutch" Problem

In 2026, AI is a requirement, not a feature. However, CodeFast treats AI as the primary developer. This works until you hit a bug that the AI can't solve.

Zero to SaaS teaches you to be the Architect. We use AI to accelerate our workflow, but the course is built around understanding the Next.js Course for Beginners fundamentals first. When your Stripe webhook fails at 3:00 AM, you won't be praying for a better prompt—you will know exactly which line in your route handler is causing the issue.

3. Real Production Workflows

CodeFast focuses on the "First 14 Days." But what happens on Day 15?

The Zero to SaaS curriculum includes:

Advanced Deployment: Going beyond "click to deploy" to understanding environment variables, build logs, and Vercel optimization.
Performance: How to achieve 100 Lighthouse scores so your landing page actually converts.
Security: Multi-role access and protecting sensitive API routes.

Why Zero to SaaS is the Better Choice for 2026

The "Vertical SaaS" wave is here. Developers are no longer building generic tools; they are building industry-specific CRMs, AI wrappers, and compliance tools. These require more than just a "shippable" script—they require a robust Build SaaS Dashboard Next.js Tailwind that can grow with the customer's needs.

Key Benefits of Choosing Zero to SaaS:

Future-Proofing: We focus exclusively on the latest Next.js App Router patterns, ensuring your code isn't legacy by the time you launch.
Scalability: Our MongoDB and Stripe patterns are designed for high-concurrency and complex billing models (like usage-based pricing).
Clarity: We replace "copy-paste" with "reason-and-implement."

Common Mistakes Beginners Make When Choosing a Course

Chasing the shortest timeline: A 14-day launch sounds great, but if the app breaks on Day 16, you haven't saved any time.
Ignoring the "Middle of the Funnel": Most courses teach you how to build a landing page and a login. They skip the actual dashboard logic where the value is created.
Stack Lock-in: Choosing a course that forces you into a proprietary boilerplate you don't own.

Final Verdict

If you want to build a "toy" or a very simple MVP to test an idea in a weekend, CodeFast is a solid choice. But if you want to Learn Full Stack SaaS Development and build a professional, secure, and scalable business, Zero to SaaS is the best alternative on the market today.

Your Action Plan:
Stop watching and start building. If you are ready to move from zero to a production-ready application with a mentor-led approach, check out the Zero to SaaS 14 Day Course.

Would you like me to help you map out a custom curriculum based on your specific SaaS idea?

How to Handle Stripe and Paystack Webhooks in Next.js (The App Router Way)

Esimit Karlgusta — Tue, 13 Jan 2026 04:01:08 +0000

The #1 reason developers struggle with SaaS payments is Webhook Signature Verification. You set everything up, the test payment goes through, but your server returns a 400 Bad Request or a Signature Verification Failed error.

In the Next.js App Router, the problem usually stems from how the request body is parsed. Stripe and Paystack require the raw request body to verify the signature, but Next.js often tries to be helpful by parsing it as JSON before you can get to it.

Here is the "Golden Pattern" for handling this in 2026.

1. The Route Handler Setup

Create a file at app/api/webhooks/route.ts. You must export a config object (if using older versions) or use the req.text() method in the App Router to prevent automatic parsing.

import { NextResponse } from "next/server";
import crypto from "crypto";

export async function POST(req: Request) {
  // 1. Get the raw body as text
  const body = await req.text();

  // 2. Grab the signature from headers
  const signature = req.headers.get("x-paystack-signature") || 
                    req.headers.get("stripe-signature");

  if (!signature) {
    return NextResponse.json({ error: "No signature" }, { status: 400 });
  }

  // 3. Verify the signature (Example for Paystack)
  const hash = crypto
    .createHmac("sha512", process.env.PAYSTACK_SECRET_KEY!)
    .update(body)
    .digest("hex");

  if (hash !== signature) {
    return NextResponse.json({ error: "Invalid signature" }, { status: 401 });
  }

  // 4. Now parse the body and handle the event
  const event = JSON.parse(body);

  if (event.event === "charge.success") {
    // Handle successful payment in your database
    console.log("Payment successful for:", event.data.customer.email);
  }

  return NextResponse.json({ received: true }, { status: 200 });
}

2. The Middleware Trap

If you have global middleware protecting your routes, ensure your webhook path is excluded. Otherwise, the payment provider will hit your login page instead of your API.

3. Why this matters for your SaaS

If your webhooks fail, your users won't get their "Pro" access, and your churn will skyrocket. Handling this correctly is the difference between a side project and a real business.

I have spent a lot of time documenting these "Gotchas" while building my MERN stack projects. If you want to see a full implementation of this including Stripe, Paystack, and database logic, check out my deep dive here: How to add Stripe or Paystack payments to your SaaS.

Digging Deeper

If you are tired of debugging the same boilerplate over and over, you might find my SassyPack overview helpful. I built it specifically to solve these "Day 1" technical headaches for other founders.

Happy coding!

Secure Authentication in Next.js: Building a Production-Ready Login System

Esimit Karlgusta — Sun, 04 Jan 2026 11:16:35 +0000

Secure Authentication in Next.js: Building a Production-Ready Login System

Every great SaaS product begins at the same point: the login page. It is the gatekeeper of your user data and the first interaction your customers have with your professional application. Yet, for many developers, setting up authentication feels like a high-stakes puzzle where a single mistake can lead to security vulnerabilities or a frustrated user base.

If you have ever struggled with session management, wondered how to securely store user credentials, or felt overwhelmed by the complexity of OAuth providers, you are in the right place. In this lesson, we are going to strip away the confusion and build a robust, secure authentication system using Auth.js (NextAuth v5) within the Next.js App Router framework.

The Problem: The "Homegrown" Auth Trap

Many developers start by trying to build their own authentication logic. They create a users table in MongoDB, hash passwords with bcrypt, and try to manage JWTs (JSON Web Tokens) manually in cookies. While this is a great academic exercise, it is often a recipe for disaster in a production SaaS environment.

Manual auth systems frequently suffer from:

Security Gaps: Improperly configured cookies or CSRF (Cross-Site Request Forgery) vulnerabilities.
Maintenance Burden: Keeping up with changing security standards and API updates from providers like Google or GitHub.
UX Friction: Hard-to-implement features like "Forgot Password," "Magic Links," or social logins.

The Shift: Moving to Auth.js

The professional way to handle this in 2026 is by using a library that does the heavy lifting for you. Auth.js is the standard for anyone wanting to Learn Next.js for SaaS. It handles session management, multi-provider support, and database integration out of the box, allowing you to focus on your core product features instead of reinventing the security wheel.

By shifting to an established library, you gain the confidence that your sessions are handled via encrypted, server-only cookies. You also get an easy path to adding "Login with Google," which significantly increases conversion rates for modern SaaS products.

Deep Dive: Setting Up Your Auth Workflow

To build a complete SaaS, we need a flexible system. We will implement two main strategies: Email/Password (Credentials) for traditional users and Google OAuth for a frictionless experience.

1. The Architecture of Auth.js in the App Router

In the Next.js App Router, authentication happens primarily on the server. We use a combination of:

The Auth Configuration File: Where we define our providers and callbacks.
Middleware: To protect routes before they even hit the browser.
Server Actions: To handle login and signup logic securely.

2. Initial Setup and Environment Variables

First, we need to install the necessary packages. In your terminal, run:

npm install next-auth@beta mongodb @auth/mongodb-adapter bcryptjs

Before writing code, we must define our environment variables. These are secrets that should never be committed to GitHub. Create a .env.local\ file:

AUTH_SECRET=your_super_secret_random_string
NEXT_PUBLIC_APP_URL=http://localhost:3000

AUTH_GOOGLE_ID=your_google_client_id
AUTH_GOOGLE_SECRET=your_google_client_secret

MONGODB_URI=your_mongodb_connection_string

3. Configuring the Auth Library

We will create a central configuration file. This is the heart of your security system. It tells Next.js how to talk to your database and how to verify users.

File: auth.ts (Root directory)

import NextAuth from "next-auth";
import Google from "next-auth/providers/google";
import Credentials from "next-auth/providers/credentials";
import { MongoDBAdapter } from "@auth/mongodb-adapter";
import clientPromise from "@/lib/mongodb";
import bcrypt from "bcryptjs";

export const { handlers, auth, signIn, signOut } = NextAuth({
  adapter: MongoDBAdapter(clientPromise),
  providers: [
    Google,
    Credentials({
      name: "credentials",
      credentials: {
        email: { label: "Email", type: "email" },
        password: { label: "Password", type: "password" },
      },
      async authorize(credentials) {
        if (!credentials?.email || !credentials?.password) return null;

        const dbClient = await clientPromise;
        const user = await dbClient.db().collection("users").findOne({ 
          email: credentials.email 
        });

        if (!user || !user.password) return null;

        const isValid = await bcrypt.compare(
          credentials.password as string, 
          user.password
        );

        return isValid ? { id: user._id.toString(), email: user.email } : null;
      },
    }),
  ],
  session: { strategy: "jwt" },
  pages: {
    signIn: "/login",
  },
  callbacks: {
    async session({ session, token }) {
      if (token.sub && session.user) {
        session.user.id = token.sub;
      }
      return session;
    },
  },
});

4. Creating the Login UI with Tailwind and DaisyUI

A SaaS needs a professional-looking login page. Using Tailwind CSS and DaisyUI, we can build a clean, responsive form that works on any device.

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

import { signIn } from "@/auth";

export default function LoginPage() {
  return (
    <div className="flex items-center justify-center min-h-screen bg-base-200">
      <div className="card w-full max-w-md shadow-2xl bg-base-100">
        <div className="card-body">
          <h2 className="text-3xl font-bold text-center mb-6">Welcome Back</h2>

          <form
            action={async () => {
              "use server";
              await signIn("google", { redirectTo: "/dashboard" });
            }}
          >
            <button className="btn btn-outline w-full flex items-center gap-2">
              Continue with Google
            </button>
          </form>

          <div className="divider text-xs uppercase text-base-content/50">or</div>

          <form className="space-y-4">
            <div className="form-control">
              <label className="label">
                <span className="label-text">Email</span>
              </label>
              <input type="email" placeholder="email@example.com" className="input input-bordered" required />
            </div>
            <div className="form-control">
              <label className="label">
                <span className="label-text">Password</span>
              </label>
              <input type="password" placeholder="••••••••" className="input input-bordered" required />
            </div>
            <button className="btn btn-primary w-full">Sign In</button>
          </form>

          <p className="text-center mt-4 text-sm">
            Don't have an account? <a href="/signup" className="link link-primary">Sign up</a>
          </p>
        </div>
      </div>
    </div>
  );
}

5. Protecting Routes with Middleware

In a SaaS application, you don't want unauthorized users accessing the dashboard or settings pages. Instead of checking for a session on every single page, we use Next.js Middleware to handle this globally.

File: middleware.ts (Root directory)

import { auth } from "@/auth";

export default auth((req) => {
  const isLoggedIn = !!req.auth;
  const { nextUrl } = req;

  const isAuthPage = nextUrl.pathname.startsWith("/login") || 
                     nextUrl.pathname.startsWith("/signup");
  const isDashboardPage = nextUrl.pathname.startsWith("/dashboard");

  if (isDashboardPage && !isLoggedIn) {
    return Response.redirect(new URL("/login", nextUrl));
  }

  if (isAuthPage && isLoggedIn) {
    return Response.redirect(new URL("/dashboard", nextUrl));
  }
});

export const config = {
  matcher: ["/((?!api|_next/static|_next/image|favicon.ico).*)"],
};

Key Benefits and Learning Outcomes

By following this workflow, you achieve several critical milestones in your development journey:

Centralized Security: You have a single source of truth for your authentication logic.
Database Synchronization: Your user accounts are automatically saved to MongoDB whenever someone logs in via Google.
Improved Conversions: Providing OAuth options reduces the friction of creating an account, which is vital for any Build SaaS with Next.js project.
Type Safety: Using TypeScript ensures that your session data is predictable throughout your components.

Common Mistakes to Avoid

Exposing the Secret: Never leave your AUTH_SECRET empty or use a simple string in production. Use a tool like openssl rand -base64 32 to generate a strong key.
Client-Side Protection Only: Never rely solely on hiding UI elements to secure your app. Always verify the session on the server or through middleware.
Forgetting Secure Cookies: In production, ensure your AUTH_URL uses HTTPS, otherwise Auth.js will not set secure cookies, and your login will fail.

Pro Tips and Best Practices

Use Server Components for Auth Checks: Whenever possible, check the session in a Server Component using the auth() function. It is faster and more secure than checking on the client.
Custom Session Data: If you need to store extra info (like a user's subscription status), extend the session callback in auth.ts to include those fields from your MongoDB database.
Graceful Error Handling: Redirect users to a custom error page if Google login fails, rather than letting the app crash or show a generic error.

How This Fits Into the Zero to SaaS Journey

Authentication is the foundation of the user experience. Once you have established who the user is, you can:

Store their specific data in MongoDB.
Link their account to a Stripe Customer ID for billing.
Provide a personalized Build SaaS Dashboard Next.js Tailwind.

Without a secure auth system, your SaaS cannot function because you cannot identify who to charge or whose data to display.

Real-World Use Case: The Productivity Tool

Imagine you are building a SaaS called TaskFlow. A user arrives at your landing page and clicks Get Started.

They click Continue with Google.
Auth.js redirects them to Google's secure portal.
After they approve, Google sends a token back to your auth.ts handler.
Auth.js checks your MongoDB. Since this is a new user, it automatically creates a new record in your users collection.
The user is redirected to /dashboard, where your server component greets them: "Welcome!"

Action Plan: What to Build Next

To master this lesson, I want you to complete these four tasks:

Initialize the Project: Set up a fresh Next.js project and install the dependencies.
Configure Google Cloud: Go to the Google Cloud Console, create a project, and get your OAuth credentials.
Build the Login Page: Use the Tailwind/DaisyUI code provided to create your own branded login screen.
Test the Middleware: Create a protected /dashboard page and try to access it while logged out to ensure you are redirected.

Take Your SaaS to the Next Level

Building a secure login system is just the beginning. If you want to skip the trial and error and follow a proven path to a launched product, check out our comprehensive Zero to SaaS Next.js Course. We dive deep into advanced patterns, multi-tenant security, and production-ready deployments.

The SaaS Billing Nightmare: Why Integration Is More Than Just a 'Pay' Button

Esimit Karlgusta — Sun, 04 Jan 2026 10:52:11 +0000

The "Simple" Button Illusion

You’ve finally finished your MVP. The logic works, the UI is clean, and you’re ready to take your first dollar. You open the Stripe documentation thinking, "I’ll just drop in a Checkout button and be done by lunch."

Fast forward forty-eight hours: you are buried in webhook logs, trying to figure out why a "successful" payment didn't actually update the user's subscription status in your database.

The Problem: Billing is a State Machine, Not a Transaction

Billing is the most deceptive part of building a SaaS. It looks like a simple transaction, but in reality, it is a complex, multi-state distributed system. When you build billing from scratch, you aren't just adding a button; you are building a system that must handle:

Subscription States: Trialing, active, past_due, canceled, and incomplete.
Proration: What happens when a user switches from a $20/month plan to a $100/month plan mid-cycle?
Webhook Reliability: If your server blips when Stripe sends a "payment succeeded" event, does your user lose access to the product they just paid for?
Global Compliance: Handling VAT, GST, and diverse payment methods like Paystack for African markets.

Building this manually drains weeks of development time and introduces "silent failures" that cost you money and customer trust.

The Shift: Using Subscription Engines

Sophisticated founders no longer write custom billing logic. They use Subscription Engines. The shift is moving away from "How do I call the Stripe API?" toward "How do I sync my app state with my billing provider?"

By using a pre-configured billing architecture, you treat payments as an infrastructure layer rather than a coding challenge. This allows you to focus on the actual value that makes users want to pay in the first place.

Deep Dive: The Hidden Logic of SaaS Payments

When you peel back the curtain, "simple" billing involves several layers of engineering that developers often underestimate.

1. The Source of Truth Paradox

Should your database be the source of truth for a subscription, or should Stripe? If you rely solely on your database, you might miss a cancellation made through the Stripe portal. If you rely solely on Stripe's API, your app will be slow due to network overhead. The solution is a robust sync layer using webhooks, which is notoriously difficult to test locally.

2. Regional Payment Diversity

If you are targeting a global audience, you can't rely on credit cards alone. In regions like Africa, Paystack is the gold standard. Implementing how to add Stripe or Paystack payments to your SaaS requires a unified abstraction layer so your frontend doesn't care which provider is being used.

3. The Grace Period Logic

What happens if a user's card is declined? You shouldn't lock them out instantly. You need "dunning" logic: a window where the app remains active while the system automatically retries the card. Coding this state machine from scratch is a massive time sink.

4. Managing Plan Upgrades

Upgrading a plan isn't just a new transaction. You have to calculate the unused portion of the current plan and apply it as a credit. If you don't have a system that handles how to add new payment plans in SassyPack automatically, you'll be doing manual math in support tickets every week.

Common Mistakes to Avoid

Hard-coding Plan IDs: Never put your Stripe Price IDs directly in your frontend code. Keep them in environment variables.
Trusting the Client-Side: Never update a user's status based on a frontend callback. Only trust a verified, signed webhook from the payment provider.
Ignoring the "Tax" Problem: Forgetting to collect addresses for tax purposes can lead to a legal nightmare once you scale.

Pro Tips for Billing Architecture

Idempotency Keys: Always use idempotency keys when creating charges to ensure customers aren't charged twice during network retries.
Simulate Webhooks: Use the Stripe CLI during development. Do not wait until production to see if your handlers work.
Unified Pricing Table: Create a single JSON configuration that maps your plan names to their respective provider IDs.

How SassyPack Helps

SassyPack takes the nightmare out of billing by providing a dual-integration system out of the box. Whether you need to add Stripe payments to your SassyPack app or add Paystack payments to your SassyPack app, the infrastructure is already built.

It features secure webhook handlers, subscription middleware to protect routes, and a unified checkout UI that works for both providers.

Action Plan and Takeaways

Stop Coding Billing Logic: It is a high-risk, low-reward activity for a founder.
Verify Your Webhooks: Ensure your handlers are cryptographically verified to prevent spoofing.
Automate Subscriptions: Use a system that handles the "past_due" and "canceled" states without manual intervention.

Start Collecting Revenue Today

Your goal isn't to be a "billing expert"; it is to be a successful founder. Every day you spend debugging payment logic is a day you aren't growing your MRR. Stop fighting the API and start shipping. Use the SassyPack Pricing and Setup Assist to get your billing system live by the end of the day.
`
},

Stop Coding Login Screens: A Senior Developer’s Guide to Building SaaS That Actually Ships

Esimit Karlgusta — Sun, 04 Jan 2026 10:37:56 +0000

The 2:00 AM Realization

You have the perfect idea. The domain is bought. The database schema is mapped out in your head. You sit down, crack your knuckles, and... spend the next eight hours configuring protected routes and password reset emails. By the time you get to the actual "logic" of your app, the weekend is over, and your motivation is dead.

Sound familiar?

The Problem: The Founder Momentum Killer

As developers, we are often our own worst enemies. We suffer from "Not Invented Here" syndrome. We think that if we don't hand-roll our own authentication or write our own Stripe webhook handlers, we aren't "really" coding.

But here is the hard truth: Your users do not care about your elegant JWT rotation logic. They care about the problem your software solves. Every hour you spend building boilerplate is an hour you aren't talking to users or refining your unique value proposition. Building SaaS from scratch manually drains your most finite resource: founder momentum.

The Shift: From Coder to Integrator

The era of the "everything from scratch" developer is ending. In its place is the "Product-Minded Engineer." These developers recognize that a SaaS foundation is a commodity. Whether you are building a Fintech tool or an AI wrapper, the login, the billing, and the dashboard sidebar are 90% the same across every project.

Starter kits have risen in popularity because they provide a "standard library" for business. They allow you to skip the plumbing and go straight to the architecture. This isn't "cheating"; it is strategic efficiency.

Deep Dive: The Parts That Will Kill Your Speed

If you choose to ignore a kit and build manually, these are the four horsemen of development delay:

1. The Auth Rabbit Hole

You start with simple email/password. Then you realize you need Google Login. Then you need Magic Links for better UX. Then you need to handle session expiration across multiple tabs. Implementing the best authentication setup for SaaS can take a seasoned dev a full week of edge-case testing and security auditing.

2. The Subscription Logic Nightmare

Writing a checkout session is easy. Handling a customer.subscription.deleted event in a way that gracefully revokes access in your database without crashing your app is hard. If you are building for a global audience, you might even need to manage multiple providers. Learning how to add Stripe or Paystack payments to your SaaS isn't just about reading docs; it is about building a bulletproof state machine.

3. Environment Parity and Deployment

Setting up a CI/CD pipeline that handles your Next.js frontend, your Node backend, and your MongoDB connection strings without leaking secrets is a tedious process. Most devs waste days on deployment debugging before they ever hit production.

4. The "Boring" UI

Don't forget the maintenance screens. Profile photo uploads, changing passwords, updating credit card info, and managing team members. This is 20% of the code but 0% of the market value of your product.

Key Benefits and Real Results

When you use a professional foundation, your timeline compresses:

Day 1: Deployment to production with a landing page.
Day 2: Your first core feature is live.
Day 7: You are running ads or cold emails to get users.

By comparison, the "manual" dev is usually still trying to figure out why their Tailwind CSS isn't purging correctly on Vercel by Day 10. The result of using a kit isn't just a faster launch; it is a higher probability of success. A project that launches in 48 hours has a much lower abandonment rate than one that takes three months to reach MVP.

Common Mistakes to Avoid

Customizing the Foundation Early: Don't spend three days redesigning the login page. Use the default. Get to the dashboard.
Hard-Coding Plans: Never hard-code your pricing tiers. Use a kit that lets you manage plans via your payment provider so you can A/B test prices without a code deploy.
Manual Deployment: If you are still FTP-ing files or manually running npm build on a VPS, you are losing time. Use a modern Vercel-based workflow.

Pro Tips for Senior Developer Speed

Use Server Components for Data Fetching: If you are on Next.js, leverage React Server Components to keep your client-side bundles small and your SEO high.
Schema First: Define your database models in Mongoose before you touch the UI. This acts as the source of truth for your entire app.
Global Middleware: Use middleware to handle authentication checks once, rather than checking session state on every single page or component.

How SassyPack Helps

SassyPack was built to be the engine under the hood of your SaaS. It uses the MERN stack with Next.js to provide a seamless developer experience. It includes everything mentioned above: pre-built auth, integrated payments with Stripe and Paystack, and a gorgeous dashboard UI.

Instead of fighting with infrastructure, you can build SaaS with SassyPack and focus on the 10% of your code that is actually unique. It is the difference between being a mechanic and being a driver.

Real-World Use Case: The AI Content Tool

Suppose you want to build a tool that generates LinkedIn posts using OpenAI.

Without SassyPack: You spend 2 weeks on the login, the Stripe integration, and the user profile. You spend 1 day on the OpenAI prompt.
With SassyPack: You spend 1 hour on setup. You spend 2 days on the OpenAI prompt, the UI for the generator, and refining the output quality.

You launch 12 days earlier. In the SaaS world, 12 days is an eternity of feedback you could have been receiving.

Action Plan and Takeaways

Stop Coding Boilerplate: If a library or kit exists for it, use it.
Focus on the Core Loop: What is the one thing your user comes to your site to do? Code that first.
Use a Proven Starter: Get the MERN stack advantage without the setup headache.

Closing CTA

Stop letting the "boring stuff" hold your ideas hostage. You have the skills to build something great, so don't waste them on login forms and billing webhooks. Use a professional Next.js SaaS Starter Kit to handle the heavy lifting while you focus on building the next big thing.

Zero to SaaS vs ShipFast, Which One Actually Helps You Build a Real SaaS?

Esimit Karlgusta — Fri, 05 Dec 2025 17:45:45 +0000

If you are trying to launch your first SaaS product, two paths usually show up. You can buy a template like ShipFast or you can follow a full step by step program like Zero to SaaS.

Both solutions help you move faster, but they help in completely different ways. One gives you a ready made codebase, the other teaches you how to build a complete SaaS from scratch. In this article, you will see the advantages of each approach, the limitations, and which one actually helps you become a real builder.

What ShipFast Really Offers

ShipFast is a production grade starter template built with Next.js. You get a full SaaS application that is ready to deploy with all the typical pieces already included.

ShipFast strengths:

A completed codebase with routing, auth, payments, and dashboard
Stripe subscriptions already integrated
Prebuilt landing page and onboarding
Helps experienced developers launch very quickly

ShipFast limitations for beginners:

Customization becomes difficult if you do not understand the code
You are modifying someone else’s architecture
Debugging takes longer because you did not build it
You are fast, but you do not learn core SaaS fundamentals

ShipFast makes sense if you already know what you are doing. If you are a beginner, the speed benefit is real, but the learning gap becomes a long term disadvantage.

What Zero to SaaS Actually Teaches

Zero to SaaS is a complete training program that shows beginners how to build a full SaaS product from scratch using Next.js, Stripe, MongoDB, and Vercel. You follow a clear path and write the code yourself.

Zero to SaaS benefits:

You build each part yourself, so you learn everything
Covers auth, protected routes, subscriptions, dashboards, and API design
Perfect for beginners who want structure and clarity
Helps you understand real world SaaS architecture
Gives you confidence to build future products on your own

Where Zero to SaaS can feel slower:

You are writing all the code manually
You will debug your own mistakes
It requires commitment and practice

The goal of Zero to SaaS is not speed at the beginning. The goal is to turn you into someone who understands how SaaS is built, so you can build anything later.

Zero to SaaS vs ShipFast, Side by Side

Speed

ShipFast is faster at the start because everything is already built.

Zero to SaaS is slower because you are learning fundamentals.

Learning

Zero to SaaS wins because you build the system step by step.

ShipFast gives you a completed solution without explaining how it works.

Customization

Zero to SaaS wins because you understand every component you create.

ShipFast becomes harder to modify if you do not know the underlying patterns.

Long term skills

Zero to SaaS wins easily. Skills compound and unlock future products.

Launching an actual SaaS

Both work, but the path depends on your background.

Who Should Use ShipFast?

ShipFast is a better choice if you:

Already understand Next.js
Can read and modify complex codebases
Want speed more than education
Are an experienced developer or repeat founder

If you have shipped apps before and you only need acceleration, a ready made template makes sense.

Who Should Choose Zero to SaaS?

Zero to SaaS is the right choice if you:

Are a beginner or intermediate developer
Want to understand authentication, billing, database models, and dashboard logic
Want to build multiple SaaS products in the future
Prefer clarity and structured guidance
Need hands on practice, not just a template

You might move slower in the first week, but you become ten times faster later because you understand what you are doing.

Final Verdict

If you want instant acceleration, ShipFast gives you a head start.

If you want long term skill, the ability to build any SaaS you imagine, and full understanding of Next.js architecture, Zero to SaaS is the stronger long term path.

Templates are shortcuts, skills compound. Zero to SaaS gives you the foundation that keeps paying off with every project you build.

The Developer’s Paradox: Why You Need a Next.js SaaS Starter Kit to Stop Coding and Start Selling

Esimit Karlgusta — Thu, 20 Nov 2025 12:24:34 +0000

You have a brilliant idea. It came to you in the shower or during a commute, a SaaS concept that solves a specific pain point, has a clear target audience, and potential for recurring revenue. You rush to your computer, fire up your terminal, and type npx create-next-app.

The adrenaline is pumping. You are ready to build the next unicorn.

But then, reality hits. Before you can write a single line of logic that makes your app unique, you have to set up authentication. Then you need to configure the database connection. Then comes the Stripe integration, webhook listeners, protected routes, email transaction providers, and responsive dashboard layouts.

Three weeks later, you are still debugging a JWT token issue. Your enthusiasm has waned, and your "brilliant idea" is gathering dust in a folder named project-final-v2.

This is the "Developer’s Paradox": The more you love to code, the slower you are at launching.

This guide explores how shifting your mindset from "builder" to "assembler" using a Next.js SaaS starter kit can save your startup before you even write the first line of business logic.

The Problem: The "Configuration Purgatory"

Why is building a SaaS application from scratch so deceptively difficult?

On the surface, a web app seems simple. You need a frontend, a backend, and a database. However, modern SaaS standards have raised the bar. Users expect:

Security: impeccable authentication (Google login, magic links, password resets).
Speed: Sub-second page loads and SEO optimization.
Reliability: recurring billing that handles failed payments and upgrades automatically.
Experience: A sleek, mobile-responsive dashboard.

Building this infrastructure manually is what we call "Configuration Purgatory."

The Math of Manual Setup

Let’s break down the time cost for a senior developer building a standard MERN (MongoDB, Express, React, Node) stack app with Next.js capabilities from zero:

Authentication System (Auth.js / NextAuth): 15–20 hours
Stripe/Payment Integration (Webhooks, Checkout): 20–30 hours
Database Schema & ORM Setup: 10 hours
Dashboard UI & Component Library: 25+ hours
Deployment Pipelines & SEO Config: 10 hours

Total wasted time: ~80 to 100 hours.

That is two and a half weeks of full-time work just to get to the starting line. For an indie hacker working nights and weekends, that’s two months. This is exactly why devs waste weeks building boilerplate instead of shipping products.

The Shift: Enter the Modern SaaS Starter Kit

Smart founders are moving away from create-app and toward SaaS app boilerplate solutions.

A SaaS starter kit is a pre-configured codebase that includes all the boring, repetitive features every SaaS needs. It is the difference between building a car engine from raw steel versus buying a reliable engine and building a custom car body around it.

Why MERN + Next.js?

When looking for the best MERN stack starter kits, the technology choice matters. The MERN stack (MongoDB, Express, React, Node.js) combined with the power of Next.js is currently the gold standard for solopreneurs and startups.

Why Next.js improves web development:

Server-Side Rendering (SSR): Unlike standard React apps, Next.js renders pages on the server. This is critical for SEO, allowing your marketing pages to rank on Google immediately.
Unified Backend/Frontend: With Next.js API routes, you can often skip a separate Express server for smaller apps, or integrate them tightly for larger ones.
Vercel Deployment: Next.js apps can be deployed globally in seconds.

Deep Dive: What’s Inside a Production-Ready Kit?

Not all boilerplates are created equal. To truly understand how to build SaaS MVP fast, you need to know what components are non-negotiable in a starter kit.

1. Robust Authentication

A simple email/password form isn't enough. A SaaS starter kit with auth must handle session management, protected routes (keeping non-paying users out of premium features), and social logins (Google/GitHub).

2. Monetization Infrastructure

This is usually the hardest part for developers. It’s not just about a "Buy" button. You need:

Subscription management (Monthly/Yearly toggle).
Webhook handling (what happens when a credit card fails?).
Customer portals (so users can cancel or upgrade without emailing you).

Pro Tip: Handling payments manually is risky. A good starter kit pre-integrates Stripe or Paystack so you don't touch sensitive financial data. For a deeper look at integration, read our guide on adding Stripe or Paystack payments to your SaaS.

3. The Dashboard UI

Your users spend 90% of their time in the dashboard. If it looks clunky, they will churn. Modern kits utilize Tailwind CSS to provide beautiful, responsive components out of the box.

How SassyPack Solves the Paradox

If you are looking for a SassyPack MERN & Next.js starter kit that bridges the gap between a raw framework and a finished product, this is where we come in.

SassyPack was built to eliminate the 100 hours of setup we mentioned earlier. It is a fully functional SaaS application waiting for your unique idea.

Key Features of SassyPack:

Full Stack MERN & Next.js: The most popular, hireable stack in the world.
Pre-built Auth: Secure login flows ready to go.
Stripe & Paystack Ready: Just add your API keys, and you are ready to take money.
Beautiful Dashboard: Professional UI components based on Tailwind.
SEO Optimized: Meta tags, sitemaps, and structured data configurations are pre-set.

SassyPack isn't just a template; it's a full stack app boilerplate setup designed to let you deploy on Day 1.

Case Study: The "Weekend Launch"

Let’s look at a hypothetical comparison of two developers, Sarah and Mike. Both have an idea for an AI-powered writing assistant.

The "From Scratch" Path (Mike):

Friday Night: Mike initializes a Next.js project. He spends 4 hours choosing a UI library.
Saturday: Mike fights with Auth0 configurations. He gets login working but breaks the session persistence.
Sunday: Mike tries to set up Stripe webhooks. He realizes he needs a backend server to listen to them securely. He starts setting up Express.
Result: By Monday morning, Mike has a login page and a broken payment button. No AI features built.

The SassyPack Path (Sarah):

Friday Night: Sarah downloads SassyPack. She runs npm install and adds her API keys to the .env file.
Saturday Morning: The dashboard, auth, and payments work immediately. Sarah deletes the placeholder text and connects her OpenAI API key.
Saturday Afternoon: She customizes the landing page copy and colors to match her brand.
Sunday: Sarah deploys to Vercel. She posts her product on Product Hunt.
Result: By Monday morning, Sarah has her first 3 paying customers.

Sarah understood that rapid web app development tools are not "cheating"—they are smart business.

Common Mistakes When Choosing a Starter Kit

If you are browsing for full stack SaaS starter kit comparison guides, watch out for these pitfalls:

1. Vendor Lock-in

Some kits rely on obscure libraries or proprietary backend-as-a-service tools (like Firebase-only wrappers) that are hard to migrate away from. SassyPack uses standard MERN technologies (MongoDB, Node, React). You own your code.

2. Bloated Code

Some templates include too much. If a kit comes with a chat app, a forum, and a blog when you only need a dashboard, you will spend days deleting code. Look for a clean architecture that is easy to extend.

3. Outdated Dependencies

The JavaScript ecosystem moves fast. Ensure the kit you buy is maintained. A Next.js SaaS starter kit running on Next.js 10 is useless in a Next.js 14 world.

Action Plan: From Zero to Launch in 3 Steps

Ready to stop configuring and start shipping? Here is your roadmap.

Step 1: Validate, Don’t Code

Before you buy anything, write down your idea. Who is it for? What is the one core feature they need? If you need help here, check out our article on building SaaS apps with the MERN stack to understand the architecture better.

Step 2: Acquire the Infrastructure

Don’t build the foundation; buy it. Download SassyPack to secure your authentication, database connection, and payment processing instantly.

Step 3: The "One Feature" Sprint

Build only the core value proposition of your app. If it’s an image generator, build the generation form. If it’s an analytics tool, build the chart. Do not build a blog or a help center yet. Use SassyPack's pre-built UI components to slap this feature into the dashboard.

Step 4: Deploy

Push your code to GitHub and connect it to Vercel. Because SassyPack is optimized for rapid deployment solutions for SaaS, your live URL will be ready in minutes.

Conclusion: Speed is Your Only Advantage

As an indie hacker or a small team, you cannot out-spend Google. You cannot out-hire Microsoft. Your only competitive advantage is speed.

Every hour you spend writing boilerplate code is an hour you are not talking to customers or improving your core product.

A Next.js SaaS starter kit like SassyPack isn't just a collection of files; it is a time machine. It buys you the 3 weeks you would have lost to "Configuration Purgatory" and hands them back to you so you can focus on what actually matters: building a business.

Ready to launch your SaaS this weekend?
Stop reinventing the wheel. Get the complete SassyPack toolkit today and turn your idea into recurring revenue 10x faster.