Architecture Dilemma: Fullstack Next.js (App Router) vs .NET Backend for a new AI oriented SaaS?
Unanswered
Hooded Warbler posted this in #help-forum
Hooded WarblerOP
Hi community, We are a small team starting a greenfield SaaS project (Fintech/Invoicing agent). We need high velocity and fast iterations.
The Context:
Goal: Build an AI-first app (OCR, Streaming UI, Agents) quickly.
Team: Small team (2-3 devs).
The Conflict: My lead developer is a Senior in .NET (C#) and prefers a separate Backend API. I am leaning towards Fullstack Next.js (App Router + Server Actions + Prisma) to move faster.
The Question: Is it worth splitting the stack into Next.js Frontend + .NET Backend in 2026?
My concerns with the .NET route:
1. Losing Server Actions: We'd have to write manual API endpoints instead of direct calls.
2. Type Safety: We lose the end-to-end type safety that Prisma/TS offers (unless we use code generators).
3. AI Integration: We want to use Vercel AI SDK for streaming and generative UI. Does this play well with a C# backend, or will we fight with streaming/SSE implementation ?
Has anyone here built an AI app with a .NET backend? Did you regret not going fullstack TS/Node?
Thanks for any insights!
The Context:
Goal: Build an AI-first app (OCR, Streaming UI, Agents) quickly.
Team: Small team (2-3 devs).
The Conflict: My lead developer is a Senior in .NET (C#) and prefers a separate Backend API. I am leaning towards Fullstack Next.js (App Router + Server Actions + Prisma) to move faster.
The Question: Is it worth splitting the stack into Next.js Frontend + .NET Backend in 2026?
My concerns with the .NET route:
1. Losing Server Actions: We'd have to write manual API endpoints instead of direct calls.
2. Type Safety: We lose the end-to-end type safety that Prisma/TS offers (unless we use code generators).
3. AI Integration: We want to use Vercel AI SDK for streaming and generative UI. Does this play well with a C# backend, or will we fight with streaming/SSE implementation ?
Has anyone here built an AI app with a .NET backend? Did you regret not going fullstack TS/Node?
Thanks for any insights!
17 Replies
It’s not worth it
There is zero reason to use dot net
Based on what you describe above
It’s so easy to with a full stack nextjs app. The whole ecosystem is built around it
How do you plan on deploying and maintaining and monitoring your dot net backend?
@linesofcode There is zero reason to use dot net
Saint Hubert Jura Hound
Except for that the lead dev uses .net...
@Hooded Warbler Hi community, We are a small team starting a greenfield SaaS project (Fintech/Invoicing agent). We need high velocity and fast iterations.
The Context:
Goal: Build an AI-first app (OCR, Streaming UI, Agents) quickly.
Team: Small team (2-3 devs).
The Conflict: My lead developer is a Senior in .NET (C#) and prefers a separate Backend API. I am leaning towards Fullstack Next.js (App Router + Server Actions + Prisma) to move faster.
The Question: Is it worth splitting the stack into Next.js Frontend + .NET Backend in 2026?
My concerns with the .NET route:
1. Losing Server Actions: We'd have to write manual API endpoints instead of direct calls.
2. Type Safety: We lose the end-to-end type safety that Prisma/TS offers (unless we use code generators).
3. AI Integration: We want to use Vercel AI SDK for streaming and generative UI. Does this play well with a C# backend, or will we fight with streaming/SSE implementation ?
Has anyone here built an AI app with a .NET backend? Did you regret not going fullstack TS/Node?
Thanks for any insights!
Saint Hubert Jura Hound
U also wouldnt lose out on server actions. U can still use them wherever u like and just call ur .net backend from them if u need to
Type safety is again also not available for nextjs api routes. Only server actions
So youd still have to use codegen or some type of rpc client (which i recommend anyway)
As for sse/streaming, that should work fine on nextjs api routes. But still i would go w a .net backend. Even if just bc ur lead dev is more accustomed to that lang
Something to keep in mind is obviously the increase in deployment complexity. But if u or someone on the team has some devops knowledge, 2 apps shouldnt be too hard
Egyptian Mau
I would also go with fullstack Next.js. Why split the codebase into two completely different tech stacks with different deployments, when there is no technical reason for it?
your lead should have recognized this right away btw instead of pushing for c#, what they prefer to use is not relavant, especially past a certain experience level - what matters is the best tools to solve your problem
Saint Hubert Jura Hound
If u want fast development and iterations, why make someone in ur team whos never used js learn not only js, but react and and nextjs too, potentially even ts. Do you think that even with experience, someone is gonna learn all of that and actually become proficient at it in a short amount of time?
Mby im biased bc i like devops but to me, setting up ci/cd for 2 different projects is much faster than having someone learn 4 new tools, and i dont really see any other negatives besides the deployment complexity. In fact i see more benefits of using c# in the long run.
You say what matters is the best tools to solve a problem but what makes c# worse than nextjs as backend?
Mby im biased bc i like devops but to me, setting up ci/cd for 2 different projects is much faster than having someone learn 4 new tools, and i dont really see any other negatives besides the deployment complexity. In fact i see more benefits of using c# in the long run.
You say what matters is the best tools to solve a problem but what makes c# worse than nextjs as backend?
Egyptian Mau
How can you be a Senior dev without experience in JS? Everybody has experience in JS.
I mean everybody who would be considered to implement a web app, of course embedded devs or linux native devs etc. don't necessarily need experience in JS
Today everyone is polyglots (or they better become one soon).