DEV Community: Oğuzhan Ağır

Why ASP.NET Zero Is a Strong Starting Point for Building SaaS Products

Oğuzhan Ağır — Wed, 24 Jun 2026 07:23:49 +0000

Building a SaaS product is rarely just about building the main product features.

At first, most teams focus on the visible parts of the application. If the product is a CRM, they think about lead management, customer profiles, sales pipelines, and reporting. If it is an ERP, they focus on modules such as inventory, purchasing, finance, and operations. If it is a B2B portal, they think about dashboards, workflows, customer access, and integrations.

But once development starts, another reality appears.

Before users can actually use the product, the team needs to build a large amount of foundational infrastructure:

Login and registration
User management
Role and permission management
Tenant management
Dashboard and admin screens
Settings management
Audit logs
Email and notification structure
API architecture
Frontend and backend organization
Data isolation between customers
Subscription, package, or payment-related flows

These are not always the most exciting parts of a SaaS product. However, they are critical. They directly affect security, scalability, maintainability, and long-term product quality.

This is where ASP.NET Zero can become a strong starting point.

ASP.NET Zero Related Blog Post

ASP.NET Zero is not a ready-made SaaS product. It does not build your CRM, ERP, customer portal, or marketplace automatically. Instead, it gives development teams a production-oriented application foundation so they can spend less time building generic infrastructure and more time building the features that make the product valuable.

The Hidden Cost of Building SaaS Infrastructure from Scratch

Many companies underestimate how much time is spent on infrastructure before the first real business feature becomes usable.

For example, a startup planning to build a CRM may initially define features such as lead tracking, customer cards, sales activities, offer management, reports, and team collaboration.

But before these features can work properly, the product also needs a secure and manageable system behind them.

Who can access which customer records?

Can different companies use the same application without seeing each other’s data?

Can admins manage users and permissions?

Can the system keep logs of important actions?

Can different tenants have different settings?

Can emails be managed through templates?

Can the application scale as more customers join?

If all of these are built from zero, the MVP timeline can easily expand. What looks like a simple SaaS product may require months of foundational work before the team reaches the core product logic.

ASP.NET Zero helps reduce this initial infrastructure burden.

ASP.NET Zero as a SaaS Foundation, Not a Finished Product

It is important to position ASP.NET Zero correctly.

ASP.NET Zero should not be seen as a finished SaaS product that only needs small edits. It is better understood as a strong technical foundation for building custom SaaS applications.

This distinction matters.

Every serious SaaS product has its own business logic. A CRM, an ERP, a B2B ordering platform, or a branch management system will each have different workflows, data models, user journeys, and reporting needs.

ASP.NET Zero does not remove the need for custom development. Instead, it helps the development team start from a more advanced point.

This can be especially useful for companies that want to launch an MVP faster, validate the product idea earlier, and avoid spending the first phase of development only on technical infrastructure.

Built-in Multi-Tenancy for SaaS Products

Multi-tenancy is one of the most important concepts in SaaS architecture.

In a SaaS model, a single application often serves multiple customers, companies, branches, or organizations. Each customer expects their own data, users, roles, and settings to remain isolated.

For example:

A CRM may serve multiple companies.
An ERP system may serve different businesses from the same platform.
A dealer management system may serve many dealers.
A branch management system may support different locations under one structure.
A B2B portal may provide separate access for each client company.

Building this structure from scratch requires careful design. The development team needs to think about data isolation, tenant-specific settings, user access, security rules, and administration flows.

ASP.NET Zero provides a multi-tenancy-ready foundation, making it easier to build applications where multiple customers or organizations can use the same software environment with separated data and management areas.

It allows SaaS teams to design products that are not limited to one company or one internal operation. The same application can be structured to serve many customers, making the product more scalable as a commercial software business.

Faster MVP Development

One of the biggest advantages of using ASP.NET Zero is the ability to move faster toward an MVP.

An MVP should not mean a weak or poorly structured product. It should mean a focused first version that validates the core business idea with the minimum required scope.

However, many SaaS MVPs fail to launch quickly because teams spend too much time building generic infrastructure.

ASP.NET Zero can help reduce this problem.

With many foundational parts already available, the development team can focus earlier on the modules that directly create customer value.

For example, in a CRM product, the team can focus on lead management, pipeline workflows, customer history, and reporting. In an ERP product, the team can focus on inventory, purchasing, finance, and operational workflows. In a B2B portal, the team can focus on customer-specific dashboards, order flows, document sharing, and approval processes.

This can shorten the distance between idea and market validation.

Faster Module Development with ASP.NET Zero Power Tools

