The SaaS Stack I'd Use for LLM-Assisted Product Development

Part 1 of 2. Part 2: The Go and gRPC Version of the SaaS Stack.

A good SaaS stack is not a mood board of tools.

It is a feedback loop.

Can you describe the product clearly, build a thin slice, deploy it, charge for it, observe what users do, debug failures, and keep the codebase legible while AI assistants are helping you move faster than your review discipline wants to move?

That is the frame I use now. The stack should reduce the number of decisions between "I think this is useful" and "a user did something real with it." It should also keep the boundaries typed enough that an LLM can help without inventing half the architecture.

My default stack for an early SaaS product is boring on purpose:

• FastAPI for the backend.
• Next.js when the app needs routing, server rendering, and deployment conventions, or Vite when I want a smaller client app.
• Supabase for Postgres, authentication, storage-adjacent product data, realtime when it is actually needed, and pgvector before I rent a separate vector database.
• Pure Python plus Pydantic for AI application code until the workflow needs a graph.
• LangGraph for agent control flow when durable state, interrupts, retries, or human review become real requirements.
• LangSmith, OpenTelemetry, and product analytics for traces, metrics, and behavior.
• Stripe for payments.
• PostHog for product analytics.
• VS Code plus GitHub Copilot as the daily coding surface.

I would not sell this as the only serious stack. It is the stack I would pick when the product is still searching for its shape and the team needs speed without accepting chaos as the cost of speed.

A Concrete Scenario#

Imagine a small team building a customer-facing workflow product.

The first version needs login, a dashboard, a few CRUD surfaces, a Stripe checkout, usage events, and an AI-assisted feature that turns user input into structured output. There is not enough evidence yet to justify microservices, a custom identity layer, a separate vector database, Kubernetes, or a full event platform. There is enough evidence to justify production hygiene because the first paying user will still notice broken auth, missing invoices, slow pages, and confusing AI output.

The common mistake is to confuse "MVP" with "toy."

The second mistake is to overcorrect by building the platform you hope to need in a year.

The real tradeoff is not simplicity versus seriousness. The tradeoff is reversible speed versus invisible obligation. A stack is good when it lets you ship a thin product slice and still see the places where quality matters: types, validation, payment state, analytics, traces, authorization, and database schema.

That is why I like this shape.

The architecture is not fancy. The point is that every major product question has a place to land.

Who is using it? PostHog.

Can they pay? Stripe.

What did the backend do? OpenTelemetry.

Why did the agent make that decision? LangSmith if the workflow is graph-shaped, or structured logs if it is not.

What is the source of truth? Postgres.

What shape should data have at the boundary? Pydantic and TypeScript.

Backend: FastAPI Until the Backend Stops Being the Bottleneck#

I still like FastAPI for this layer because it gives Python teams a clean HTTP surface with type hints, validation, dependency injection, generated OpenAPI docs, and async support. The FastAPI features page is explicit about the design center: standard Python type hints drive validation, serialization, editor support, and documentation.

That matters more in AI-assisted development than people admit.

LLMs work better when the codebase has named contracts. A request model like this is not only runtime validation. It is also context for the assistant, documentation for the next developer, and a small refusal to let vague JSON drift through the system.

from pydantic import BaseModel, Field
 
 
class BriefRequest(BaseModel):
    account_id: str
    source_text: str = Field(min_length=20)
    tone: str = "operator"
 
 
class BriefResponse(BaseModel):
    summary: str
    risks: list[str]
    next_actions: list[str]

I would deploy a small FastAPI service on Railway when the team is trying to keep operations light. Railway's pricing page is the source to check because the exact plan names and included usage can change, but the product idea is still attractive: push the service, attach environment variables, add managed resources when needed, and avoid spending the first month becoming a platform team.

The failure mode is not FastAPI. The failure mode is letting the backend become a kitchen drawer.

Keep the service narrow:

• HTTP routes own request and response contracts.
• Application services own product actions.
• Database access stays behind repositories or query modules.
• AI calls are wrapped behind typed functions.
• Background work gets a real queue before it becomes "just one more async task."

If the backend becomes a bundle of route handlers, prompt strings, SQL queries, webhook logic, and product analytics calls, the stack is not helping anymore. It is just letting you make the mess quickly.

Frontend: TypeScript Is Product Infrastructure#

For the frontend, I pick Next.js when the product benefits from file-system routing, server components, server actions, metadata handling, and the Vercel deployment path. I pick Vite when I want a tight client app, an embedded dashboard, or a more explicit frontend/backend split. The Next.js TypeScript docs and the Vite guide both lean into the modern assumption that frontend work should be typed, fast to run, and easy to refactor.

The LLM angle is practical. TypeScript narrows the assistant's playground.

If the shape of an API response is known, Copilot is less likely to invent fields. If a component prop is typed, the assistant has a smaller target. If the editor can flag the mistake immediately, the human reviewer can spend attention on product behavior instead of syntax and property names.

type SubscriptionStatus = "trialing" | "active" | "past_due" | "canceled";
 
type AccountDashboard = {
  accountId: string;
  planName: string;
  subscriptionStatus: SubscriptionStatus;
  remainingCredits: number;
};

That is why I do not treat types as ceremony. They are a communication protocol between humans, code, tests, and agents.

