Show HN: I open-sourced my Go and Next B2B SaaS Starter (deploy anywhere, MIT)
22 comments
·December 19, 2025zaphodias
This is great - thanks for sharing. I am actually building something very similar myself as I started building a couple SaaS and though it would be nice to extract the common pieces in a template.
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.
[2]: https://ui.nuxt.com/
moh_quz
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
MadsRC
This is cool - Whenever I have a new idea for a thing I spend too much time writing boilerplate IAM and backend stuff, taking away time that could be spend on actual business logic. Thought about packaging the boilerplate stuff up before, never gotten around to it. Glad you did!
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.
moh_quz
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?
leetrout
Have you tried Echo instead of Gin? I find it to be much more friendly and approachable with its docs compared to Gin.
moh_quz
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
adlpz
Cool project! Will surely copy ideas from it :)
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?
moh_quz
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.
adlpz
Thanks for the answer! I've hit those tipping points myself in exactly the same scenarios (OCR and AI). For me, ends up being hacky or just decoupled (independent job runners). Makes sense to have a proper monolith backend for these.
Congrats on the launch again!
moh_quz
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.
null
sallveburrpi
Thanks for sharing!
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?
moh_quz
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.
miroljub
Nice one. Good to learn about polar.sh as a MoR alternative to Paddle.
I would prefer if it had a more leightweight htmx approach, but I guess it would be useful to some people.
moh_quz
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.
icedrift
Oh boy another template shipped in a single commit; complete with "For now, do this" and "In production you would do this" comments
moh_quz
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.
user20251219
Awesome project - thanks for sharing
moh_quz
You are more than welcome!
If you need anything don’t hesitate to reach out, you can find my info in the repo
rvz
Nice project and great idea and a reasonable selection of technologies that optimize for low cost deployment.
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.
moh_quz
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
null
Hi HN, I'm Mohammed, a technical founder who loves shipping and giving back to the community. I'm open-sourcing the full-stack engine that powers my B2B product, apflow.co.
What it is: A production B2B starter with a Go backend and Next.js frontend. Both are fully Dockerized with separate containers. No Vercel. No Supabase. Deploy the whole thing on a $6 VPS, or split frontend and backend across different providers. You own the infrastructure.
The problem I was solving:
Every SaaS starter I evaluated had the same issue: they locked me into someone else's platform. Vercel for hosting. PlanetScale for the database. Serverless functions billing per invocation. Fine for prototypes, but costs become unpredictable at scale and migrating away is painful.
I wanted something I could deploy on any Linux box with docker-compose up. Something where I could host the frontend on Cloudflare Pages and the backend on a Hetzner VPS if I wanted. No vendor-specific APIs buried in my code.
Why Go for the backend:
Go gives me exactly what I need for a SaaS backend:
Tiny footprint. The backend idles at ~50MB RAM. On a cheap VPS, that headroom lets me run more services without upgrading. Concurrency without complexity. Billing webhooks, file uploads, and AI calls run concurrently without callback hell. Compile-time type safety. Using SQLC, my SQL compiles to type-safe Go. If the query is wrong, it fails at build time, not in production. Predictable performance. No garbage collection pauses that surprise you under load. The architecture (Modular Monolith):
I didn't want microservices complexity for a small team, but I needed clean separation. I built a Modular Monolith: features like Auth, Billing, and AI are isolated Go modules with explicit interfaces, but they deploy as a single binary.
This structure also made AI coding tools (Cursor, Claude Code) dramatically more effective. Because every module has strict boundaries, the AI knows exactly where new code belongs and doesn't break other modules.
Full-stack, not just backend:
Backend: Go 1.25 + Gin + SQLC (type-safe SQL, no ORM) + PostgreSQL with pgvector Frontend: Next.js 16 + React 19 + Tailwind + shadcn/ui Communication: The frontend consumes a clean REST API. You can swap Next.js for any framework that speaks HTTP. Infrastructure: Separate Dockerfiles for frontend and backend. Deploy together or apart. What's pre-built:
The boring infrastructure is solved so you can focus on your actual product:
Auth + RBAC: Stytch B2B integration with Organizations, Teams, and Roles. Multi-tenant data isolation enforced at the query level. Billing: Polar.sh as Merchant of Record. Handles subscriptions, invoices, and global tax/VAT. No Stripe webhook edge cases. AI Pipeline: OpenAI RAG using pgvector. The retrieval service enforces strict context boundaries to minimize hallucinations. OCR: Mistral integration for document extraction. File Storage: Cloudflare R2 integration. Each feature is a separate module. Don't need OCR? Remove it. Want Stripe instead of Polar? The billing interface is abstracted.
Real-world proof:
This isn't a template I made for GitHub stars. It's the exact code running apflow.co in production. When I added document OCR, I built it as a new module without touching Auth or Billing. The architecture held.
How to try it:
Clone the repo, read setup.md to check the prerequisite, run ./setup.sh, and you have a working B2B environment locally in minutes.
Feedback I want:
I'd appreciate feedback from Go developers on the module boundaries and cross-module interfaces. Also curious if anyone has suggestions for the Docker setup in production deployments.
GitHub: https://github.com/moasq/production-saas-starter
Live: https://apflow.co