Forem: qodors

Building Modern Apps with Blazor and .NET MAUI — What Actually Works in 2026

qodors — Wed, 29 Apr 2026 10:10:32 +0000

By Team Qodors — Custom Software Development & IT Consultancy

Microsoft’s Blazor and .NET MAUI don’t get the hype that React or Flutter get. But for teams already working in the .NET ecosystem — or businesses that need enterprise-grade applications with strong backend integration — they’re becoming serious contenders.

At Qodors, .NET has been part of the stack for years. Blazor and .NET MAUI aren’t new to the team, but the way they’ve matured over the last two years has changed how certain projects get built. Especially when the requirement is a content management system (CMS) paired with a cross-platform application that needs to work on web, desktop, and mobile.

This isn’t a tutorial. It’s a breakdown of what Blazor and .NET MAUI actually do well, where they fall short, and when it makes sense to use them instead of the usual suspects like React, Angular, or Flutter.

What Is Blazor, Really?

Blazor is Microsoft’s framework for building interactive web applications using C# instead of JavaScript. That’s the headline feature — write your frontend logic in the same language as your backend.

There are two main flavors:

Blazor Server — the app runs on the server, and UI updates get pushed to the browser over a SignalR connection. Fast to build, low client-side load, but requires a persistent connection to the server.

Blazor WebAssembly (WASM) — the app runs entirely in the browser using WebAssembly. No server dependency after the initial load. Feels more like a traditional SPA (single-page application).

For teams that live in the .NET world — ASP.NET Core, Entity Framework, SQL Server, Azure — Blazor removes the mental overhead of switching between C# on the backend and JavaScript on the frontend. The same developers can work across the full stack without context switching.

That’s a real productivity boost for certain teams. Not everyone. But for the right setup, it’s significant.

What Is .NET MAUI?

.NET MAUI (Multi-platform App UI) is Microsoft’s framework for building native cross-platform apps. One codebase. Runs on Windows, macOS, iOS, and Android.

It’s the successor to Xamarin.Forms, rebuilt from the ground up to be faster, cleaner, and better integrated with modern .NET.

MAUI apps are written in C# and XAML (or pure C# if XAML isn’t the preference). They compile to native apps, so performance is solid. Unlike hybrid frameworks that wrap web views, MAUI apps feel native because they are native.

For businesses that need internal tools, field service apps, or enterprise applications that run on desktop and mobile — MAUI is a strong option. Especially when the backend is already .NET and Azure.

Blazor + .NET MAUI — Why Use Them Together?

Here’s where it gets interesting.

Blazor components can run inside a .NET MAUI app using something called Blazor Hybrid. That means the same UI code written for a Blazor web app can also be used in a desktop or mobile app built with MAUI.

One set of components. Multiple platforms.

This isn’t perfect code reuse — there are platform-specific quirks, navigation differences, and UI adjustments needed. But it’s close enough that a single development team can build a web app, a Windows desktop app, an iPad app, and an Android app without rewriting the entire frontend for each platform.

For businesses building internal tools or SaaS products that need to work across web and mobile, this approach cuts development time significantly.

At Qodors, this pattern has been used on projects where the client needed:

A web-based admin dashboard for managing content
A mobile app for field staff to access the same content offline
A Windows desktop app for office users who prefer native applications

Instead of building three separate frontends, the core UI was built once in Blazor and deployed across all three platforms using MAUI for mobile and desktop.

Building a CMS with Blazor — What That Looks Like

A content management system built with Blazor typically follows this structure:

Backend — ASP.NET Core Web API handling authentication, database access, file uploads, and business logic. SQL Server or PostgreSQL for the database. Azure Blob Storage for media files.

Frontend — Blazor WebAssembly or Blazor Server for the admin interface. Editors create and manage content. Real-time previews. Role-based access control. Media library. Version history.

Content Delivery— A separate public-facing website or mobile app pulls content via the API. Could be another Blazor app. Could be React, Next.js, or a MAUI mobile app. The CMS just serves the data.

Why Blazor for the CMS admin panel?

Rich UI components are easier to build in Blazor than in traditional MVC views.
No need to manage a separate JavaScript framework for the admin interface.
Tight integration with .NET identity and authentication.
Fast development for CRUD operations, forms, and data tables.
Works well with Entity Framework for database operations.

It’s not the only way to build a CMS, but for .NET-heavy teams, it’s efficient.

— -

Using .NET MAUI for the Content Consumption App

Once the CMS exists and content is managed through the Blazor admin panel, the next step is building the app that actually displays that content to end users.

This is where .NET MAUI comes in.

A MAUI app connects to the same backend API the CMS uses. It pulls content — articles, images, videos, product listings, whatever the CMS manages — and displays it in a native mobile or desktop interface.

