.NET Development: APIs, Blazor and Cloud Apps on Modern .NET

Teams usually come to us for .NET development with a clear goal: an API or web platform that is fast, strongly typed, easy to operate and built to last. There is often a constraint too, such as an existing C# team, a Microsoft-centered organization, or a .NET Framework system that the new platform must eventually replace.

Good looks like a service that starts quickly, uses resources efficiently, deploys the same way every time, and tells you what it is doing through logs, metrics and traces. Modern .NET, the open-source, cross-platform successor to the .NET Framework, does all of that well when it is used deliberately.

What we build with .NET

• High-throughput APIs for mobile apps, partner integrations and single-page front ends
• Line-of-business platforms with complex rules, such as finance, legal, healthcare and logistics workflows
• Background processing: imports, reconciliation, notifications, scheduled jobs and message consumers
• Real-time features with SignalR, such as live dashboards and in-app notifications
• Internal tools and admin portals, sometimes in Blazor
• Replacements for .NET Framework systems, a path our ASP.NET development article describes step by step

How we approach .NET development

Discovery starts with the shape of the load and the integrations: who calls the system, how often, what must be strictly consistent and what can be eventually consistent. Our business analysts capture those rules as acceptance criteria before any code exists, because in line-of-business software the rules are the product.

Design follows. By default we build a modular monolith: one deployable application with clearly separated modules and explicit contracts between them. We split into separate services only for a concrete reason, such as independent scaling, a separate team or a different release cadence. A modular monolith is cheaper to run and easier to debug, and it can be split later if the boundaries were drawn well.

In the build, the compiler does part of QA’s job: nullable reference types are enabled, warnings fail the build, and analyzers run in CI. Our QA testers own the end-to-end regression suite. Releases go through automated pipelines with health checks, and we watch traces and error rates closely after each one.

Stack and architecture choices

APIs

ASP.NET Core offers two styles. Controllers suit large APIs with shared conventions and filters; minimal APIs are lighter and now cover most needs. We pick per project and stay consistent. Much of what once required libraries is built in: OpenAPI document generation, rate limiting, output caching, health checks and standard problem-details error responses.

Data

Entity Framework Core is our default. We keep it fast with no-tracking queries for reads, projections instead of whole entities, split queries where joins multiply rows, and set-based bulk updates and deletes. For hot paths with complex SQL, Dapper sits alongside it. SQL Server and PostgreSQL are both first-class options; the choice depends on your hosting, licensing and team.

Identity and security

Accounts are handled by ASP.NET Core Identity when you manage users yourself, or by an OpenID Connect provider such as Microsoft Entra ID for staff and business customers. Secrets live in a vault, never in configuration files in the repository. Data protection keys are persisted and shared across instances, so sign-in cookies and anti-forgery tokens keep working after restarts and when the app scales out.

Background work and dependencies

Hosted services handle simple background loops. Durable scheduled jobs go to a proven scheduler such as Hangfire or Quartz.NET, and communication between services goes through a message broker with retries and dead-letter queues. We also check the license of every dependency: some popular .NET libraries, MediatR and AutoMapper among them, now require a commercial license for many business uses, and that belongs in the budget conversation.

Cloud and hosting

Modern .NET runs on Linux and in containers, so hosting is a genuine choice: Azure App Service or Container Apps, AWS, Kubernetes, or plain virtual machines. On Azure, Microsoft Entra ID, Key Vault and managed identities fit together especially well. Native ahead-of-time compilation can cut startup time and memory for small services and functions, but it rules out reflection-heavy libraries and some framework features, including MVC controllers, so we use it only where cold starts matter.

Blazor: where it fits and where it does not

Blazor lets you build interactive web UI in C#. Pages can be rendered statically on the server, made interactive on the server over a persistent SignalR connection, run in the browser on WebAssembly, or start on the server and switch to WebAssembly on later visits. Each mode has a cost:

• Interactive server keeps state on the server for every connected user and needs a stable connection. It feels instant on a good network and fragile on a poor mobile one.
• WebAssembly downloads the .NET runtime and your code before the page becomes interactive, a noticeable first-load cost for public sites.
• The ecosystem of components and experienced developers is smaller than React’s or Angular’s.

Our view: Blazor is an excellent choice for internal tools, admin panels and line-of-business apps built by a C# team, where one language across the stack pays off. For public, mobile-heavy or SEO-critical products, we usually pair a .NET API with a JavaScript front end, the approach covered in our frontend development article.

Performance and quality

.NET is fast by default, which also makes it easy to waste. The problems we fix most often are not in the runtime: blocking calls inside async code that starve the thread pool, chatty database access, missing caching, and large allocations on every request. We measure before changing anything, with OpenTelemetry traces in production, dotnet-counters and dotnet-trace for live diagnostics, and BenchmarkDotNet for the rare hot path that deserves micro-optimization.

Testing is layered. Unit tests cover domain rules. Integration tests run the real HTTP pipeline in memory against a real database started in a container with Testcontainers, so what passes in CI behaves the same way in production. Playwright end-to-end tests cover the critical user journeys, and accessibility checks for semantic markup, keyboard navigation and screen readers are part of done for any interface we ship. Security reviews focus on per-resource authorization, secrets management and vulnerable packages, which the .NET tooling flags during restore.

When .NET is the right platform, and when it is not

.NET is a strong choice when you need high throughput on modest hardware, long-lived systems with complex business rules, a C# team or hiring market, or deep integration with Microsoft identity, SQL Server, Azure and Office tooling. Microsoft ships a new release every November, and every other release gets long-term support, which gives you a predictable upgrade rhythm.

It is less compelling in a few situations. If your whole team writes TypeScript, Node.js keeps one language across front end and back end. Data science and machine learning belong in Python, even when a .NET service calls them. A marketing site or content platform is faster to deliver on a CMS. And for consumer mobile apps we usually recommend native or React Native over .NET MAUI, which fits best when a .NET team is building internal apps.

How an engagement works

For a new platform, we form a dedicated product team: a business analyst, a product designer when there is user-facing UI, .NET engineers and a QA tester, working in short iterations with a demo at the end of each. For modernization work, we start with a focused assessment and a phased plan. Either way, the code lives in your repository from day one, and you receive infrastructure defined as code, runbooks for operating the system, and regular written reports on progress, risks and decisions.

Frequently asked questions

Is .NET only for Windows and Azure?

No. Modern .NET is open source and runs on Linux, macOS and Windows, in containers and on any major cloud. Azure integration is excellent, but optional.

Should we use minimal APIs or controllers?

Either works for most projects. We lean toward controllers for large APIs with many shared conventions and minimal APIs for smaller, focused services, and we stay consistent within a codebase.

Is Blazor ready for production?

Yes, and it suits internal and line-of-business apps built by C# teams. For public-facing products, weigh its first-load and connection trade-offs against a JavaScript front end.

How often do we need to upgrade .NET?

Plan to move from one long-term support release to the next. Support windows overlap, so there is time to upgrade calmly, and staying current keeps each upgrade small.

Can you work with our in-house .NET team?

Yes. We can own a module end to end, pair with your developers, or take on a focused piece such as performance work or a migration, with shared code review and conventions.

If you are planning a .NET platform, or wondering whether .NET is the right one, tell us about your product. We will give you a straight answer and a practical first step.