Every SaaS starter kit I looked at came with a frontend attached.
ShipFast. MakerKit. SupaStarter. All of them assume you want
Next.js. All of them bundle a UI you may not need, a framework
you may not want, and opinions about your frontend you never asked for.
I didn't plan to build a backend-only kit. It just ended up that way.
How it started
I was starting a new project and needed a backend foundation.
Auth. Billing. Webhooks. Email. Database setup.
The same things every SaaS needs.
I needed a backend foundation. I knew what I wanted it to look like —
clean architecture, proper tests, everything wired.
So I built it. When it was done, I packaged it.
So I built it myself. And packaged it so others could use it too.
When I looked at what I'd built, it was pure backend. No pages.
No components. No frontend framework opinions. Just a clean
Node.js + TypeScript foundation with everything wired.
I didn't make it backend-only as a strategic decision.
It just was.
What I realized after
Once it was done, I started looking at who actually needs this.
Developers using Firebase or Supabase aren't the target. Those
tools are genuinely good for certain use cases. If you want
managed auth and don't care about owning your stack, use them.
But there's a specific type of developer who hits a wall with BaaS:
- You're building something where you need full control over your auth logic
- You already have a frontend — React, Vue, Svelte, React Native — and you don't want to rebuild it around a new framework
- You want to own your database and deploy anywhere
- You want Stripe webhooks handled properly, not worked around
That developer can't use ShipFast. It's Next.js-first.
That developer can't use MakerKit. Also Next.js-first.
They can use KeelStack.
What backend-only actually means
It means your frontend is your problem. KeelStack doesn't care
what you use. React, Vue, Svelte, React Native, a mobile app,
no frontend at all — it doesn't matter. You hit REST endpoints
over HTTP. That's it.
It also means the backend is done properly:
- Hexagonal architecture — swap Stripe, swap your database, swap email providers without touching business logic
- 159 unit tests, 36 end-to-end checks, 95% statement coverage
- Idempotent webhook handling — no duplicate processing
- In-memory fallback — works without a database on first run
- Health endpoints with per-service diagnostics
The uncomfortable truth about full-stack kits
When you buy a full-stack kit, you're buying someone else's
frontend opinions bundled with a backend you actually needed.
If those opinions match yours — great. You save time.
If they don't — you spend hours stripping out a frontend
you never wanted, or worse, you bend your product to fit
the kit's architecture.
Backend-only sidesteps this entirely.
You bring your frontend. I bring the backend.
Who this is for
Developers who already have a frontend and need a solid backend.
Freelancers building APIs for clients.
Founders launching SaaS MVPs who want to own their stack.
Developers switching away from Firebase who want full control.
Not for complete beginners. Not for people who want managed hosting.
Not for teams expecting enterprise SLAs.
One more thing
I'm 17. This is my first product.
I built it because what I needed didn't exist at a price
that made sense — and because building it taught me more
than any tutorial ever would.
It's $49. You own the code. No subscription.
If you're building a SaaS backend and you're tired of
framework lock-in — it might save you a few weeks.
If you found this useful or have thoughts on the backend-only
approach — drop a comment. I'm genuinely curious whether other
developers hit the same wall.
Top comments (0)