.NET and C# development
The strongest case for .NET is longevity. A line-of-business system that has to work in twelve years benefits from a platform with a published support calendar and a company committed to it — which is a different criterion from whichever framework is interesting this quarter.
Discuss your projectWhen we reach for it
- Estates already committed to Microsoft — Active Directory, SQL Server, Azure, Dynamics
- Long-lived line-of-business systems where a twenty-year support story matters more than novelty
- Systems with heavy computation, where a compiled runtime and real threads are a genuine advantage
- Organisations whose existing developers are C# developers
When we don’t
- Small products where a single-language TypeScript stack means one engineer can own the whole feature
- Teams with no existing .NET capability and no plan to hire for it
- Rapid, iterative consumer product work where the surrounding ecosystem is overwhelmingly JavaScript
This half is the useful one. A firm that has never declined to use a technology has never chosen one.
What we have learned about the parts of .NET that bite — written from projects rather than from documentation.
What the platform is genuinely good at
Type safety that is actually enforced at runtime rather than erased at build time, real multithreading without a separate worker process, and a first-party answer for most things — dependency injection, configuration, logging, background services, authentication — so a codebase does not become an assembly of eleven competing community choices.
Entity Framework Core is a capable ORM with genuinely good migration tooling, and the tooling story generally is the platform’s quiet advantage: the debugger, the profiler and the analysers are excellent, and they are the same on every project.
Where we see it go wrong
Layered architecture applied by ritual. A repository wrapping an ORM that is already a repository, a service layer that only forwards calls, a mapping layer between three shapes of the same object — each layer defended on principle and none earning its cost. The result is a codebase where adding a field touches seven files.
The other frequent problem is a heavily stateful application that assumes it is the only instance, which makes horizontal scaling impossible without a rewrite of the session and caching layers.
Modern .NET, not legacy .NET
Current .NET is cross-platform, runs well in Linux containers, and has none of the deployment constraints people remember from the Framework era. If your image of .NET is an IIS server somebody has to remote into, that image is a decade out of date.
We also take on Framework-era systems that need to keep running while being modernised — a strangler migration behind a routing layer, replacing one area at a time, rather than a big-bang port that has to reach parity with undocumented behaviour before it can go live.
.NET and C#, applied
The shapes of system this technology is actually good at, rather than the ones it is capable of.
Usually alongside
- C#
- ASP.NET Core
- Entity Framework Core
- SQL Server
- PostgreSQL
- Azure
- xUnit
- Docker
- Line-of-business systems with long expected lifespans
- ASP.NET Core web APIs and server-rendered applications
- Integrations with Dynamics, SQL Server and Active Directory
- Background and scheduled processing services
- Modernisation of .NET Framework systems, in place
.NET, answered
Is .NET a good choice for new projects in 2026?
For the right shape of project, yes. Current .NET is cross-platform, containers well, performs strongly, and has a published support calendar — which genuinely matters for a system expected to run for a decade. It is a poor fit for a small product where a single-language TypeScript stack lets one engineer own a feature end to end, and for teams with no C# capability and no intention of hiring any. The platform is not the deciding factor; the estate and the team usually are.
Can you modernise our .NET Framework application?
Yes, and almost always incrementally rather than as a port. The pattern is a routing layer in front of the existing application, with functionality moved across one area at a time while the old system keeps serving everything else. A big-bang port has to reach parity with behaviour that was never fully documented before it can replace anything, which is why so many of them stall. We start with an assessment of what is load-bearing and what can be retired outright — there is usually more of the latter than expected.
Do we need SQL Server, or can we use PostgreSQL?
PostgreSQL works well with .NET and Entity Framework Core, and it removes a licensing cost that is not trivial at scale. Stay on SQL Server where you depend on something specific to it — existing stored procedures representing real business logic, SSRS reporting, or Always On configuration your operations team already runs. If you are starting fresh with no such dependency, PostgreSQL is usually the more economical answer and we would say so.
Where this shows up
- BuildCustom Software DevelopmentCustom platforms, marketplaces and SaaS. We write the parts that are specific to your business and buy the parts that aren’t.Read more
- RunMaintenance & SupportTaking over a system someone else wrote — including the archaeology needed before anyone can safely change it.Read more
- RunCloud & DevOpsDeploys that are boring on purpose. Infrastructure as code, real environments, and a bill you can read line by line.Read more
Building with .NET?
Whether it is a new build, a takeover or a second opinion on an architecture someone else chose — the first conversation is free and we will tell you if the stack is wrong for the job.