I got tired of rebuilding the same SaaS foundation every time — so I packaged it once
Every new SaaS project started the same way for me.
Day 1 — set up auth.
Day 2 — wire up Stripe.
Day 3 — database, deployment config, environment variables.
Only on day 4 did I actually start building the thing I wanted to build.
So I stopped doing it repeatedly and packaged everything into one boilerplate I can reuse forever.
Here's what I ended up with:
Auth
- JWT with access + refresh token rotation
- Google OAuth — one click sign in, works out of the box
- Rate limiting on auth routes to block brute force attacks
- bcrypt password hashing
Billing
- Stripe subscription plans pre-wired
- Checkout and Customer Portal both handled
- Webhook handler syncs subscription changes to the database automatically
- API routes you can lock behind a plan with one line of code
Database
- PostgreSQL with Prisma ORM
- Clean schema — Users, Subscriptions, Refresh Tokens
- Migration files included
Frontend
- Next.js + Tailwind
- Landing page with pricing section
- Login, register, dashboard, billing, profile — all done
- Deploys to Vercel automatically on every git push
Deployment
- Railway config for the backend
- Vercel for the frontend
- Both set up and running in under an afternoon
You can see the whole thing live here:
👉 https://saas-boilerplate-hsh5xrikl-johnolee15-9278s-projects.vercel.app
I'm curious — how much time do you typically lose to this kind of setup at the start of a project? And what would you add to something like this?
Happy to answer any questions about how I built it — drop them below!
This is interesting. I have seen a similar issue with cookie scanners: some tools report all cookies found after consent, while the more important question is whether analytics or marketing tracking happened before consent. For small teams, the confusing part is usually interpreting the scan result rather than adding the banner itself.
The feature stack is solid, but I’d be careful with positioning this as “another SaaS boilerplate.”
Most founders don’t buy the stack itself. They buy the saved first week and the confidence that billing/auth/deploy won’t break while they’re trying to validate the actual product.
So the sharper message may be less “JWT, Stripe, Prisma, Vercel” and more “start testing the SaaS idea before setup work kills momentum.”
Happy to put the tighter landing/pricing angle in writing if useful. The risk here is sounding technically complete but commercially interchangeable.
This is the most useful comment I've gotten on this — thank you.
You're completely right. I wrote the post like a developer
explaining what I built rather than a founder explaining what
problem it solves. "JWT + Stripe + Prisma" is what's in it,
not why someone buys it.
"Start testing your SaaS idea before setup work kills momentum"
is a much sharper way to frame it. That's exactly the feeling
I had when I built it — I just didn't articulate it that way.
I'd genuinely take you up on that tighter landing/pricing angle
if you're offering. I'm in the process of figuring out the
right positioning so an outside perspective would be really
helpful.
Also packaged this up here if you want to take a look at what
you're working with:
looneyjoons.gumroad .com/l/nodejs-saas-boilerplate
Appreciate that.
The reason I stopped short is that I don't think the interesting part is the landing angle itself.
I think there's a bigger positioning decision sitting underneath it.
That's the part I'd be careful with before changing messaging, pricing, or packaging.
I wouldn't try to unpack that properly in a thread.
If you're curious, drop your email and I'll put together the tighter version.