ASP.NET Zero Power Tools helps teams speed up repetitive CRUD development by generating code from entity definitions.

In SaaS products, many modules follow similar patterns: customers, leads, products, orders, branches, employees, requests, or records. Building each one manually requires repeating entity setup, database structure, application services, DTOs, permissions, and UI pages.

Power Tools reduces this repetitive work and gives developers a faster starting point for standard data management features.

It does not replace custom business logic, workflows, integrations, or reporting. However, it helps teams spend less time on boilerplate code and more time on the features that create real product value.

Better Starting Point for Custom Business Applications

ASP.NET Zero can be especially useful for companies building custom B2B software.

Some common use cases include:

CRM Systems

A CRM needs users, roles, customer records, activity tracking, dashboards, reporting, and often multi-company support.

ASP.NET Zero provides a strong base for the administrative and security side, allowing the team to focus on CRM-specific workflows.

ERP Systems

ERP products usually require complex permissions, multiple modules, auditability, settings, and structured administration.

Starting from a mature application foundation can reduce the amount of repetitive setup work.

Customer Portals

Customer portals often need secure login, customer-specific data access, document sharing, notifications, and role-based permissions.

ASP.NET Zero can support the foundation needed to build these portal experiences.

B2B SaaS Platforms

B2B SaaS platforms need a strong backend structure, tenant management, user control, and scalable application architecture.

ASP.NET Zero can help teams avoid starting from an empty project and instead begin with a more complete technical base.

Branch and Dealer Management Systems

Branch and dealer systems often require multi-tenant or multi-organization structures, role-based access, reporting, and administrative control.

ASP.NET Zero’s foundation is well aligned with these requirements.

Time and Cost Impact

Building SaaS infrastructure from scratch does not only increase development time. It also increases cost and project risk.

Every custom-built infrastructure module requires analysis, development, testing, security review, bug fixing, maintenance, documentation, and future improvements.

When a team builds everything manually, they are not only paying for initial development. They are also taking responsibility for maintaining all of those foundational systems over time.

ASP.NET Zero can reduce this burden by providing many common application components from the start.

This does not eliminate development cost. Custom business logic, UI requirements, integrations, reporting, workflows, and product-specific modules still need to be designed and built.

However, it can help reduce the amount of time spent on repetitive infrastructure work.

Why This Matters for Non-Technical Founders

For non-technical founders and business owners, the value of ASP.NET Zero may not be immediately obvious.

It is not simply about having ready-made technical modules.

The real value is that the development team can start with a stronger foundation instead of spending the early stages of the project on invisible infrastructure.

This means:

Faster MVP planning
Less duplicated development work
More focus on business features
Better structure for future growth
A more professional starting point
Reduced technical uncertainty in the first phase

For a founder, this can directly affect budget, launch timeline, and product validation speed.

Conclusion

Building a SaaS product is not only about developing the features users see. A significant part of the work is hidden in the infrastructure: authentication, authorization, tenant management, user roles, admin panels, audit logs, settings, email structure, and scalable architecture.

ASP.NET Zero gives teams a strong foundation for these common requirements, helping them avoid rebuilding the same infrastructure from scratch.

It is not a finished SaaS product, but for SaaS ideas, B2B platforms, CRM systems, ERP systems, customer portals, and branch or dealer management solutions, it can be a strong starting point for building faster and more predictably.

Start Building with ASP.NET Zero

If you are planning to build a SaaS product, CRM, ERP, customer portal, or B2B platform, ASP.NET Zero gives you a strong foundation instead of starting from scratch.

Explore ASP.NET Zero pricing and choose the right plan for your SaaS product.

View Pricing

React Performance: Preventing Unnecessary Re-renders

Oğuzhan Ağır — Wed, 11 Mar 2026 21:47:24 +0000

The original and complete version of this article is available on the ASP.NET Zero blog:
https://aspnetzero.com/blog/react-performance-and-preventing-unnecessary-renders

React applications can sometimes feel slow even when everything appears to work correctly. The UI renders, no errors occur, yet interactions feel sluggish. Buttons respond with slight delays, scrolling may stutter, and typing can occasionally feel laggy.

In many cases, the underlying reason is unnecessary component re-renders.

React does not rebuild the entire DOM on every update. Instead, when a component renders:

• The component function executes again
• React generates a new virtual tree
• React compares it with the previous render
• Only the necessary DOM updates are applied

This means a re-render does not necessarily mean a DOM update. However, every render still executes the component function again, which may involve expensive calculations, large lists, or complex component trees.

A Common Cause of Performance Issues

