DEV Community: azhadsuhaimi

"Tech stack doesn't matter" is terrible advice when you're a solo dev

azhadsuhaimi — Tue, 22 Sep 2026 00:58:29 +0000

You’ve probably heard this advice a hundred times on X, Reddit, and Indie Hackers:

"Users don't care about your tech stack. Just pick whatever is fast and build your MVP."

In theory, this sounds smart. In practice, as a solo developer, picking a tech stack that you aren't completely comfortable with or that lacks solid production features leads straight to burnout.

When you spend 80% of your nights debugging OAuth state mismatches, fixing database migration scripts, or fighting CORS policies on deployment, your motivation evaporates. Fast.

The stack doesn't matter to the user, but it matters immensely to you—the person who has to maintain it at 2 AM.

Why I Settled on .NET 8 + Next.js

When I started planning projects at PulseLabs, I tried various mainstream SaaS templates. Most were heavily biased toward Node.js or Python backends.

While they're fine for simple apps, I wanted something rock-solid for long-term scalability:

Strong Typing & Performance: .NET 8 brings incredible runtime speed and clean C# syntax.
Enterprise-Grade Security: Built-in identity management and robust ORM features via Entity Framework Core.
Modern Frontend DX: Next.js with React Server Components, TypeScript, and Shadcn UI for fast UI development.

The problem? Finding a complete, production-ready template that seamlessly connects a decoupled .NET Web API to a modern Next.js frontend is surprisingly hard.

So, I spent the last few months building NetPulse.

What Makes This Setup Different

Instead of forcing a rigid framework, I focused on making the plumbing modular and easy to tear down if needed.

1. Pluggable Payment Engine

Most templates lock you into Stripe. But if you operate globally, tax compliance is a nightmare. NetPulse includes an abstraction layer that lets you switch between Stripe, Polar.sh, and Lemon Squeezy with a single config change. No core code rewrites required.

2. Fully Containerized Workflow

Local setup is usually where boilerplates fail. Rather than writing a 20-step setup guide, everything is wrapped inside Docker Compose:

Next.js Client
.NET 8 Web API (Clean Architecture)
PostgreSQL 16
Stripe CLI container for routing local webhooks

Running docker compose up -d --build gets the entire ecosystem up and running immediately.

3. Real Clean Architecture

The backend is split into 4 logical layers (Domain, Application, Infrastructure, WebApi). Core business logic is isolated from database drivers and external SDKs, keeping the codebase readable as the app grows.

Tech Stack Breakdown

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 System: ASP.NET Core Identity, JWT Bearer tokens, Google & GitHub OAuth 2.0
Payments: Stripe, Polar.sh, Lemon Squeezy (Multi-provider abstraction)
DevOps: Multi-stage Dockerfiles + Docker Compose

The Goal

The point of a good boilerplate isn't to over-engineer your app. It's to eliminate all the repetitive setup so you can spend 100% of your energy building the features that actually make your product unique.

I Spent 3 Weeks Setup-Helling a Full-Stack SaaS Stack Before Writing a Single Line of Business Logic

azhadsuhaimi — Fri, 11 Sep 2026 03:47:26 +0000

Check out PulseLabs to explore production-ready developer tools, SQL Server performance diagnostics, and full-stack SaaS starters built to help you ship faster!

The $5,000 Waste: Why 80% of Indie SaaS Projects Die in Week 2

Imagine this scenario:

You have a killer SaaS idea. You spend your weekend excited, sketching out database schemas and dreaming of your first 100 paying users. On Monday night, you sit down to start coding.

By Friday night:

You are down a rabbit hole trying to get ASP.NET Core Identity refresh tokens to play nicely with Next.js App Router client sessions.
You are banging your head against the wall because Google and GitHub OAuth redirect callbacks keep returning claim errors.
Your Stripe webhook handler crashes every time a test checkout fires because the payload signature does not match locally.
You have not even written a single line of the actual app feature that your users will pay you for!

This is the ultimate momentum killer.

Most developers do not fail because their idea was bad. They fail because by the time they finish gluing together authentication, database ORMs, billing webhooks, rate limiting, and CORS headers, they are completely burned out.

How to Avoid the Boilerplate Burnout Trap

If you want to actually launch your SaaS product before losing your sanity, follow these three rules:

Never build authentication or billing from scratch twice: Set up pluggable abstractions for Stripe, Polar, or Lemon Squeezy once, and re-use them.
Containerize your local dependencies from Day 1: Do not waste days fixing database setup issues or port conflicts on your machine. Use Docker Compose so your DB, API, and frontend boot in a single command.
Use standard Clean Architecture patterns: Do not mix database logic inside API controllers. Keeping a clear separation between Domain, Application, and Infrastructure layers prevents spaghetti code as your app grows.

