I tried Clerk in a real Next.js build (notes from actually shipping something)

I wanted to test Clerk in a way that felt real, so I used it in a small app I was already building (Next.js App Router + Supabase + Prisma), instead of doing a toy “login page” demo.

Short version: auth setup was fast, most pain came from DB plumbing, not Clerk.

I followed the Next.js quickstart pattern:

• install @clerk/nextjs
• add clerkMiddleware() in proxy.ts
• wrap layout with ClerkProvider
• use SignedIn/SignedOut + UserButton

// src/proxy.ts
import { clerkMiddleware } from "@clerk/nextjs/server";

export default clerkMiddleware();

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

That part took minutes.

What felt good

1) Keyless mode is actually useful
I could just start building. No key-copying upfront, no dashboard detour before writing product code.

For prototypes, this is huge. Normally auth setup breaks flow early.

2) Going from keyless to real keys was easy
After core features were done, I added:

NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=...
CLERK_SECRET_KEY=...

Restarted app and moved on. No drama.

What broke

1) Middleware matcher got me once

I hit this runtime error during setup:

auth() was called but Clerk can't detect usage of clerkMiddleware()

Fix was matcher coverage. Once fixed, auth was stable.

2) My bigger issues were Supabase/Prisma

I hit P1001 and schema engine headaches.
That was a DB/network config issue, not an auth issue.

Honestly this was useful signal: Clerk wasn’t the bottleneck in the build.

Net take

If you’re on Next.js and want to move quickly, Clerk is solid.

The biggest value for me wasn’t “fancy auth features,” it was:

• fast time-to-first-working-auth
• low setup friction
• easy path from prototype mode to proper config

That’s what I care about in tooling.