Service · ASP.NET Core · Azure

.NET Development

Brisbane-based .NET specialists building and modernising C#, ASP.NET Core, Blazor and Azure applications for Australian businesses. Especially good at the unfashionable work — turning a 12-year-old WebForms app into something a new graduate can work on without screaming.

What we do in the .NET ecosystem

  • ASP.NET Core API + Web app builds for new SaaS and internal tooling
  • Blazor Server and WebAssembly when the brief is .NET-only
  • Azure architecture for .NET workloads — App Service, Functions, AKS, Service Bus, SQL
  • Modernisation from .NET Framework 4.x / WebForms / WCF to ASP.NET Core 8/9
  • Performance work — Entity Framework tuning, async patterns, caching strategies
  • Integration with Microsoft 365, Dynamics 365, Power Platform APIs
  • Microservices and event-driven systems on Service Bus, Event Grid, Event Hubs

The .NET Framework migration question

If you're still running .NET Framework 4.x in 2026, you're not alone — a large slice of Australian mid-market businesses still are. Microsoft has committed to indefinite support for 4.8, so technically nothing forces you to migrate. But you'll face increasing friction: new package versions stop supporting it, hiring becomes harder, and Microsoft's investment now goes entirely into modern .NET.

We use the YARP reverse-proxy strangler-fig pattern: stand up a new .NET 9 app alongside the legacy one, route specific URLs to the new app, migrate features one at a time. Old and new run in production together for months. Risk is contained per feature; rollback is a routing change.

How we approach .NET architecture

Vertical slice architecture, not Clean/Onion

For most SMB-scale apps we build, the layered Clean/Onion architecture adds ceremony without benefit. We default to vertical-slice (feature-folder) architecture with MediatR or minimal APIs — easier to onboard new developers, less code per feature, simpler to reason about.

EF Core by default, Dapper when measured

Entity Framework Core is fast enough for almost all SMB workloads we see. We use Dapper or raw SQL only when we measure an actual bottleneck — never preemptively.

Azure-first hosting

App Service for most workloads, Functions for event handlers, AKS only when we have a specific reason (multiple services that actually need orchestration, or complex networking). All data residency pinned to Australian regions.

Explore more

.NET development FAQ

Usually yes, and rarely as a big-bang. .NET Framework 4.8 is the last version Microsoft will support indefinitely, and it's a maintenance dead-end — no new features, declining hiring pool. Modern .NET (9, formerly Core) gives you cross-platform hosting, much better performance, ASP.NET Core's vastly cleaner API, and active language evolution. The right migration path is incremental: stand up a parallel .NET 9 app, migrate features one at a time using a reverse-proxy strangler-fig pattern. Typical scope: AU$60,000–$250,000 depending on app size.
Blazor (Server or WebAssembly) is the right call when your team is .NET-only and you want to avoid the JS ecosystem entirely. The trade-off: smaller talent pool, less mature tooling, more complex hosting for WebAssembly. React/Next.js with a .NET API is the right call for most public-facing or high-interaction apps — broader talent pool, mature ecosystem, lighter client payloads. We default to React + .NET API for new projects unless there's a specific reason to choose Blazor.
Yes — about half our .NET engagements are augmenting an existing in-house team. We typically take on the harder architectural work (event-driven design, Azure architecture, performance optimisation, complex integrations) while the in-house team handles feature work. We document everything we touch and run knowledge-transfer sessions.
EF Core is the default for most modern .NET projects and we use it heavily. The exception: very high-throughput data layers (>5k requests/sec) or complex reporting where Dapper or raw SQL gives much better control over query plans. Realistically, almost no Australian SMB workload pushes EF Core past its limits — we recommend EF Core for new projects unless we measure a real bottleneck.
Azure is the natural default for .NET — App Service, Azure SQL, and the Azure DevOps tooling are tightly integrated. AWS is fine too if you're already there (Elastic Beanstalk for App Service-equivalent, RDS for SQL Server). On-prem still makes sense for some compliance scenarios but is harder to justify financially below ~50 servers. We pin all data residency to AU regions by default.
Modernisation of legacy .NET Framework / WebForms / WCF to ASP.NET Core. New builds in ASP.NET Core, Blazor, or .NET API + React. Azure architecture for .NET workloads (App Service, Functions, AKS, Service Bus, SQL). Performance optimisation and re-platforming. Integration work with the wider Microsoft ecosystem (Dynamics, Power Platform, Microsoft 365 APIs). We don't take on Windows desktop client (WPF/WinForms) work unless it's part of a migration project.

Get a .NET architecture review

Book a free 30-minute call. We'll discuss your .NET stack, the modernisation pressure points, and the realistic next move.

Book a Free 30-Min Discovery CallSee Pricing