Because MAUI supports offline storage using SQLite, the app can cache content locally. Users can browse even without an internet connection. When they reconnect, the app syncs with the server.

For field workers, sales teams, or anyone who needs access to company content on the go, this setup works well. Web apps require a browser and an internet connection. MAUI apps run natively and handle offline scenarios cleanly.

Where Blazor and .NET MAUI Actually Make Sense

Not every project is a good fit. Here’s when this stack works best.

Enterprise applications. Large organizations already using .NET, SQL Server, and Azure. Internal tools, employee portals, CRM systems, inventory management. Blazor and MAUI fit naturally into existing infrastructure.

Line-of-business apps. Applications built for specific business processes — inspections, audits, data collection, reporting. Often need to work offline. Need tight integration with backend systems. MAUI handles this well.

Hybrid web + mobile products. SaaS platforms that need a web admin interface and a mobile app for end users. Sharing Blazor components across both reduces duplication.

Teams already skilled in .NET. If the team knows C#, Entity Framework, and ASP.NET Core, learning Blazor and MAUI is a much smaller jump than learning React, Flutter, and a new backend framework.

Projects where JavaScript fatigue is real. Some teams are tired of the constant churn in the JavaScript ecosystem. Blazor offers stability. Microsoft’s release cycles are predictable. Breaking changes are rare.

Where Blazor and .NET MAUI Fall Short

No framework is perfect. Here’s where this stack struggles.

Smaller talent pool. Finding developers who know React or Flutter is easier than finding Blazor or MAUI specialists. The .NET community is strong, but it’s smaller than the JavaScript world.

WebAssembly file sizes. Blazor WASM apps have large initial download sizes compared to optimized React or Vue apps. That’s improving, but it’s still a consideration for public-facing websites with heavy traffic.

Mobile app performance. MAUI is solid, but Flutter still has an edge in rendering performance and UI flexibility. For consumer-facing apps where every millisecond of startup time matters, Flutter is often the better choice.

Limited third-party component libraries. The ecosystem is growing, but Blazor and MAUI don’t have the same breadth of open-source UI libraries as React or Flutter. More custom work is often needed.

Not ideal for content-heavy public websites. Blazor works for web apps, but for marketing sites, blogs, or e-commerce storefronts, frameworks like Next.js or Astro with static generation are faster and better for SEO.

Blazor and MAUI shine in enterprise and business contexts. They’re not the best choice for every project type.

Real-World Example — How Qodors Used This Stack

A logistics client needed a system to manage delivery schedules, driver assignments, and shipment tracking. The operations team needed a web dashboard. Drivers needed a mobile app. Warehouse managers wanted a Windows desktop app.

The solution:

Backend: ASP.NET Core Web API + SQL Server
CMS/Admin Dashboard: Blazor WebAssembly
Mobile App (iOS/Android): .NET MAUI
Desktop App (Windows): .NET MAUI

Same backend. Same API. Shared Blazor components for common UI elements like shipment lists, driver profiles, and schedule views.

Development time: 8 weeks instead of the 14–16 weeks it would have taken building three separate native apps.

The client got a unified system that worked across all platforms, with a single codebase to maintain going forward.

That’s the kind of project where Blazor and MAUI make perfect sense.

— -

The Honest Take

Blazor and .NET MAUI aren’t trying to replace React or Flutter. They’re not the trendy choice. They don’t generate the same buzz on Twitter or get featured in every YouTube tutorial.

But for businesses already invested in the Microsoft ecosystem, or for teams that prefer working in C# and want to avoid JavaScript entirely, they’re powerful tools that deliver real results.

At Qodors, the decision always comes down to the project requirements, the client’s existing infrastructure, and the team’s skillset. Sometimes that means React and Node.js. Sometimes it means Flutter. And sometimes it means Blazor and .NET MAUI.

The goal isn’t to use the most popular framework. It’s to use the one that gets the product shipped on time, on budget, and built to last.

Building a CMS, internal tool, or cross-platform app? Need a team that knows when to use .NET and when to use something else? Reach out to Qodors. Happy to talk through what fits best.

Team Qodors

🌐 www.qodors.com
📧 contact@qodors.com

— -

Blazor #DotNET #NETMAUI #MicrosoftDevelopment #CMS #CrossPlatformApps #EnterpriseApps #CustomSoftware #WebDevelopment #MobileAppDevelopment #Qodors #ASPNETCore #CSharp #SoftwareDevelopment #AppDevelopment #BusinessApps #HybridApps #ContentManagement

SQL Server Running Slow? Here's What Actually Fixes It.

qodors — Fri, 24 Apr 2026 08:19:58 +0000

Every growing business hits this wall at some point. The application that worked perfectly six months ago now takes forever to load. Users start complaining. The dev team blames the server. The infrastructure team blames the code.