One of the most common causes of unnecessary renders is placing state too high in the component tree.

const Page = () => {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        {count}
      </button>
      <HeavyComponent />
    </>
  );
};

Even though HeavyComponent does not use the count state, it will still re-render whenever the parent component renders.

A better approach is state colocation, meaning state should live in the lowest possible component that actually needs it.

Memoization and Referential Stability

React also provides tools such as:

• React.memo
• useMemo
• useCallback

These tools help prevent unnecessary renders by stabilizing props and avoiding repeated calculations. However, they should be used carefully, because excessive memoization can add complexity without improving performance.

Rendering Large Lists

When working with very large lists, rendering every element can become expensive. In such cases, techniques like virtualization can significantly improve performance by rendering only the visible portion of the list.

Libraries such as:

• react-window
• react-virtuoso

allow React applications to handle thousands of rows efficiently.

Measure Before Optimizing

Performance optimization should always begin with measurement rather than assumptions. Tools like the React DevTools Profiler help identify which components render, why they render, and how long they take.

Without profiling, optimization often becomes guesswork.

Read the Full Article

This post only provides a brief overview of the topic.

The full article explains in detail:

• React re-render mechanics
• architectural performance principles
• Context API performance pitfalls
• referential stability problems
• real-world optimization strategies for large React applications

Read the complete guide here:
https://aspnetzero.com/blog/react-performance-and-preventing-unnecessary-renders

The True Face of Referential Equality and Optimizations in React

Oğuzhan Ağır — Fri, 06 Mar 2026 20:40:59 +0000

When performance issues arise in React applications, React.memo, useMemo, and useCallback are usually the first things that come to mind. In practice, however, adding these tools often merely complicates the code without delivering the expected performance boost.

The underlying reason isn't that React is inadequate, but rather a fundamental misunderstanding of referential equality within React's render model and how these optimization tools actually work.

React's Decision Mechanism: Value vs. Reference

When deciding whether to re-render a component, React doesn't check the contents of the data (structural equality). Instead, it checks if the data points to the same location in memory (referential equality). It uses a shallow comparison similar to JavaScript's Object.is() method.

const a = { value: 1 };
const b = { value: 1 };

console.log(a === b); // false

In the example above, even though objects a and b have identical content, they point to different memory locations. Therefore, React considers them completely different values. This becomes critical especially when objects, arrays, and functions are passed as props to child components.

The Shallow Comparison Preference

React.memo, PureComponent, and Hook dependency arrays intentionally perform a shallow comparison. If React were to deeply compare every property within objects during every render, the performance cost would be significantly higher.

const Child = React.memo(({ options }) => {
  /* ... */
});

const Parent = () => {
  // A new 'options' object is created in memory during every render.
  const options = { pageSize: 20 };

  return <Child options={options} />;
};

In this example, every time the Parent component renders, a new options object is created in memory. Even though the Child component is wrapped in React.memo, the optimization cannot kick in because the reference of the options prop has changed, causing the Child to re-render unnecessarily.

Impact on the Reconciliation Process

In React, rendering does not mean directly updating the DOM. During the render phase, React generates a new component tree (Fiber tree) and compares it with the previous one (Reconciliation).

If a component's state or prop references have changed, React re-renders that component and its entire subtree. Even if there are no actual changes to the DOM, constantly changing references force React to perform this comparison repeatedly, wasting CPU cycles.

Why useMemo and useCallback Fall Short

These two Hooks are designed to keep references stable (memoization), but when implemented incorrectly, they only add overhead to the application.

The Limits of useMemo: useMemo is used to cache expensive calculations or keep references stable. However, if a value in the dependency array changes its reference on every render, the calculation inside useMemo will re-run every time. In this case, not only does the optimization fail, but React is also burdened with the extra work of tracking these dependencies.
The Role of useCallback: useCallback caches function definitions. But if a function depends on a frequently updated state (e.g., state changing on every keystroke in a text input), this function will be recreated with every keystroke. Passing this function as a prop to child components will cause them to continuously re-render as well.

Every Render Creates Its Own Scope (Closures)

In React, every render creates its own lexical scope. This means that during each render, a "snapshot" of the current state and prop values is taken.

Functions within a component capture the values belonging to that specific render. When the state updates, the component re-renders, a new snapshot is taken, and naturally, brand-new functions working with these new values are created in memory. This is React's expected behavior.

Architectural Solutions Over Forced Optimization

Instead of trying to forcefully stabilize references using useMemo and useCallback, rethinking the component architecture is often a more permanent and cleaner solution.

