I have been writing .NET code since version 1.1. That was a long time ago. In the years since, I have built campsite management platforms, HR software, property tools and countless client systems on it. At some point in every developer's career, the question comes up: should you switch? JavaScript, Python, Go, Rust. The noise from other ecosystems never goes away. Every year there is a new darling language getting breathless coverage on Hacker News. And every year I look at the options, weigh them up honestly, and conclude that .NET remains the right tool for the kind of commercial software I build. This is not sentiment. It is a considered position that I am happy to defend.
What .NET actually is in 2026
The biggest misconception I run into is people confusing modern .NET with the old .NET Framework. They are not the same thing. .NET has been open source and cross-platform since .NET Core. It runs on Linux, on containers, on ARM chips. The performance benchmarks are genuinely impressive, sitting comfortably alongside Go and well ahead of most Node.js workloads in server-side throughput.
Microsoft made some painful decisions getting here. The transition from .NET Framework to .NET Core was messy and confused a lot of people. But that work is done. What you have now is a mature, fast, actively maintained platform with a release cadence that is actually predictable. That matters when you are running commercial software in production.
The ecosystem is not a weakness
People sometimes argue that .NET's ecosystem is narrower than JavaScript or Python's. That has not been my experience. NuGet has everything I need for the kind of software I build. Entity Framework Core is a genuinely excellent ORM and I have built on it across half a dozen products. SignalR handles real-time requirements cleanly. ASP.NET is fast, well-documented and the tooling around it is superb.
The Azure integration is particularly strong, which matters because I run most things there. Managed Identity, App Services, Azure Functions, Service Bus. They all work exactly as documented with .NET, without fighting the platform. When you are running multiple products and do not have a dedicated devops team, that friction reduction adds up to real time saved.
The performance argument has real money attached to it
This one is practical rather than theoretical. The .NET runtime is efficient. For a bootstrapped SaaS product like CampSuite, compute costs are a real line on the P&L. An application that handles the same load on a smaller instance is cheaper to run every single month. Over years, that compounds.
I have seen Node.js codebases at equivalent scale requiring more horizontal scaling to handle the same traffic. Some of that is application code quality, obviously. But some of it is the runtime itself. .NET's memory management and thread handling are genuinely good, and the async story with C# is clean once you understand how it works. You do not have to fight the language to write performant server-side code.
Hiring is not the problem people claim it is
One argument I hear for moving away from .NET is hiring. The theory goes that there are more JavaScript developers than .NET developers, so it is easier to find people. In my experience this is true on the surface and misleading in practice.
Yes, there are more JavaScript developers in absolute terms. There are also considerably more poor JavaScript developers. The .NET talent pool in the UK is deep and experienced. When I have hired for my own products or helped clients build teams, finding solid C# developers has not been the blocker. Finding solid developers of any kind is hard. The language is rarely the constraint.
Beyond that, if you are the kind of technical founder who is hands-on in the codebase, you are picking a stack you will live in every day. Picking a stack purely for perceived hiring advantages while neglecting your own productivity is a trade-off that often goes wrong. I am faster in C# than I would be in most other languages at this point. That matters.
Where I would actually consider something else
I try to be honest about this rather than reflexively defensive. There are cases where I would reach for something other than .NET.
For data science or machine learning work, Python is the obvious answer. The ecosystem there is unmatched and trying to do ML in .NET is swimming upstream. For very lightweight serverless functions where cold start time is critical, there are arguments for other runtimes depending on the specific constraints. And for frontend development, I use JavaScript like everyone else, because the browser does not care about my preferences.
But for building the core of a commercial web application? An API backend? A background processing service? .NET every time. The alternative stacks I have spent serious time with have not offered enough to justify the disruption of switching, and I have looked at this question genuinely rather than out of laziness.
The deeper reason
There is something beyond the technical argument. When you have spent years building expertise in a platform, that expertise has real value. I know where .NET's edges are. I know the gotchas, the performance traps, the bits where the documentation is misleading. That accumulated knowledge makes me faster and less likely to make expensive mistakes.
There is a churn cost to switching that the tech conference talks do not mention. You do not just learn a new language. You learn a new ecosystem, new tooling, new deployment patterns, new ways of debugging, new community conventions. That takes time. Time is the one resource you cannot get back in a bootstrapped business.
If you are thinking through your own tech stack decisions for a SaaS product, the honest answer is that the stack matters less than the people using it. But if you are asking me specifically, and you have a commercial software product to build, .NET is a bloody good choice in 2026. Do not let the noise convince you otherwise.