Most of the time, it's neither. It's the database.

SQL Server is built to handle serious workloads. But without regular maintenance and smart optimization, even the most powerful setup starts choking under pressure.

At Qodors, database performance optimization is part of the daily work across multiple client projects. Not theoretical best practices — real fixes on real production systems serving real users.

Here are the things that consistently make the biggest difference when a SQL Server database starts slowing down.

1. Fix the Indexes First

This is the single most common reason SQL Server databases slow down over time.

Either there aren't enough indexes, so the database scans entire tables for every query. Or there are too many, so every write operation — INSERT, UPDATE, DELETE — gets bogged down maintaining indexes nobody is using.

The approach that works:

Check what SQL Server is already recommending. The system tracks missing index suggestions automatically.

`sql

SELECT

mid.statement AS TableName,

mid.equality_columns,

mid.inequality_columns,

mid.included_columns,

migs.user_seeks,

migs.avg_total_user_cost

FROM sys.dm_db_missing_index_groups mig

INNER JOIN sys.dm_db_missing_index_group_stats migs

ON mig.index_group_handle = migs.group_handle

INNER JOIN sys.dm_db_missing_index_details mid

ON mig.index_handle = mid.index_handle

ORDER BY migs.avg_total_user_cost * migs.user_seeks DESC; `

Then check for unused indexes sitting there doing nothing except slowing down writes:

sql

SELECT

    OBJECT_NAME(i.object_id) AS TableName,

    i.name AS IndexName,

    ius.user_seeks,

    ius.user_scans,

    ius.user_updates

FROM sys.dm_db_index_usage_stats ius

INNER JOIN sys.indexes i

    ON ius.object_id = i.object_id AND ius.index_id = i.index_id

WHERE OBJECTPROPERTY(i.object_id, 'IsUserTable') = 1

    AND ius.user_seeks = 0

    AND ius.user_scans = 0

ORDER BY ius.user_updates DESC;

Index what gets searched. Drop what doesn't get used. Review every few months as query patterns change.

2. Read the Execution Plans

An execution plan shows exactly what SQL Server does behind the scenes when running a query. Skipping this step means troubleshooting is just guesswork.

Open SQL Server Management Studio, press Ctrl + M to enable Actual Execution Plan, and run the slow query.

Things to look for:

Table Scans — the database is reading every single row instead of jumping straight to the data it needs. Usually means a missing index.
Key Lookups — the index found the row but had to go back to the table to fetch additional columns. Fix this by adding INCLUDE columns to the index.
Fat arrows between operations — large amounts of data moving through the plan. Something upstream is pulling too much.
Warning triangles — SQL Server literally flagging that something went wrong during execution.

No amount of hardware upgrades will fix a bad query plan. Read the execution plan first, optimize second.

3. Keep Statistics Updated

SQL Server decides how to execute a query based on statistics — its internal understanding of data distribution across tables. When statistics go stale, the optimizer makes terrible decisions. A table with 10 million rows might get treated like it has 500 rows, resulting in a plan that runs 50 times slower than it should.



sql

EXEC sp_updatestats;

Run this on a schedule. Weekly for most databases. Daily for high-transaction systems.

Also, verify that Auto Update Statistics is turned on:


sql

SELECT name, is_auto_update_stats_on

