Most "what stack should I use" posts read like a tournament bracket. This isn't that. It's the answer I give clients when they ask why I keep showing up with the same two tools.
The split
The pairing is simple: Next.js for the front end, .NET (Core / 8+) for the back end. They communicate over a small REST or gRPC surface. The browser never talks to the database directly.
Why split at all? Because the things a web framework is good at and the things a service framework is good at have diverged. Next.js gets routing, hydration, image optimization, and edge rendering right out of the box. .NET gets long-lived processes, structured concurrency, EF Core, and a typing system that survives refactors a year later.
What I actually feel in production
A few things I never have to fight:
- Type safety across the boundary. I generate TS types from the .NET OpenAPI spec. When the contract changes, the front end stops compiling — not the way you find out at 2am.
- Performance baseline. A hot ASP.NET endpoint hovers around half a millisecond. I don't optimize until I have a reason.
- EF Core migrations. Schema changes are a single command, version-controlled, reviewable. I've been burned enough by ad-hoc SQL in Node projects to never go back.
The honest trade-offs
- Two languages, two toolchains. New devs joining a project pay a real onboarding cost. I keep the ceremony low — no microservices, one solution, one front-end app.
- Hosting story is more involved than "deploy to Vercel." I usually run the API on a small VM or App Service, with the front end on Vercel. It's not hard, but it's not click-once either.
- Cold starts on serverless .NET aren't great. I avoid serverless on the API side and stick to long-lived containers.
When I deviate
- Pure marketing site, no auth, no real backend? Just Next.js. .NET would be ceremony.
- Real-time-heavy (chat, presence, collaborative editing)? Node still has the ergonomics edge for sockets at small scale.
- Heavy AI/ML pipelines? Python service alongside the .NET one. .NET's ML story is fine but the ecosystem isn't where Python is yet.
TL;DR
Pick the stack you can debug at 2am with no internet. For me that's still C# on the server and TypeScript in the browser.