My stack is similar, with a few differences:

- Go backend with sqlc, but using ConnectRPC[1]. I chose this as it allows me to define a proper API scheme and generate a decent-quality Typescript client.

- Nuxt (Vue) instead of Next.js (React). I chose this even though I'm new to vue cause I saw the open source components and templates here [2] (especially the dashboard template: [3]) and was convinced.

I'll definitely check out your repo as inspiration.

[1]: https://connectrpc.com/

[2]: https://ui.nuxt.com/

[3]: https://dashboard-template.nuxt.dev/

However, my biggest concern is the glaringly lack of comprehensive tests whatsoever. I have to even question if this project is production ready at all.

Until that is in place, I really do not think this is "production" quality I'm afraid.

A thing to consider would be to make it easier (or perhaps bake it in) to separate out parts of the app into a separate origin. Something that would be good for pretty much any SaaS app would be to separate the IAM out (could still embed it with an iframe) - this allows you to keep a fairly tight security policy for the IAM stuff and a more lax one for the rest of the app. Kinda how Google separates out accounts.google.com.

A general question for the room: where's the tipping point where you need a "proper" backend, in a different language, with all the inconveniences of possible type safety issues and impedance mismatches?

Because I feel like for 90% of small-medium projects it's just good enough with all the backend stuff within the same Next.js process as the front-end. I just do "separation of concerns"-ish with the code organization and funnel all communication with something structured and type safe like tRPC.

Feels separate enough but very pleasant to work anyway.

Am I doing it wrong?

I created a simple start kit set of packages for my projects, not as exhaustive as yours though -- https://github.com/krsoninikhil/go-rest-kit

One question though: What made you avoid lock-in via platforms like supabase but then choose to be locked in on the AuthN/Z side with a proprietary solution?

I would prefer if it had a more leightweight htmx approach, but I guess it would be useful to some people.