.NET and React for enterprise software: team and pitfalls

A .NET backend with a React frontend is a good fit for enterprise software. C# and ASP.NET Core give you a typed, mature backend with a predictable release cycle, and React developers are easy to find. The risks sit mostly where the two meet: types that drift apart, two builds that go live separately, and a team that splits into a backend camp and a frontend camp.

What .NET does well in the backend

Enterprise software has many business rules and integrations with other systems, and it stays in production for years. C# suits that: strong types, good tooling and a framework that ships with authentication, authorisation, dependency injection and logging. ASP.NET Core is open source and cross-platform, so it runs fine in Linux containers.

Microsoft ships a new .NET version every November. LTS releases such as .NET 8 and .NET 10 get three years of support. Since .NET 9, STS releases get two years instead of eighteen months. That makes upgrades predictable, provided you schedule them.

For .NET 8 and .NET 9 that is now urgent, because they receive no security updates after 10 November 2026. If any of your services still run on them, put the move to .NET 10 on this sprint's board. .NET 10 is supported until November 2028.

What React does in the frontend

Internal applications behind a login rarely need server rendering. A React app built with Vite and TypeScript that calls the API is the simplest thing to build and host. If you also have public pages that need to rank in search engines, Next.js is the better choice for that part.

Keep the frontend thin where you can. Validation and permissions belong in the backend; the frontend shows what the API returns and sends what the user enters. That way you test business rules in one place.

The team profile

My advice is not to create a separate backend team and frontend team. Features get stuck at the boundary while one group waits for the other. Let one developer build a feature from API to screen, and make sure the team as a whole covers both sides well.

For a team of four or five developers I would look for:

• C# developers who are comfortable with React and TypeScript;
• at least one developer who is strong on the frontend, for the component library, accessibility and performance;
• someone who knows the database and Entity Framework Core inside out.

In screening I would ask C# developers about async/await, about the SQL that Entity Framework produces from their LINQ query, and how they spot an N+1 problem. Frontend candidates get questions on state, forms and TypeScript types. What such a team costs is on the page about building a remote team.

Pitfalls where backend and frontend meet

The best-known pitfall is maintaining types twice. C# DTOs and TypeScript interfaces that someone copies by hand drift apart within months. ASP.NET Core can generate an OpenAPI document itself through the Microsoft.AspNetCore.OpenApi package, and at build time with Microsoft.Extensions.ApiDescription.Server. Turn that into TypeScript types or a full client in CI, and fail the build when the generated file differs from what is committed.

Frontend and backend also tend to go live through two pipelines. A frontend that expects an API version that is not deployed yet produces errors that are hard to trace. Build and test both in one pipeline. Or serve the built React app as static files from the API, so they always ship together.

If the React app runs on the same domain as the API, use httpOnly cookies for login rather than tokens in localStorage. The backend owns the session and the frontend only gets what it needs.

The last risk is Entity Framework without supervision. EF Core makes it easy to run an extra query for every row in a list without noticing. Log the SQL that EF Core generates in development and look at it during code review.

Infrastructure and cost

ASP.NET Core runs in a Linux container, so you can host on Azure, on another cloud or on your own servers. SQL Server is the usual database in a Microsoft shop. For a new project I would also consider Postgres, which Entity Framework Core supports through the Npgsql provider. Include SQL Server licence costs in that decision. Why I start new projects on Postgres is covered in Postgres as the default database.

We build with this stack ourselves. For Nannies at Night we built a platform with a .NET backend, a React frontend and Postgres, bringing matching, planning and payments into one system.

When another stack fits better

A small team that only writes TypeScript and builds a web product moves faster with one language on both sides. If you have an existing .NET Framework application, the first step is a migration plan, not a new frontend. Start with the parts that change most often and leave the rest alone for now.

Sources

• .NET Blog: .NET 8 and .NET 9 end of support
• Microsoft Learn: Overview of ASP.NET Core
• Microsoft Learn: Overview of OpenAPI support in ASP.NET Core API apps
• Microsoft Learn: EF Core database providers