Moving State Down: If a piece of state only affects a specific child component, move that state directly into the child rather than keeping it in the parent. This prevents the parent from rendering unnecessarily.
Lifting Content Up (Children Prop): By passing expensive components to a parent via the children prop, you can ensure that the child components are unaffected when the parent's state changes.
Using Primitive Values: Instead of passing an entire object to child components as a prop, pass only the necessary primitive values like string, number, or boolean. Primitives are always compared by value, not by reference.

React.memo, useMemo, and useCallback are not magic wands. These tools only provide benefits in applications where the architecture and data flow are properly structured. If you are experiencing performance issues, rather than immediately reaching for these Hooks, it is much better to ask architectural questions like, "Where should this component's state live?" or "Do I really need to pass this prop?"

When Are Custom Hooks an Advantage in React, and When Do They Become a Liability?

Oğuzhan Ağır — Fri, 06 Feb 2026 08:34:02 +0000

Custom hooks are one of React’s most powerful abstraction tools but they’re also one of the easiest ways to quietly make a codebase harder to understand.

In real projects, I’ve often seen hooks introduced with good intentions, only to later cause questions like:

What does this hook actually do?

Why is changing this so risky?

Why do I need to read three hooks to understand one component?

This article looks at when custom hooks genuinely improve readability and reuse, and when they become a liability due to premature or over generalized abstraction. It focuses on practical signals, concrete examples, and questions you can ask before extracting logic into a hook.

If you’ve ever wondered whether a hook is simplifying your component or just hiding complexity, you might find this useful:

👉 https://aspnetzero.com/blog/react-custom-hooks-pros-cons

An ASP.NET Core + React Template Worth Reviewing

Oğuzhan Ağır — Thu, 22 Jan 2026 12:06:05 +0000

For those looking for an example of how a starting structure can be set up for ASP.NET Core + React, sharing this as a reference.

There is a React based UI on the ASP.NET Zero side. It makes it possible to see how concerns such as login, authorization, tenant separation, basic administration pages, and localization are handled on the React side.

On the frontend, Vite, Ant Design, Redux Toolkit, and TypeScript are used. The backend follows a familiar ASP.NET Core structure.

For those who want to take a closer look, the article is here:
https://aspnetzero.com/blog/react-ui-has-arrived-in-aspnet-zero

ASP.NET Core Dependency Injection From Scopes & Lifetimes to .NET 9 Source Generators

Oğuzhan Ağır — Thu, 23 Oct 2025 06:19:24 +0000

Dependency Injection in ASP.NET Core is simple... until you hit a subtle memory leak or a captive dependency bug.

Are you positive you're not creating a "captive dependency"? Do you know the right way to use a Scoped service (like a DbContext) inside a Singleton background worker?

I've just published a guide that goes beyond the basics and dives into the advanced patterns and new features you need to know.

This isn't just AddTransient vs. AddScoped again. We cover:

The Captive Dependency trap (and how to fix it).
Using IServiceScopeFactory in IHostedService like a pro.
.NET 9 Source Generators for blazing fast startup & Native AOT.
Keyed Services ([FromKeyedServices("key")]) for runtime flexibility.
The Decorator Pattern for clean, cross-cutting concerns.
Proper async cleanup with IAsyncDisposable.

You can move beyond the basics and start writing robust, testable, and high performing DI compatible code. This guide shows you how.

👉 Read the Full Guide on ABP.io

What's your favorite Dependency Injection hack? Let me know in the comments! 👇

Building an In-Memory Background Job Queue in ASP.NET Core (Intro + Deep Dive Link)

Oğuzhan Ağır — Tue, 30 Sep 2025 11:51:53 +0000

If you've ever wondered how to run asynchronous, long running tasks without blocking your API responses and without pulling in external dependencies like Hangfire or RabbitMQ this might interest you.

In my latest article on ABP Community, I walk through how to build an in memory background job queue from scratch using only built in .NET tooling (IHostedService, System.Threading.Channels, dependency injection, etc.). It’s ideal for scenarios where you need lightweight queueing in a single application instance (with the usual caveats). 👇

What you’ll learn

How to define a IBackgroundTaskQueue interface
Implementing it using Channel<T>
Creating a BackgroundService that continuously dequeues and executes jobs
Wiring it into the ASP.NET Core DI container
Pitfalls and limitations of an in memory approach (e.g. job loss upon restart, scalability)
When to switch to more robust solutions (Hangfire, message brokers)

If you like hands on, from scratch tutorials, here’s the full article:
How to Build an In Memory Background Job Queue in ASP.NET Core from Scratch