82
points
moh_quz
Joined 51 karma
B2B founder | Open Source Enthusiast | FullStack Dev
- You are welcome hope it benefits you!
- This is really helpful context, thanks for writing it out.
You’re right that Next wants to be your backend and thats exactly why I kept the real backend separate in Go.
The Go backend handles all auth, billing, database, everything.
Next is just a frontend that calls the API. So if Next keeps changing things or pushes too hard toward Vercel, you swap it out. The backend doesnt care.
The white-label / custom domain point is interesting, hadnt thought about that edge case. Good to keep in mind.
Honestly the backend is the important part here. The frontend is just one way to consume it
- Honestly just because its the most popular so more people can pick it up easily.
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
- Just checked yours, it is really helpful for those who want to start quickly, some people won't use mine because it is too much for their use case.
Thanks for your feedback, and I am always open for any questions!
- Tbh not yet, I heard that it’s more user friendly, but I go with gin because it has larger community and support!
Would love to explore different libraries
- Thanks man, really appreciate it!
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
- Fair point. For what its worth I did add a script that runs tests and checks coverage. But yeah the coverage itself could be better, working on it
PRs welcome if anyone wants to help out
- Thanks! That's exactly why I open-sourced it. Instead of this living in my private repo getting occasional updates, now the community can push it forward. Improvements flow back to everyone, including me. Win-win.
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?
- You are more than welcome!
If you need anything don’t hesitate to reach out, you can find my info in the repo
- I really appreciate your comment, never hesitate to reach out to me if you have any concerns, you can find my info in the repo.
- This was extracted from my production apps including (apflow.co).
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.
- Totally valid. The Go backend is just a REST API with no Next.js coupling. You could swap the frontend for Go templates + htmx without changing the backend at all. And yeah, Polar.sh has been great. Merchant of Record means I don't think about tax compliance.
- Fair question. The difference for me: Supabase lock-in is deep (their Postgres extensions, auth hooks, edge functions all intertwined).
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.
- You're not doing it wrong.
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.
- 1 point
- Hi HN,
I realized I was spending the first 3 weeks of every new B2B project just wiring up "boring" infrastructure like Authentication, Team Invites, and Billing webhooks.
I decided to open-source my internal kit (MIT Licensed) to fix this.
The Goal: Help founders skip the plumbing and start building their unique business logic on Day 1.
The Stack:
Backend: Go 1.23 (Modular Monolith with sqlc).
Frontend: Next.js 15 (App Router).
Included: Pre-configured RBAC, Multi-tenancy, Billing (Polar), and a pgvector RAG pipeline.
It’s opinionated, but it saves you from "Decision Fatigue" when launching a new product. Happy to answer questions!
- 1 point
The deployment process for this repo has been really smooth for me. I use only docker compose, and traefik for web server.
ngl I ran claude code to help me for deployment, and then I wrote scripts automating deployment of frontend and backend.
All of this I used it for my product apflow.co
If you need to know more, please you can contact me, you will find my info in the repo