DEV Community: azhadsuhaimi

Building NetPulse: A Production-Ready .NET 8 + Next.js SaaS Boilerplate

azhadsuhaimi — Fri, 28 Aug 2026 16:34:26 +0000

Over the last 1–2 months, I stopped chasing new side-project ideas and decided to solve a frustration I’ve had for a long time: The exhausting setup phase before writing actual business logic.

As part of my ongoing engineering work at PulseLabs, I frequently test and prototype product ideas. But every single time, I found myself spending 3–4 weeks repeating the exact same setup:

Configuring OAuth callback handling
Designing Entity Framework models and running PostgreSQL migrations
Handling JWT access & refresh tokens securely
Wiring up payment gateways and handling brittle webhooks
Building Docker environments that actually work locally and in production

By the time the app foundation was ready, the initial momentum was gone.

So, I spent the last two months building NetPulse—an enterprise-grade, clean-architecture SaaS boilerplate designed to crush that setup phase down to under 5 minutes.

Here is what I focused on solving during this build, how I structured the project, and the architectural decisions I made along the way.

1. Solving "Multi-Provider Payment Lock-In"

Most SaaS templates lock you into a single payment gateway (usually just Stripe). But depending on where your customers are or how you handle international taxes/MoR (Merchant of Record), you might prefer Polar.sh or Lemon Squeezy.

Instead of hardcoding Stripe everywhere, I engineered a Multi-Gateway Billing Engine in the backend:

               ┌──────────────────────┐
               │  IBillingService     │ (Abstraction Layer)
               └──────────┬───────────┘
                          │
     ┌────────────────────┼────────────────────┐
     ▼                    ▼                    ▼
[ StripeProvider ]  [ PolarProvider ]  [ LemonSqueezyProvider ]

Whether a subscription event (Free, Pro, Enterprise) comes from Stripe, Polar, or Lemon Squeezy, the API standardizes subscription lifecycles, checkout sessions, and webhook processing seamless inside ASP.NET Core.

The Tech Stack: Clean Architecture + Modern Frontend I wanted a stack that offers blazing performance, type safety, and zero bloat:

Backend: ASP.NET Core (.NET 8 Web API) using Clean Architecture (Domain, Application, Infrastructure, and WebApi presentation layers).

Database & ORM: PostgreSQL 16 + Entity Framework Core 8 (Npgsql) with code-first migrations and connection pooling.

Frontend: Next.js (App Router, React 18, TypeScript, Tailwind CSS, Shadcn UI / Radix primitives).

Auth & Security: ASP.NET Core Identity + JWT Bearer tokens + Google & GitHub OAuth 2.0. Integrated with Audit Logging, Rate Limiting, and Global Exception middleware.

The "One-Command Setup" Nightmare (Solved with Docker) Setting up a full-stack environment with .NET, Node, PostgreSQL, and local webhook tunnels manually is a headache for developers cloning a starter kit.

I packaged the entire ecosystem into a single docker-compose.yml setup. Running:

docker compose up -d --build

Boots up the Next.js frontend, .NET 8 Web API, PostgreSQL 16 DB, and an automated Stripe CLI webhook tunnel container simultaneously.

Here’s a quick glance at the repository structure:

NetPulse/
├── client/          # Next.js App Router Frontend
├── src/             # .NET 8 Backend Solution
│   ├── Core/        # Domain & Application Business Logic
│   └── WebApi/      # Controllers, Middlewares & Config
├── docker-compose.yml
└── NetPulse.sln

Key Lessons Learned from 2 Months of Building
Separation of Concerns saves sanity: Keeping payment provider integrations inside the Infrastructure layer means swapping gateways doesn't touch the core business logic.

Developer Experience (DX) matters most: A boilerplate shouldn't just be "code"—it needs step-by-step documentation, working .env.example templates, and zero-headache local deployment.

I’d Love Your Feedback! 💬
As I finalize version 1.0 of NetPulse, I’d love to get insights from fellow .NET devs, Next.js builders, and SaaS founders:

Payment Gateways: Do you prefer using traditional processors like Stripe, or Merchant of Record (MoR) platforms like Polar.sh / Lemon Squeezy for your SaaS?
Backend Architecture: Do you prefer strict Clean Architecture (4 layers) for SaaS templates, or a Vertical Slice Architecture approach?
What is the single most annoying feature you hate setting up manually in every new project?

Drop your thoughts in the comments below! I'll be active in the thread replying to architecture questions. 👇

I Spent 30+ Hours Building "The Boring SaaS Stack" So I Never Have To Do It Again