Meet NetPulse: The Production-Ready .NET 8 + Next.js SaaS Starter

To stop wasting weeks on repetitive setup work, I built NetPulse—an enterprise-grade SaaS starter kit engineered for developers who want to bypass the setup headache and start shipping features immediately.

Architecture Breakdown

NetPulse follows strict Clean Architecture principles on the backend combined with a modern Next.js 14 App Router client:

NetPulse/
├── client/                               # Next.js App Router Frontend
│   ├── src/
│   │   ├── app/                          # Auth pages, Dashboard & Landing
│   │   ├── components/                   # UI components & Radix wrappers
│   │   └── lib/                          # Axios API clients & helpers
│   └── Dockerfile
├── src/                                  # .NET 8 Backend Solution
│   ├── Core/
│   │   ├── Domain/                       # Enterprise Entities & Domain models
│   │   ├── Application/                  # Business logic, DTOs & CQRS
│   │   └── Infrastructure/               # EF Core, Identity, Payment Gateways
│   └── WebApi/                           # Controllers & Middlewares
├── .env.example
└── docker-compose.yml                    # Multi-container setup

What Is Included Under the Hood?

Dual Gateway Billing Engine: Built-in multi-provider support for Stripe and Polar.sh with automated webhook handlers for subscription lifecycles (subscription.created, checkout.created).
Enterprise Authentication: ASP.NET Core Identity with JWT Bearer Access Tokens, refresh tokens, and social login for Google & GitHub out of the box.
Pre-configured Security: Middleware for IP Rate Limiting, Audit Logging, and Global Exception Handling.
Turnkey Docker Setup: Launch PostgreSQL, .NET 8 Web API, and Next.js in 1 command.

Spinning Up in Under 5 Minutes

# Clone repository and copy environment variables
git clone <your-repo>
cd NetPulse
cp .env.example .env

# Spin up containers
docker compose up -d --build

# Run database migrations
dotnet ef database update --project src/Core/Infrastructure --startup-project src/WebApi

That is it! Your entire backend, database, client app, and API documentation (Swagger) are up and running.

Final Thoughts

Do not let setup fatigue ruin another great project idea. Focus your time on solving real user problems and building unique product features—not wrestling with identity protocols or billing webhooks.

Explore more developer tools, diagnostic scripts, and production starters over at PulseLabs!

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

azhadsuhaimi — Mon, 07 Sep 2026 08:28:55 +0000

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.

Why I Built a .NET 8 + Next.js SaaS Boilerplate (And 4 Architecture Decisions I Made)

azhadsuhaimi — Tue, 01 Sep 2026 10:44:55 +0000

Building a full-stack SaaS application from scratch is usually fun—until you reach the part where you have to wire up identity managers, ORM migrations, CORS policies, OAuth redirects, and payment webhooks.

Over the past two months of building at PulseLabs, I found myself solving the exact same foundation problems repeatedly. To eliminate this friction permanently, I engineered NetPulse: a production-ready starter kit leveraging .NET 8 Web API, Next.js App Router, PostgreSQL 16, and Docker.

Instead of a generic feature walkthrough, I want to share the 4 core architectural decisions I made during this build and why I structured it this way.

1. Enforcing Clean Architecture in the Backend

Many SaaS templates bundle all backend logic directly inside API controllers or Next.js route handlers. While fast initially, it quickly turns into spaghetti code as the business logic grows.

For NetPulse, I separated the backend into 4 distinct projects within a single solution:

NetPulse.sln
├── Core/
│   ├── Domain/         # Pure enterprise entities (User, Subscription, AuditLog)
│   ├── Application/    # DTOs, Service Interfaces, CQRS & Business Logic
│   └── Infrastructure/ # EF Core, Identity, Mailers, Payment SDKs
└── WebApi/             # Controllers, Middlewares, Program.cs setup

Why this matters:
The Domain layer has zero dependencies on external libraries. If you want to switch from Entity Framework Core to Dapper, or swap database providers, your core business logic remains completely untouched.

Abstraction Layer for Payment Billing (Stripe, Polar, Lemon Squeezy) One of the most frustrating decisions when launching a project is choosing a payment provider. Traditional processors like Stripe are great, but managing international VAT and sales tax can be a nightmare for solo builders. Merchant of Record (MoR) solutions like Polar.sh or Lemon Squeezy handle taxes automatically.

