I was tired of spending 3 weeks setting up Auth & Billing, so I built NetPulse

Let’s be honest for a second.

Every time a cool SaaS idea pops up in your head at 2 AM, the excitement is unreal. You fire up your terminal, create a blank project, and get ready to build something awesome.

Then reality hits.

Before you can write a single line of your actual core feature, you spend the next three weeks setting up:

• OAuth flow that doesn't break on callbacks
• JWT access and refresh token logic
• Entity Framework models & Postgres migrations
• Stripe CLI and local webhook forwarding
• Docker compose files because "it works on my machine" isn't enough anymore

By the time you finish configuring all that boring plumbing, the initial high is gone. The project gets abandoned, joining the graveyard of unfulfilled GitHub repos.

I’ve been there way too many times while working on projects at PulseLabs. So over the last couple of months, I decided to fix this loop once and for all.

I built NetPulse—a .NET 8 + Next.js SaaS starter kit designed to get all that setup out of the way in about 5 minutes.

---

The Pain Points I Wanted to Eliminate

I didn't want just another bloated template. I wanted something clean, fast, and sensible for developers who actually want to ship.

1. Payment Provider Lock-In

Most templates force you to use Stripe. But depending on where your users are or how you handle international taxes, you might prefer a Merchant of Record (MoR) like Polar.sh or Lemon Squeezy.

Instead of hardcoding one gateway, I wrapped the billing system inside a simple abstraction layer. You get pre-built webhook handlers for Stripe, Polar, and Lemon Squeezy out of the box. Want to switch providers? Just change your config in Program.cs or .env. You don't have to rewrite your core subscription logic.

2. Clean Architecture (Without the Over-Engineering)

I like clean code, but I hate over-engineering. The backend uses a straightforward 4-layer setup:

• Domain: Pure business entities, zero external dependencies.
• Application: CQRS handlers, DTOs, interfaces.
• Infrastructure: EF Core, PostgreSQL, mailers, payment SDKs.
• WebApi: Controllers, rate limiting, audit logs.

If you ever decide to swap out PostgreSQL for something else, your domain logic stays completely safe.

3. One Command Local Setup

No one likes installing five different dependencies on their local machine just to test a template.

Everything runs inside Docker. One command:

docker compose up -d --build

This spins up the Next.js frontend, the .NET Web API, a PostgreSQL 16 container, and a Stripe CLI container that automatically routes local webhooks to your local API.

What’s Under the Hood?

Here’s the TL;DR of the tech stack:

Backend: .NET 8 Web API (Clean Architecture)

Frontend: Next.js (App Router), TypeScript, Tailwind CSS, Shadcn UI

Database: PostgreSQL 16 + Entity Framework Core 8

Auth: ASP.NET Core Identity, JWT Bearer, Google & GitHub OAuth 2.0

Payments: Pluggable integration for Stripe, Polar.sh, and Lemon Squeezy

DevOps: Multi-stage Dockerfiles + Docker Compose

Final Thoughts

Building this was all about cutting down friction. By baking the repetitive 80% of SaaS setup into a reusable foundation, the focus shifts entirely to building the actual product features and shipping faster.