.NET is Microsoft's application platform, using C#. It is genuinely fast, strongly typed and has long-term support dates published years in advance. We use it where a client already runs Microsoft infrastructure, or where procurement requires a platform with a named vendor behind it.
What is .NET?
.NET is a runtime, a language (C#) and a large standard library, maintained by Microsoft and open source since 2016. Modern .NET runs on Linux as happily as on Windows, which surprises people whose impression of it was formed a decade ago.
Its distinguishing properties are performance and predictability. It is one of the fastest mainstream server platforms in real benchmarks, and Microsoft publishes support end dates years ahead, so a CTO can plan an upgrade window instead of discovering one.
The type system is stricter than TypeScript's and enforced at runtime as well as at compile time, which suits systems where a wrong value is a financial or regulatory problem rather than a cosmetic one.
When we choose .NET
When the client is a Microsoft organisation. If the identity system is Entra ID, the reporting is Power BI and the servers are Azure, a .NET application fits into that without an integration layer, and the internal team can maintain it.
When procurement demands a platform with a corporate vendor and a published support schedule. Government and banking work in this region frequently specifies exactly that, and it is not a technical argument to win — it is a requirement to meet.
And for genuinely computation-heavy backends where raw throughput matters and Node would block.
It is also the path of least resistance when procurement has already specified a Microsoft stack, which in government-adjacent work in this region happens often. Arguing the platform choice on a tender that has already been written costs more than it saves.
When we do not use .NET
For content-managed marketing sites. .NET can do it, but hosting costs more, the CMS options are weaker than the PHP world's, and a marketing team gets a better editing experience elsewhere.
For a small business on shared hosting, where .NET is effectively not an option.
And for a startup optimising for speed of change. The rigour that protects a bank slows down a team that needs to rewrite its assumptions every quarter.
What we build with .NET
Logistics and operations backends
High-throughput systems processing consignments, routes and events continuously. We built Meridian Freight's backend on .NET with PostGIS for the geospatial work — 300+ live consignments with position history that has to stay accurate.
Integrations with Microsoft systems
Single sign-on through Entra ID, data flowing into Power BI, documents in SharePoint. When the organisation already runs on these, .NET removes the adapter layer entirely rather than making it someone's job.
Line-of-business applications
Approval workflows, asset registers, compliance tracking — the systems an enterprise runs on internally, integrated with the identity and reporting stack the organisation already has.
APIs in front of existing Microsoft systems
A modern API layer over SQL Server or an older internal system, so a new web or mobile front end can be built without touching the system of record.
How we ship .NET projects
On an LTS release, containerised, deployed to Linux unless there is a specific reason for Windows — it is cheaper to run and the platform is fully supported there.
Structured logging and health endpoints from the first sprint. On the systems .NET is chosen for, knowing something is degrading before a user reports it is most of the operational value.
What .NET costs you
Hosting is more expensive than PHP and the developer pool in the GCC is smaller than for JavaScript or PHP, which affects both cost and how quickly a role can be filled.
The ecosystem also assumes an enterprise context. Libraries tend to be thorough and heavy rather than small and quick, which is right for a bank and heavy for a fifteen-screen internal tool.
Development is generally slower than Laravel or Node for equivalent web work — more ceremony, more configuration, more code for the same feature. That cost is repaid on a large, long-lived system and is simply a cost on a small one.
The local talent pool is also concentrated in enterprise and government work rather than agencies, which affects both what you pay and how quickly you can add someone.
.NET questions we get asked
No. Modern .NET runs on Linux and in containers, and that is how we deploy it unless a client specifically needs Windows. Linux hosting is cheaper and the platform is fully supported there.
For internal systems that integrate with Entra ID, SharePoint or SQL Server, it is usually the shortest path. For a public marketing website, it is not — a Laravel or Next.js site will be cheaper to host and faster to launch, and nothing is lost by mixing.
The runtime is free and cross-platform now, and it runs on Linux perfectly well. The cost is elsewhere: hosting is not shared-hosting cheap, and SQL Server licensing adds up if the design assumes it — which it does not have to.
Yes, and that is the more common arrangement. We typically build the public-facing or customer-facing part while the internal team owns the core systems, with a documented API contract between the two so neither side blocks the other.
Yes, and they usually do now. Modern .NET is cross-platform, runs well in containers and does not require Windows Server or its licensing. If a proposal assumes Windows hosting because the application is .NET, that assumption is a decade out of date and worth challenging before it reaches the budget.
Web applications start at $15,000 and typically run twelve to twenty weeks. Enterprise .NET work sits at the higher end of that, mostly because integration with existing internal systems is where the time goes rather than the application itself. We scope the integrations explicitly before quoting so the number holds.
