EventForge
Production-ready .NET 8 SaaS starter kit — event-driven out
For years I've been a backend .NET developer, building things for other people. Solid work, but always someone else's product. This year I decided I wanted something that was mine my first personal product, from zero.
The problem was picking something I could actually ship, not just dream about. So I looked at what I already knew cold: every time I start a new .NET SaaS, I rebuild the exact same foundation. Auth, multi-tenancy, billing, background processing. Weeks of plumbing before writing a single line of the actual product.
And there was one piece I kept seeing done wrong or skipped entirely: the event-driven part. Most .NET starter kits stop at auth and billing. Almost none ship a correct event-driven foundation.
So I built one. It's a .NET 8 SaaS starter kit with Clean Architecture, multi-tenancy via EF Core query filters, JWT auth with refresh rotation, Stripe subscriptions, and the part I care most about: the transactional Outbox pattern wired to RabbitMQ. Domain events are never lost, and never published for a transaction that rolled back at-least-once delivery, retries, poison-message handling.
Docker Compose brings up the API, PostgreSQL and RabbitMQ with one command. From clone to a running multi-tenant SaaS backend in about 5 minutes.
I just launched it. No sales yet this is genuinely day one of going from zero. I'd love feedback from anyone who's sold code or built dev tools: what worked for you in those first weeks?
Happy to answer anything about the architecture too the Outbox implementation especially.
5 Comments
Most starter kits save developers from writing boilerplate. Yours is interesting because it also tries to remove architectural uncertainty.
Whether buyers see it as a productivity tool or a reliability tool will probably matter more than the feature list.
That's a sharp distinction, thank you. You're right that 'removes architectural uncertainty' is the real value, more than the time saved. The Outbox + RabbitMQ piece especially: most devs know they should do it, but getting it correct (atomic with the business transaction, at-least-once, poison handling) is where the uncertainty lives. I'm going to lean into the 'reliability tool' framing. Really appreciate you taking the time to think about the positioning.
Appreciate the context.
The reliability vs productivity distinction is the interesting part here.
Would be good to understand how you're thinking about that positioning shift and what you're seeing from developers.
What's the best email to reach you on?
Thanks, appreciate that.
Reliability over productivity is the direction I'm taking, and the early feedback has been pointing the same way.
Best email to reach me is eventforge2026@gmail .com glad to continue there.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.