FROM sys.databases;`

This setting should be ON by default, but there are production databases out there where someone turned it off years ago and nobody noticed. It happens more often than anyone would like to admit.

4. Stop Neglecting TempDB

TempDB is the shared workspace SQL Server uses for temporary operations — sorting, hash joins, temp tables, cursors, snapshot isolation version store. Every database on the instance uses a single TempDB.

When TempDB is misconfigured, the entire server suffers.

What consistently works:

Create multiple TempDB data files. One file per logical CPU core, up to 8 files. This reduces allocation contention that causes waits.
Pre-size the files. Don't leave them at the default 8MB with 64MB autogrow. Figure out the typical TempDB usage and set the initial size accordingly.
Put TempDB on the fastest available storage. If SSDs or a dedicated drive are available, that's where TempDB belongs.

This takes about 15 minutes to configure and makes a noticeable difference, especially on busy transactional systems.

5. Parameterize Every Query

Building SQL queries by concatenating strings in application code is still shockingly common.

-- This is a problem

"SELECT * FROM Orders WHERE CustomerID = " + customerId

Beyond the SQL injection risk, this destroys performance. SQL Server creates a brand new execution plan for every variation. The plan cache fills up with thousands of single-use plans. The optimizer spends more time compiling than executing.

The fix is simple. Use parameterized queries or stored procedures:

sql

SELECT OrderID, OrderDate, TotalAmount

FROM Orders

WHERE CustomerID = @CustomerID;

Same plan gets reused every time, regardless of the parameter value. Less compilation overhead. Less memory consumed. Faster response.

6. Kill the SELECT * Habit

Using SELECT * in production code means asking SQL Server to return every column from a table when the application probably needs three or four.

The cost adds up fast:

More data read from disk
More memory used for processing
More network bandwidth consumed
Indexes can't cover the query, forcing expensive lookups back to the base table

Name the columns. Only pull what's needed.

sql

-- Instead of SELECT * FROM Customers

SELECT CustomerID, FullName, Email, Phone

FROM Customers

WHERE IsActive = 1;

Small change. Big impact at scale.

7. Set Up Monitoring Before Things Break

Fixing performance problems is ten times harder without a baseline. If there's no data showing what "normal" looks like, there's nothing to compare against when things go sideways.

Key areas to monitor and the DMVs that help:

Capture this data regularly. When something breaks at 2 AM on a Saturday, having historical baselines is the difference between a quick fix and hours of firefighting.
The Takeaway

Most SQL Server performance problems come down to the same handful of issues:

→ Missing or bloated indexes

→ Stale statistics

→ Poorly written queries pulling more data than needed

→ TempDB sitting on default configuration

→ Zero monitoring until something breaks

None of this requires deep DBA expertise. It requires consistency. Set aside time every month to check database health. Treat the database like any other critical piece of infrastructure — because that's exactly what it is.

At Qodors, SQL Server performance optimization is part of ongoing work across client projects in retail, healthcare, logistics, and financial services. Sometimes the fix takes two hours. Sometimes it needs a full performance audit. Either way, the goal is the same — find the bottleneck, fix it, and make sure it doesn't come back.

Dealing with a slow database or a query that won't cooperate? The Qodors team is always open to taking a look.

— Team Qodors

🌐 www.qodors.com

SQLServer #DatabasePerformance #SQLServerOptimization #PerformanceTuning #QueryOptimization #DatabaseManagement #Qodors #SoftwareDevelopment #ITConsulting #SQLServerDBA #MicrosoftSQLServer #SQLTips #TechNewsletter #DatabaseTuning #SQLServerTips #SlowQueryFix #IndexOptimization #SQLServerMonitoring

Why AI-Generated Code Works… Until It Doesn’t (A React Reality Check)

qodors — Wed, 22 Apr 2026 13:01:47 +0000

Here’s a natural, human-style Dev.to first post aligned with your tags (ai, programming, javascript, react) and your positioning 👇

Why AI-Generated Code Works… Until It Doesn’t (A React Reality Check)

AI tools have changed how we write code.

You can now spin up a React component, generate API logic, or even scaffold an entire app in minutes. It feels like 80% of the work is done instantly.

But if you’ve tried to take that code into production, you’ve probably seen this:

It works… until it doesn’t.

The Illusion of “80% Done”

Most AI-generated code looks correct at first glance:

components render
API calls work
UI behaves as expected

But this is usually the happy path.

Real-world applications don’t run on happy paths.

They run on:

edge cases
unexpected user behavior
performance constraints
long-term maintainability

And that’s where things start breaking.

A Simple React Example

Let’s say you generate a component like this:

function UserProfile({ user }) {
  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  );
}

Looks fine, right?

Now consider:

What if user is null?
What if API is still loading?
What if data shape changes?

Suddenly, you’re dealing with runtime errors.

The Missing 20% (That Actually Matters)

From experience, the “last 20%” usually includes:

1. State & Edge Case Handling

Loading states, empty states, error boundaries.

2. Performance Optimization

Unnecessary re-renders, memoization, API caching.

3. Code Structure

Separation of concerns, reusable components, clean architecture.

4. Scalability

Can this component survive 10x more users or features?

5. Testing

Unit tests, integration tests, regression safety.

AI rarely gets these right out of the box.

Why This Happens

AI is trained on patterns, not context.

It doesn’t know:

your product goals
your future scale
your team structure
your long-term constraints

So it generates something that works now, not something that lasts.

How to Actually Use AI Effectively

AI is not the problem. Misusing it is.

Here’s a better approach:

Use AI for:

boilerplate code
initial scaffolding
quick experiments

Don’t rely on it for:

architecture decisions
production readiness
complex state management

Think of AI as a junior developer that works fast, not as a replacement for engineering thinking.

The Real Shift

We’re not moving from:

Developers → AI

We’re moving from:

Writing code → Owning systems

The value is no longer in typing code.

It’s in:

making systems stable
making them scalable
making them reliable over time

Final Thought

AI can get you to 80% faster than ever before.

But the real work — the part that users actually feel — is still in the last 20%.

And that part still needs engineers.

If you’ve worked with AI-generated code in React or JS, curious to hear your experience — did it hold up in production?