Vercel is the default hosting choice for a Next.js app because the deployment model is built around that framework. The Vercel pricing page is the cost reference I would keep linked in the decision brief, not copied into the codebase as permanent truth. If the product is a Vite app with a plain static frontend, Vercel is still fine, but the deployment advantage is less special.

Database and Auth: Supabase Before Service Sprawl#

I used to see a lot of early products default to MongoDB because document shape felt faster during prototyping. I understand the appeal, but I would usually rather start with Supabase now.

Supabase gives the team a real SQL database, managed auth, row-level security options, realtime features, edge functions, and common Postgres extensions without asking the team to stand up all of that separately. The Supabase billing docs, Edge Functions docs, and pgvector docs are the pages I would keep close when making the decision.

The important part is not "use every Supabase feature."

The important part is that product state lives in SQL from day one. Accounts, subscriptions, documents, projects, tasks, usage events, permissions, and AI outputs can have constraints. You can query them. You can inspect them. You can migrate them.

For AI features, pgvector is often enough at the beginning:

create table document_chunks (
  id uuid primary key default gen_random_uuid(),
  account_id uuid not null,
  document_id uuid not null,
  chunk_text text not null,
  embedding vector(1536) not null,
  created_at timestamptz not null default now()
);

I would not buy a separate vector database until Postgres is visibly failing the workload. The graduation trigger should be measured: index size, latency, recall quality, operational isolation, or query patterns that no longer fit the primary database.

AI Code: Stay Minimal Until the Workflow Needs a Graph#

The fastest way to make an AI app hard to debug is to hide the core behavior behind a framework before the team understands the workflow.

For many SaaS features, pure Python plus typed request and response models is better than a heavy orchestration layer. Pydantic is enough to define the contract, validate tool inputs, parse outputs, and make failures explicit. The Pydantic validation docs are worth reading as application architecture guidance, not only Python library docs.

class ExtractedTask(BaseModel):
    title: str
    owner_hint: str | None = None
    due_date_hint: str | None = None
    confidence: float = Field(ge=0, le=1)

I would reach for LangGraph when the workflow has real state: multi-step control flow, tool calls, retries, user approval, resumability, or human-in-the-loop review. The LangGraph overview frames it around durable execution, streaming, persistence, and human-in-the-loop workflows. That is the right use case.

I would not use an agent framework to call one model once.

For observability, LangSmith observability is convenient when the workflow is already LangGraph-shaped. For the rest of the backend, I want standard traces. The OpenTelemetry FastAPI instrumentation docs matter because AI products still have normal distributed-systems problems: slow endpoints, failed dependencies, retries, timeouts, and missing context.

Payments and Product Analytics Are Not Later Work#

Stripe should enter the architecture earlier than most teams want. Not because billing is the most interesting part, but because a SaaS product that cannot charge is still hiding one of its most important workflows. Use the Stripe pricing page for current payment processing cost assumptions and treat webhooks as production code, not glue.

@router.post("/stripe/webhook")
async def stripe_webhook(request: Request) -> dict[str, str]:
    payload = await request.body()
    signature = request.headers["stripe-signature"]
    event = verify_stripe_event(payload, signature)
    await apply_billing_event(event)
    return {"status": "ok"}

PostHog should also enter early. The PostHog pricing page changes over time, so I do not hardcode pricing claims into architecture docs. I do hardcode the product habit: track activation, retention, funnel completion, and feature usage before the team starts arguing from anecdotes.

The data model does not need to be large:

posthog.capture("brief_generated", {
  account_id: accountId,
  source: "dashboard",
  model_family: "gemini",
  duration_ms: durationMs,
});

The mistake is waiting until after launch to define what "working" means.

Cost Bands I Would Actually Use#

Pricing pages move, and usage changes faster than estimates. Still, it helps to have bands.

The first cost trap is buying infrastructure to avoid deciding what the product is.

The second cost trap is ignoring usage-based AI spend because the hosting bill looks small.

The third cost trap is putting analytics, traces, logs, and model calls on autopilot without retention rules.

Default Stack Decision Brief#

This is the artifact I would keep in the repo before the first line of code becomes permanent.

# Default SaaS Stack Decision Brief
 
## Why
 
We need a fast product-learning loop with typed boundaries, low operational drag,
and enough observability to debug user-facing workflows.
 
## What We Are Choosing
 
- Backend: FastAPI on Railway
- Frontend: Next.js on Vercel, or Vite when the app is primarily client-side
- Database/Auth: Supabase Postgres and Auth
- AI workflow: Pure Python + Pydantic first; LangGraph only for stateful workflows
- Payments: Stripe
- Product analytics: PostHog
- Observability: OpenTelemetry for services; LangSmith for graph-shaped AI traces
 
## What This Replaces
 
- Custom auth
- Separate vector database before evidence
- Heavy agent framework for one-shot model calls
- Kubernetes before platform need
- Untyped JSON contracts
 
## When It Breaks
 
- Background jobs need stronger guarantees
- Database workload needs isolation or tuning beyond the managed default
- AI workflows need durable state, retries, interrupts, or human review
- Analytics or traces become too expensive without retention controls
 
## When To Graduate
 
- Split workers from the API
- Move stable high-throughput boundaries to Go/gRPC
- Add queue semantics
- Introduce a dedicated search/vector service only after measuring Postgres limits

That document does not make the stack perfect. It makes the tradeoffs visible.

That is what I want from a SaaS stack now. I want the product team to learn quickly, the engineering team to debug honestly, and the AI assistant to operate inside rails that humans can review.