Instead of hardcoding a single vendor, I built a pluggable abstraction layer around an IBillingService interface.

public interface IBillingService
{
    Task<CheckoutSessionResponse> CreateCheckoutSessionAsync(string userId, string priceId);
    Task HandleWebhookAsync(string jsonPayload, string signatureHeader);
    Task SyncSubscriptionStatusAsync(string customerId);
}

How it works in practice:
Developers using the template don't need to rebuild webhook infrastructure when changing providers. You simply set your preferred active provider in Program.cs / .env (e.g., Stripe, Polar, or Lemon Squeezy), and the core identity and subscription models automatically handle tier updates (Free, Pro, Enterprise).

JWT Bearer Tokens + ASP.NET Core Identity & OAuth Handling authentication between a decoupled SPA (Next.js) and a backend API (.NET) can get tricky with CORS and cookie/token security.

I implemented ASP.NET Core Identity with custom JWT Bearer handling, paired with OAuth 2.0 social sign-ins (Google & GitHub).

[ Next.js Client ] ──(OAuth Redirect)──► [ Provider (Google/GitHub) ]
         │                                          │
         │ (Receive Callback Code)                   │
         ▼                                          ▼
[ Send Code to .NET API ] ───────────────► [ Validate & Issue JWT + Refresh Token ]

Short-lived access tokens keep stateless API calls secure.
Refresh tokens stored in PostgreSQL allow seamless session renewal without forcing the user to re-login.

Zero-Lock-In Containerization via Docker Compose Setting up PostgreSQL, .NET SDK, Node modules, and local webhook listeners manually on every new development machine takes hours.

I containerized the ecosystem using a single root docker-compose.yml. With one command:

docker compose up -d --build

It spins up:

Next.js Frontend (localhost:3000)
.NET 8 Web API (localhost:44366 with interactive Swagger UI)
PostgreSQL 16 Container (localhost:5432)
Stripe CLI Container (automatically tunneling live local webhooks to the backend controller)

🛠️ Summary of Tech Stack
⚡ Backend API: ASP.NET Core 8 Web API structured with Clean Architecture (Domain, Application, Infrastructure, WebApi)

🎨 Frontend Client: Next.js (App Router), TypeScript, Tailwind CSS, and Shadcn UI / Radix primitives

🗄️ Database & ORM: PostgreSQL 16 + Entity Framework Core 8 (Npgsql) with code-first migrations

💳 Pluggable Billing: Pre-configured handlers for Stripe, Polar.sh, and Lemon Squeezy

🔐 Auth & Security: ASP.NET Core Identity, JWT Bearer tokens, and OAuth 2.0 (Google & GitHub)

🐳 DevOps & Tooling: Multi-stage Dockerfiles orchestrated via a single Docker Compose setup

Let's Discuss Architecture 🗣️
If you're building SaaS products with .NET or Next.js, I'd love to hear your thoughts:

Clean Architecture vs. Vertical Slice: Do you prefer splitting code into strict layers (Domain/App/Infra), or grouping everything by feature folder?
Database Choice: Do you lean towards PostgreSQL or SQL Server when deploying .NET Web APIs in production?
Payment Gateways: Has anyone here transitioned from Stripe to an MoR provider like Polar or Lemon Squeezy? How was your experience?

Leave a comment below—let's chat code! 👇

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

"Tech stack doesn't matter" is terrible advice when you're a solo dev

Why I Settled on .NET 8 + Next.js

What Makes This Setup Different

1. Pluggable Payment Engine

2. Fully Containerized Workflow

3. Real Clean Architecture

Tech Stack Breakdown

The Goal

I Spent 3 Weeks Setup-Helling a Full-Stack SaaS Stack Before Writing a Single Line of Business Logic

The $5,000 Waste: Why 80% of Indie SaaS Projects Die in Week 2

How to Avoid the Boilerplate Burnout Trap

Meet NetPulse: The Production-Ready .NET 8 + Next.js SaaS Starter

Architecture Breakdown

What Is Included Under the Hood?

Spinning Up in Under 5 Minutes

Final Thoughts

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

The Pain Points I Wanted to Eliminate

1. Payment Provider Lock-In

2. Clean Architecture (Without the Over-Engineering)

3. One Command Local Setup

What’s Under the Hood?

Final Thoughts

Why I Built a .NET 8 + Next.js SaaS Boilerplate (And 4 Architecture Decisions I Made)

1. Enforcing Clean Architecture in the Backend

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`