azhadsuhaimi — Tue, 18 Aug 2026 02:13:05 +0000

We’ve all been there:

You get an exciting idea for a micro-SaaS on a Friday night. You fire up your IDE, ready to build the core feature that solves a real problem.

Fast forward 3 weeks later... and you haven't even written a single line of business logic yet.

Instead, you’ve spent your precious free time configuring Google OAuth, wrestling with Stripe webhook signatures, building user profile pages, and tweaking Dark Mode CSS variables for the 100th time.

By the time the "boring 80%" of the app is finally functional, the initial excitement is gone, burnout hits, and another side project dies silently in a local directory.

Taming the "Boring 80%"

I got tired of repeating this painful cycle every time I wanted to test a new product idea. So, I decided to freeze new feature builds for a moment and focus entirely on creating a clean, unbloated foundation.

My goal was simple: Build a lean, production-ready setup once, and reuse it forever.

Here is the lightweight stack and core architecture I put together:

Backend: ASP.NET Core Web API (Clean, predictable, and fast execution)
Auth Layer: Social Sign-In (Google & GitHub OAuth) to eliminate email/password management overhead.
Billing: Stripe integration handling subscription checkouts (Pro / Enterprise tiers) and webhook listener setups.
UI/UX: Responsive Dashboard, basic credential profile management, and native Light/Dark theme toggling.

Here is a quick high-level look at how I kept the user context and session management minimal:

