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!
11 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