2
3 Comments

Why this scaffold exists

When I was building my Next.js 16 Auth Kit, I didn't originally plan to release a free version.

As the project grew, I realized the session layer had become a useful starting point on its own. It already included email and password authentication, JWT session cookies, the proxy.ts and layout.tsx split, startup environment validation, and strict TypeScript. Those pieces are useful even if you don't need OAuth, roles, or an admin panel.

That's why I extracted it into its own project instead of keeping it locked inside the larger kit.

The scaffold intentionally focuses on one thing: session authentication.

It includes:

Email and password authentication with bcrypt

JWT session cookies signed with jose

Edge cookie checks in proxy.ts

Full JWT verification in dashboard/layout.tsx

Startup validation for DATABASE_URL and JWT_SECRET

Strict TypeScript with a server-only guard

PostgreSQL using raw SQL

MIT license for personal and commercial use

I deliberately left out OAuth, email verification, password reset, roles, and an admin panel. Those belong in a complete authentication system, while this scaffold is meant to be a clean foundation that developers can understand and extend.

If you eventually need OAuth, email verification, or role-based access, the full Auth Kit has those. If session authentication is all you need, this scaffold is designed to work well on its own.

I'd love to hear how you're approaching authentication in your own Next.js 16 projects.

posted toAvatar for product Next.js 16 Auth Scaffold
Next.js 16 Auth Scaffold
  1. 2

    Keeping the scaffold intentionally narrow is the right instinct. I'd keep validating where developers actually stop needing "just auth" and start rebuilding the missing pieces. That boundary is what determines whether the free scaffold becomes a growth engine for the full kit or a complete substitute for it.

    1. 1

      That's exactly the balance I'm trying to strike. The scaffold is intentionally focused on getting session authentication right, but I don't want to artificially hold anything back just to create an upgrade path. My goal is for the free version to stand on its own, and for the paid kit to become the natural next step only when someone genuinely needs features like OAuth, email verification, roles, or an admin panel. It'll be interesting to see where developers naturally draw that line. Thanks for the perspective!

      1. 2

        That makes sense.

        One thing I'd keep watching is whether the upgrade happens because developers hit a missing feature or because the product becomes part of a larger workflow they don't want to rebuild themselves.

        Those are different signals, and the second one usually creates stronger product pull.