AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms10 business days
To start a C#/.NET engagement
Scoping through first sprint
100%
Senior engineers, US-based
No offshore handoff
Every sprint
Working software on a preview URL
Not a status deck between milestones
100%
Code and infrastructure you own
From the first commit
Where C#/.NET fits
What a C#/.NET engagement is actually building
C#/.NET's versatility is real — sales, finance, supply chain, and internal line-of-business apps all run on it comfortably — and it looks different depending on which corner of the platform a project actually needs.
Enterprise web APIs and applications
ASP.NET Core is the current default: a fast, cross-platform web framework with dependency injection and configuration built in from the start, rather than bolted on the way older frameworks required.
Internal business systems
Sales, finance, accounting, and supply-chain tooling remain a core C#/.NET use case, largely because the platform's strong typing and mature tooling suit line-of-business logic that has to stay correct as it grows, and because most enterprises already run other Microsoft infrastructure it integrates cleanly with.
Windows desktop applications
WPF and, increasingly, .NET MAUI remain the standard choice for a genuine Windows desktop application — and MAUI extends that same C# codebase to macOS, iOS, and Android when a project needs one codebase across platforms rather than separate native apps.
Blazor for C# in the browser
Blazor lets a team write interactive web UI in C# instead of JavaScript, running either server-side or compiled to WebAssembly in the browser. It's a genuine option for a team that's strong in C# and would rather not maintain a second frontend stack, not a gimmick.
Cloud-native and microservices
Current .NET runs natively on Linux containers, not just Windows, which makes it a real option for containerized, cloud-native architectures on any major cloud — a meaningful shift from the Windows-only .NET Framework era.
Game development
C# is the primary scripting language for Unity, one of the two dominant game engines — a use case that has little to do with the enterprise-backend reputation the language otherwise carries.
Decisions that matter
The platform and architecture decisions that decide whether a C#/.NET project goes smoothly
Most of the risk in a C#/.NET project traces back to one distinction buyers often don't know to ask about: which .NET they're actually building on, or migrating from.
.NET Framework vs. current .NET — not the same platform
.NET Framework (versions up to 4.8) is Windows-only, closed development, and effectively in maintenance mode. Current .NET (5 and later, including the yearly releases and LTS versions like 8 and 10) is cross-platform, open source, and where all active development happens. Any project described as ".NET" without specifying which one is missing the single most important fact about its scope.
ASP.NET Core as the default web framework
ASP.NET Core replaced the older ASP.NET MVC and Web API frameworks with a unified, faster, cross-platform framework built around dependency injection from the ground up. New C# web work should default here; the older frameworks are legacy-maintenance territory now, not a starting point.
Native async/await, done correctly
C# had first-class async/await support years before most competing ecosystems, and it remains one of the language's real strengths — cleaner to read and reason about than callback- or promise-based alternatives. The common mistake is mixing synchronous and asynchronous code carelessly, which produces deadlocks that are genuinely hard to diagnose after the fact.
Entity Framework Core, and when to bypass it
EF Core is the standard ORM and handles the large majority of data access cleanly. For queries under real performance pressure, dropping to Dapper or hand-written SQL for that specific path is a normal, well-supported pattern — not a sign EF Core was the wrong choice for everything else.
Deployment target: Windows Server, Linux, or cloud-native
Current .NET runs equally well on Windows Server, Linux containers, or as a cloud-native service on Azure, AWS, or GCP. Deciding this early affects hosting, CI/CD, and whether a team can standardize on the same container tooling it already uses for everything else.
Nullable reference types and modern C#
Recent C# versions default to nullable reference type checking, catching a large class of null-reference bugs at compile time rather than in production. A codebase still on an older language version, or with nullable checking disabled, is giving up a meaningful safety net for no real benefit.
What's involved
C#/.NET engagement types
The scope question that matters most here is whether the work is new development on current .NET or a migration off legacy .NET Framework — the second category is where timelines actually vary.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| Framework migration assessment | Fixed scope | 1 – 3 weeks | An inventory of what's actually in a .NET Framework codebase — WebForms, WCF, Windows-only APIs — and a realistic migration plan. |
| New ASP.NET Core API or app | Fixed scope | 6 – 12 weeks | A web API or application built on current .NET and ASP.NET Core, including data access, authentication, and tests. |
| .NET Framework → current .NET migration | Fixed scope | 8 – 20 weeks | Moving an existing application to current, cross-platform .NET, including replacing Framework-only pieces that have no direct equivalent. |
| Blazor or MAUI frontend | Fixed scope | 6 – 14 weeks | A browser or cross-platform client built in C#, integrated with an existing or new ASP.NET Core backend. |
| Dedicated .NET engineer | Staff augmentation | Ongoing | A senior C#/.NET engineer embedded in your existing team and codebase, working your sprint cadence. |
Ranges assume US-based senior engineers. The assessment is the fastest way to find out whether a Framework migration is mostly mechanical or genuinely blocked on a component — WebForms or WCF server hosting, most often — that has no direct current-.NET equivalent.
Right tool, wrong tool
When C#/.NET is the right call — and when it isn't
C#/.NET's strengths are real for the systems it was built for, and it's not the automatic answer just because a company already runs other Microsoft infrastructure.
Right call: Microsoft-stack enterprises
A team already running SQL Server, Azure AD, and Microsoft 365 gets real integration value from building on .NET — identity, data access, and deployment tooling all connect more directly than mixing in an unrelated stack for no strategic reason.
Right call: strongly typed business logic at scale
C#'s type system, combined with mature tooling for testing and static analysis, suits complex business rules that need to stay correct as a codebase and a team both grow — the same case Java makes, from a different vendor.
Wrong call: greenfield builds with no Microsoft-stack reason
If a team has no existing Microsoft infrastructure and no specific reason to introduce one, defaulting to .NET rather than an ecosystem the team already knows adds licensing and tooling overhead without a corresponding benefit — the platform itself is open source and free to use, but supporting tooling and any Windows Server hosting decisions are real costs worth weighing honestly.
Wrong call: quick scripts and prototypes
C#'s compile step and project structure are real overhead for a fast, disposable prototype — a scripting language gets there with far less ceremony when the artifact itself is throwaway.
Depends: mobile development
.NET MAUI is a legitimate cross-platform option for a team already strong in C#, sharing logic across iOS, Android, and desktop. A team with no existing C# investment usually gets more mileage from native Swift/Kotlin or React Native, where the hiring pool and library ecosystem are both larger.
Depends: which .NET, if it's a migration
Carrying a Framework application forward is a very different project depending on what's in it. An app built on ASP.NET MVC or Web API with standard libraries migrates in weeks. One built on WebForms or hosting WCF services — both without a direct current-.NET equivalent — is a genuine re-architecture, and pretending otherwise is how a migration estimate goes wrong.
Migration and integration
Where a C#/.NET engagement is really a Framework migration
A meaningful share of C#/.NET work is moving an existing system off .NET Framework rather than building something new.
WebForms has no direct successor
WebForms, the page-and-postback model from the early .NET Framework era, has no equivalent in current .NET — there's no drop-in replacement, only a rewrite of the UI layer against ASP.NET Core or Blazor. Any WebForms application in a migration scope should be budgeted as a rebuild of that layer, not a port.
WCF services need a new home
Server-side WCF isn't supported on current .NET. The common paths forward are re-implementing the service as a gRPC service or an ASP.NET Core Web API — both are well-trodden, but neither is a mechanical port, and the choice between them depends on who's consuming the service.
Third-party and Windows-only dependencies
Libraries built specifically against .NET Framework, or against Windows-only APIs, are the other common blocker. Some have current-.NET-compatible versions; others need to be replaced entirely, which is exactly the kind of detail an assessment surfaces before a migration timeline gets promised to anyone.
Incremental migration is usually the honest path
A large Framework application rarely needs to move in one cutover. Running current .NET services alongside a Framework application during a transition, migrating piece by piece, is standard practice and lowers the risk of a single large release that has to work perfectly on the first try.
Hiring a C#/.NET developer
What actually matters when you're hiring
"Years of .NET experience" doesn't tell you whether a candidate has worked on the current platform or spent a decade exclusively on legacy Framework — and those are genuinely different skill sets now.
Current .NET fluency, specifically
Ask directly whether recent experience is on .NET Framework or current, cross-platform .NET. A developer who's strong on Framework but has never shipped on ASP.NET Core is a real gap for new development, even with many years of C# behind them.
Async/await correctness
Ask about a deadlock they've debugged from mixed sync/async code — it's one of the more common real bugs in production C#, and a developer who can explain how it happens understands the model well enough not to reintroduce it.
EF Core judgment, not just usage
Knowing when a query needs to bypass EF Core for raw SQL or Dapper, rather than forcing every data-access pattern through the ORM regardless of cost, is a stronger signal than general EF familiarity.
Comfort outside Windows, if the deployment target needs it
If the plan is Linux containers or cloud-native deployment, confirm the candidate has actually shipped that way — some long-tenured .NET developers have spent their whole career on Windows Server and IIS and haven't made that shift yet.
Related
Related services
What C#/.NET builds usually connect to.
Questions
Common questions about C#/.NET development
What teams ask before a first call.
.NET Framework is the original platform from the 2000s — Windows-only, closed development, and effectively in maintenance mode with no new features coming. Current .NET (5 and later, including LTS releases like 8 and 10) is the actively developed, open-source, cross-platform successor that runs on Windows, Linux, and macOS.
They share the C# language but are different runtimes with different capabilities, and moving an application between them is a migration project, not a version bump — which is the single fact most buyers researching this need to know before scoping anything.
It depends most on whether the work is new development on current .NET or a migration off legacy .NET Framework — the migration category varies widely depending on whether the app uses WebForms or WCF, both of which need real re-architecture rather than a mechanical port.
A scoping conversation, backed by a short codebase assessment for any migration, gets you an accurate number faster than a generic range would.
Yes, and it's one of the more common requests we get on this stack. The honest first step is an assessment of what's actually in the codebase — WebForms and WCF are the two components without a direct current-.NET equivalent, and they're what actually sets the timeline, not the line count of the rest of the application.
It can be — current .NET is open source, cross-platform, and free to build on regardless of your existing stack, and it's a genuinely strong platform on its own merits. That said, if your team has no Microsoft-stack investment and no specific reason to introduce one, an ecosystem your team already knows is usually the lower-friction default. We'll tell you honestly which situation you're in.
Blazor lets you write interactive web UI in C# instead of JavaScript, running either on the server or compiled to WebAssembly in the browser. It's a legitimate option for a team that's strong in C# and would rather not maintain a separate JavaScript stack — genuinely production-ready today, not an experimental feature.
MAUI is worth considering when your team already has strong C# skills and wants to share logic across iOS, Android, and desktop from one codebase. Teams without existing C# investment usually get a larger hiring pool and library ecosystem from native Swift/Kotlin or React Native — the right answer depends on your team's background more than a technical ranking of the frameworks.
Mostly extending and maintaining existing systems: adding features to an ASP.NET Core service, fixing a defect in business logic, writing the tests that keep a growing codebase safe to change, and — on a migration engagement — verifying which parts of a Framework application carry forward cleanly and which need to be rebuilt against current .NET.
You do. Source code lives in a repository under your organization from the first commit, and any cloud infrastructure runs in your own account. That's the arrangement that keeps a Microsoft-stack system portable to a different team or vendor later, rather than locked to whoever built it.