// Keeping auth payload lean while preserving claim context
public class CurrentUserContext
{
    public string UserId { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
    public string SubscriptionTier { get; set; } = "Free";
    public bool IsActive => SubscriptionTier != "Free";
}

The Big Dilemma: How Much "Boilerplate" Is Too Much?
While structuring this setup, I noticed a huge trap in existing commercial boilerplates: Over-engineering.

Many templates try to throw in every single library under the sun—multi-tenancy, complex RBAC permissions, 5 different payment gateways, blog engines, and heavy microservice abstractions. You end up spending more time deleting code you don't need than actually building your app.

I wanted to keep mine as stripped-down as possible while still covering the actual launch requirements.

I'd Love Your Input! 💬
Before I finalize version 1.0 of this foundation for my upcoming micro-SaaS launches, I want to hear from fellow builders and backend devs:

Multi-Tenancy vs. Single-User: Is built-in Organization/Team management an absolute MUST-HAVE for v1, or is simple single-user auth enough for an initial MVP?
Payment Integrations: Do you prefer sticking exclusively to Stripe, or is LemonSqueezy/Paddle support a dealbreaker for global taxes?
What is the single most annoying thing you usually hate about 3rd-party starter kits/boilerplates?

Drop your thoughts, hot takes, or architectural advice in the comments below! 👇

The Silent Killer of ASP.NET Core Performance: The N+1 Query Problem

azhadsuhaimi — Thu, 13 Aug 2026 03:26:10 +0000

It’s a classic story:

You build an API endpoint in ASP.NET Core using Entity Framework Core. You test it locally with 10 dummy records in your database, and it responds in a lightning-fast 15 milliseconds.

You push it to production. A few weeks later, as the user base and data grow, users start complaining that the app is loading painfully slow. You check your APM logs, and to your horror, a single HTTP GET request is triggering 1,001 SQL queries to the database.

Welcome to the N+1 Query Problem.

What Actually Happens Under the Hood?

The N+1 problem occurs when your application executes 1 query to fetch a parent record (or list of records), and then executes N additional queries to fetch related child data for every single parent item in that list.

Consider this innocent-looking LINQ code:

// 1 Query to fetch 100 active customers
var customers = await _context.Customers
    .Where(c => c.IsActive)
    .ToListAsync();

foreach (var customer in customers)
{
    // N Queries executed inside the loop!
    var latestOrder = await _context.Orders
        .FirstOrDefaultAsync(o => o.CustomerId == customer.Id);

    // Process order...
}

If you have 100 customers:

1 Query fetches the list of customers.

100 Queries are fired inside the foreach loop to get each customer's order.

Total database roundtrips = 101. Multiply that by network latency, and your database connection pool starts crying for help.

How to Catch It Before It Hits Production
EF Core makes lazy loading or lazy queries inside loops deceptively easy. Here are three ways to hunt down N+1 queries in your codebase:

Enable SQL Logging in Development In your appsettings.Development.json, set EF Core logging to Information:

"Logging": {
  "LogLevel": {
    "Default": "Information",
    "Microsoft.EntityFrameworkCore.Database.Command": "Information"
  }
}

Watch your terminal output. If you see a wall of identical SELECT statements scrolling past for a single request, you've got an N+1 issue.

Throw Exceptions on Unintended Queries If you use Lazy Loading, you can explicitly configure EF Core to throw an exception in development whenever a query is triggered implicitly:

optionsBuilder.UseSqlServer(connectionString)
    .ConfigureWarnings(warnings => 
        warnings.Throw(RelationalEventId.MultipleCollectionIncludeWarning));

The Fix: Eager Loading & Projection
Instead of fetching data inside loops, tell EF Core exactly what related data you need up-front so it generates a single JOIN, or project directly into a DTO.

Approach A: Eager Loading (Include)

// Generates a SINGLE SQL JOIN query
var customersWithOrders = await _context.Customers
    .Include(c => c.Orders)
    .Where(c => c.IsActive)
    .ToListAsync();

Approach B: Direct Projection (Best Performance)
Only fetch the fields your API actually returns. This avoids fetching unneeded columns and forces EF Core to construct an optimized SQL query:

var customerDtos = await _context.Customers
    .Where(c => c.IsActive)
    .Select(c => new CustomerDto
    {
        CustomerId = c.Id,
        CustomerName = c.Name,
        LatestOrderDate = c.Orders.Max(o => o.OrderDate)
    })
    .ToListAsync();

Conclusion
N+1 queries rarely show up as errors—they just quietly degrade your performance as your database scales. By adopting direct DTO projection and monitoring SQL logs during local development, you can catch these bottlenecks before your production database takes a hit.

How do you usually catch hidden ORM query issues in your team? Do you rely on APM tools, EF Core logging, or static analysis tools?

Let me know in the comments below!

Why Is My SQL Query Slow Only in Production? (The Parameter Sniffing Trap)

azhadsuhaimi — Mon, 10 Aug 2026 01:08:43 +0000

It’s every developer's favorite Friday afternoon nightmare:

A user complains that a feature in the app is hanging. You take the exact SQL query executed by the application, paste it into SQL Server Management Studio (SSMS), hit Execute... and it finishes in 0.02 seconds.

You run it again. Blazing fast.

Yet, inside the application, it continues to time out.

If you’ve been building database-backed apps long enough, you’ve almost certainly run into Parameter Sniffing.

What Actually Happens Under the Hood?

When a parameterized query or Stored Procedure runs for the very first time, SQL Server looks at the parameters passed in at that specific moment. It uses those values to estimate how many rows will be returned and compiles an execution plan tailored for that payload.

Scenario A: The first run passes a parameter that returns 5 rows. SQL Server creates a plan using an Index Seek. Fast and lightweight.
Scenario B: Later, another user passes a parameter that returns 500,000 rows. SQL Server reuses the cached "Index Seek" plan instead of doing an Index Scan.

Result? The server chokes trying to force a lightweight plan onto a massive dataset.

How to Catch Bad Plans in the Cache

Instead of guessing or restarting the SQL Server service (which wipes the entire cache and hides the evidence!), you can inspect the plan cache to see what parameter values were used during compilation versus execution.

Here’s a quick DMV snippet I use to find queries where the average execution duration is wildly higher than expected:

SELECT TOP 10
    qs.execution_count AS [Exec_Count],
    (qs.total_elapsed_time / 1000.0) / qs.execution_count AS [Avg_Duration_ms],
    (qs.total_worker_time / 1000.0) / qs.execution_count AS [Avg_CPU_ms],
    qs.total_logical_reads / qs.execution_count AS [Avg_Logical_Reads],
    SUBSTRING(st.text, (qs.statement_start_offset / 2) + 1,
        ((CASE qs.statement_end_offset
              WHEN -1 THEN DATALENGTH(st.text)
              ELSE qs.statement_end_offset
          END - qs.statement_start_offset) / 2) + 1) AS [Query_Text],
    qp.query_plan AS [XML_Execution_Plan]
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
WHERE qs.execution_count > 5
ORDER BY (qs.total_elapsed_time / qs.execution_count) DESC;
Clicking on the XML_Execution_Plan column lets you view the actual graphical execution plan directly in SSMS.

Look for the Parameter List inside the properties window—it will show you the Compiled Value vs the Runtime Value. If they look drastically different, you've found your parameter sniffing culprit.

How Do You Usually Fix Parameter Sniffing?
There are several ways to tackle this depending on the SQL Server version and business context:

Adding OPTIMIZE FOR UNKNOWN to the query.

Using local variables inside stored procedures.

Updating stale index statistics.

Using Query Store (if enabled) to force a known good plan.

How do you usually handle this in your production apps? Do you rely on query hints, or do you prefer fixing it at the database configuration level?

Drop your thoughts in the comments!

Why Do We Keep Forgetting About the Plan Cache in SQL Server?

azhadsuhaimi — Fri, 07 Aug 2026 23:26:04 +0000

Picture this: A user reports that the system is running painfully slow.

What is your immediate knee-jerk reaction?

For a long time, mine was to check table indexes, look at active locks, or blame the ORM for generating terrible SQL queries. But more often than not, the actual root cause was sitting right under my nose—inside SQL Server’s plan cache.

We talk a lot about optimizing queries during development, but we rarely talk about how much insight SQL Server passively collects for us in production while it's running.

The Unsung Hero: `sys.dm_exec_query_stats`

When SQL Server executes a query, it compiles an execution plan and caches it to save CPU time on subsequent runs. Along with that plan, it tracks execution metrics inside sys.dm_exec_query_stats.

It stores critical telemetry like:

Execution Count: Is a query slow because it’s inherently heavy, or because it’s being executed 50,000 times a minute (the classic N+1 problem)?
Worker Time: How much raw CPU time (total_worker_time) has this specific query consumed since the last service restart?
Logical Reads: Is the query thrashing memory and IO?

Instead of firing up SQL Server Profiler or Extended Events (which can add performance overhead to a live server), pulling directly from the plan cache is practically free.

The Tricky Part: Taming Large Batch Queries

If you've ever queried sys.dm_exec_query_stats and joined it with sys.dm_exec_sql_text, you’ve probably hit a common pain point: It gives you the entire batch or stored procedure text.

If a slow statement is hidden inside a 500-line stored procedure, looking at the entire text block doesn't immediately tell you which exact query ate the CPU.

To isolate the specific culprit, you have to do some offset math using statement_start_offset and statement_end_offset.

Here is a lightweight snippet I usually keep handy when I need to quickly inspect top CPU hogs without reading through endless blocks of SQL text:

SELECT TOP 10
    qs.execution_count AS [Execution_Count],
    qs.total_worker_time / 1000.0 AS [Total_CPU_ms],
    (qs.total_worker_time / 1000.0) / qs.execution_count AS [Avg_CPU_ms],
    qs.total_elapsed_time / 1000.0 AS [Total_Duration_ms],
    qs.total_logical_reads AS [Total_Logical_Reads],
    qs.creation_time AS [Plan_Cached_Since],
    DB_NAME(st.dbid) AS [Database_Name],
    OBJECT_NAME(st.objectid, st.dbid) AS [Object_Name],
    SUBSTRING(st.text, (qs.statement_start_offset / 2) + 1,
        ((CASE qs.statement_end_offset
              WHEN -1 THEN DATALENGTH(st.text)
              ELSE qs.statement_end_offset
          END - qs.statement_start_offset) / 2) + 1) AS [Query_Text]
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
ORDER BY qs.total_worker_time DESC;

Dividing total_worker_time by 1000 converts microseconds to readable milliseconds, and the SUBSTRING logic slices out the exact offending query statement.

What's Your First Move During a Performance Issue?
I’ve been working on organizing my own lightweight, read-only diagnostic scripts lately because I got tired of rewriting these DMV queries from memory during high-pressure troubleshooting.

But I’m curious to know how other developers handle this:

Do you regularly rely on Dynamic Management Views (DMVs) for quick health checks?

Or do you prefer APM tools like Datadog, New Relic, or built-in Extended Events?

Let’s discuss in the comments below!

DEV Community: azhadsuhaimi

Building NetPulse: A Production-Ready .NET 8 + Next.js SaaS Boilerplate

1. Solving "Multi-Provider Payment Lock-In"

I Spent 30+ Hours Building "The Boring SaaS Stack" So I Never Have To Do It Again

Taming the "Boring 80%"

The Silent Killer of ASP.NET Core Performance: The N+1 Query Problem

What Actually Happens Under the Hood?

Why Is My SQL Query Slow Only in Production? (The Parameter Sniffing Trap)

What Actually Happens Under the Hood?

How to Catch Bad Plans in the Cache

Why Do We Keep Forgetting About the Plan Cache in SQL Server?

The Unsung Hero: sys.dm_exec_query_stats

The Tricky Part: Taming Large Batch Queries

The Unsung Hero: `sys.dm_exec_query_stats`