Stytch lock-in is shallow (just an API behind a ~200 line adapter).

If I swap Stytch for Ory or Auth0, I rewrite one file. The rest of the app doesn't know the difference.

For most CRUD apps, Next.js + tRPC is the right call.

My tipping point was long-running tasks (OCR, AI processing that takes 30+ seconds) and wanting to scale backend compute separately from frontend serving.

If you don't have those needs, stick with what you have.

I stripped out the business logic and keys, then pushed it as a clean starting point.

The "in production you would" comments are guides for where to add your own config.

Single commit because I didn't want my app's git history in an open source repo.

Your IAM separation idea is interesting. Separate origin for auth would tighten the CSP significantly. The backend is already modular, so spinning the auth service into its own container with a stricter policy is doable. Worth exploring. Would you mind opening an issue on the repo so I don't lose track of this?

PRs welcome if anyone wants to help out

ConnectRPC looks interesting actually, proper API schema with generated TS client is nice. And that Nuxt dashboard template is clean, hadnt seen that before.

If you spot anything in the repo or have ideas, feel free to open a PR. Or just reach out directly if you wanna chat about the stack. Always down to learn from someone building similar stuff

Would love to explore different libraries

Thanks for your feedback, and I am always open for any questions!

But the frontend and backend arent tightly coupled at all.

You can swap Next for Vite, Nuxt, whatever you want and connect it to the same Go backend.

Only thing you'd need to copy over is some auth and billing related stuff on the frontend side

* It wants to be your back-end. If you have a separate back-end, get ready to write back-end auth code twice, and probably in 2 different languages, and some brittle proxy code that will break the next time the Next guys decide they want to change how middleware works (again).

* The maintainers aren't particularly helpful. Having built a couple sites using Next, many of our questions ended up being answered with some variation of, "You're holding it wrong," but it was clear they just didn't want to support our (and other users' submitting issues) scenarios.

* Whether you are on Vercel or not, the team behind Next is very motivated to get you onto Vercel. You can expect their technical choices to go more towards that path. This is at odds with the goals of this project. Coupled with the above, expect to have little to no agency to raise issues and have them solved beyond simple/obvious bug fixes, even after you've invested your project into their platform.

* Next really struggles in situations where your users are your customers' customers, and your customers want something more white-labeled. As soon as this bleeds into the arena of using custom domains per customer and such, some of the advantages of Next start to become disadvantages.

Many of the pieces Next offers are sort of optional, but if you don't fit their idea of how a piece (such as auth via next-auth or their take on server-side components) should work, you're left to solve on your own. It's not the end of the world to have to implement your own auth flow with oidc-client, but it can be a little risky and my brain doesn't hold onto OIDC or OAuth2 so every time I implement an auth flow from scratch I end up having to look up how it should work.

That said, if you end up having to deal with more than a couple of the above things, Next moves from an ok choice for the project to a poor choice.