DEV Community: Anurag Srivastava

Building AI SaaS MVP, the right way

Anurag Srivastava — Mon, 04 May 2026 18:18:27 +0000

Adding AI to a product takes an afternoon. An API key, a prompt, a fetch call. Done.

Building the system that runs that AI feature in production is a different problem entirely. How do you isolate data between tenants so Org A never sees Org B's rows? How do you bill for usage and actually block access when the quota runs out? How do you build a dashboard that shows real numbers instead of placeholder charts?

I built TubeDigest, a YouTube video summarizer. Teams paste a video URL, get a summary. The summarization is one OpenAI call. The multi-tenant org structure, subscription billing, usage enforcement, caching layer -- that's where the actual work went.

This post is about all of that.

What's actually running

On the surface: paste a YouTube URL, get a summary. Behind that:

Postgres Row Level Security handles tenant data isolation. Org A can't query Org B's rows even if the application code has a bug. The database enforces it, not my WHERE clauses.

Billing runs through Dodo Payments with real subscriptions. Free tier has a monthly cap. Hit it, you're blocked. Upgrade, the limit goes up. Webhooks handle the whole lifecycle.

Organizations are the tenant boundary. Invite team members, assign roles (owner or member), manage access. Actual multi-user orgs, not single-user accounts with a team label stapled on.

There's also a caching layer in front of the AI pipeline. If any org has already summarized a particular video, the cached result gets returned. One transcript extraction and one OpenAI call serve every future request for that same video.

Tech stack

Layer	Choice
Frontend	Next.js (App Router) + Tailwind CSS + shadcn/ui
Backend	NestJS (separate service)
Database	PostgreSQL on Neon
ORM	TypeORM
Auth	Clerk
Billing	Dodo Payments
AI	OpenAI API
Monorepo	Turborepo + pnpm

Frontend and backend are separate services, deployed independently. The frontend handles UI and auth. The backend owns the data, billing logic, and AI pipeline. They talk over REST -- 17 endpoints, all documented with Swagger.

I split them because that's how I'd build a client's SaaS product. Not because it looks good on a diagram.

Data isolation

Most multi-tenant apps put WHERE org_id = ? on every query. Miss one and you have a data leak. That approach works until someone forgets, and then it's a breach.

TubeDigest uses Postgres Row Level Security. The database enforces who sees what.

Every request goes through a middleware that verifies the Clerk JWT, pulls the org_id, and sets it on the connection:

SET LOCAL app.org_id = 'the-org-id';

After that, every query on tenant-scoped tables gets filtered by the database engine. Not by application code. The policy:

CREATE POLICY tenant_isolation ON users
  USING (org_id = current_setting('app.org_id')::uuid);

This covers users, invitations, subscriptions, usage_records, and user_summaries. The videos table has no RLS because it's the shared cache. All orgs read from it.

If my code has a bug that skips the org filter, the database catches it anyway. The safety net is in the infrastructure, not in my discipline.

Billing that works end to end

A lot of SaaS demos have a pricing page and a test checkout button that goes nowhere. TubeDigest has a billing system that processes real payments.

Dodo Payments handles subscriptions. Checkout sessions, webhook events, billing portal -- standard payment gateway patterns:

Sign up. Land on Free tier with a monthly summary cap
Use up the quota. API returns 429s
Click upgrade. Dodo checkout. Payment processes. Webhook fires
Backend catches the webhook. Updates the subscription. Raises the limit
User manages billing through the self-service portal

Usage tracking is per org, per billing period. Every summary request increments a counter. The system knows how many summaries each org has used, when the period resets, and what the cap is. The dashboard shows all of this live.

Duplicate payments

This problem doesn't show up in demos. It shows up in production, and it wrecks things.

User clicks checkout twice. Network hiccup makes Dodo fire the same webhook twice. User opens checkout in two browser tabs. All of these cause the same issue: duplicate payment processing. Double charges, phantom subscription upgrades, usage limits applied twice.

TubeDigest processes webhooks idempotently. Every incoming event gets checked against what's already been processed. If the system has seen that event before, it acknowledges it and moves on. No state change. The subscription table stays clean no matter how many times the same event arrives.

Not a lot of code. But this is the kind of thing that separates a demo from a system that handles real money.

The AI pipeline

The summarizer is simple on purpose. I wanted the complexity in the infrastructure, not the AI call. Here's the flow:

User submits a YouTube URL
Backend extracts the video ID, checks the videos cache table
Cache miss: pull transcript via YouTube's captions API
Truncate to about 4000 tokens (roughly 20 minutes of spoken content)
Send to OpenAI, get summary back
Store transcript and summary in the cache, keyed by video ID
Log the request in user_summaries, increment the org's usage counter

Cache hit? Skip steps 3 through 6. Return the stored summary immediately. A YouTube video that gets summarized by 500 different orgs costs one API call. Not 500.

No captions on the video? Return a 422 with a clear message. Don't touch the usage counter. Don't charge for failures.

Dashboard with real data

Building a dashboard is easy. Having real data to put in it is the harder part, because the data pipeline has to exist first.

TubeDigest tracks:

Summaries used this period, out of the plan's limit. Live counter
Recent activity. Last 5-10 summaries with video titles and timestamps
Daily usage. Bar chart of summaries per day across the billing period

All of that comes from two tables: usage_records and user_summaries. No analytics service. No third party dashboard tool. The same data pipeline that tracks billing also feeds the dashboard.

Project structure

Monorepo with Turborepo and pnpm:

tubedigest/
├── apps/
│   ├── web/     # Next.js frontend → Vercel
│   └── api/     # NestJS backend → Render
├── packages/    # Shared types
├── turbo.json
└── pnpm-workspace.yaml

CI runs lint, type-check, and build on every push via GitHub Actions. Vercel and Render auto-deploy when the pipeline passes. Swagger docs live at /api/docs with request and response schemas for every endpoint.

What I'd add at scale

These aren't missing. They're unnecessary at this stage. If TubeDigest had real traffic, they'd be next:

Async processing. Summarization is synchronous right now. At scale, a job queue with Bull and Redis would handle long videos without blocking request threads.
Chunk and merge for long transcripts. I truncate at about 4000 tokens, roughly 20 minutes. A chunk, summarize, merge pipeline would handle 3 hour lectures but costs more in API calls.
Integration tests for billing webhooks and RLS policies. The two most important paths in the system deserve the most test coverage.

Try it

Live demo: tubedigest-web.vercel.app

anuragmerndev / tubedigest

TubeDigest

A multi-tenant SaaS YouTube video summarizer. Paste a YouTube URL, get a concise AI-generated summary. Built with organization-based multi-tenancy, usage-based billing, and role-based access control.

Tech Stack

Layer	Technology
Monorepo	Turborepo + pnpm workspaces
Frontend	Next.js (App Router) + Tailwind CSS + shadcn/ui
Backend	NestJS
Auth	Clerk
Database	PostgreSQL (Neon) + TypeORM
Multi-tenancy	Row-Level Security (RLS)
Billing	Dodo Payments
AI	OpenAI API

Features

AI Summarization — paste a YouTube URL, get a summary powered by OpenAI
Multi-Tenancy — organization-based isolation with Postgres RLS
Role-Based Access — owner and member roles with backend-enforced permissions
Usage Tracking — per-organization usage limits and daily usage charts
Billing — subscription management via Dodo Payments
Team Management — invite members, manage roles, revoke access
Video Caching — same video = reuse cached summary, saving API costs

Project Structure

tubedigest/
├── apps/
│   ├── web/        # Next.js frontend
│   └── api/        # NestJS backend
├──

…

View on GitHub

The AI feature took a day. The system around it took the rest of the week. That ratio tells you where the real engineering is.

I built a production RAG pipeline. Here's what most tutorials skip.

Anurag Srivastava — Mon, 13 Apr 2026 19:21:21 +0000

I wanted a RAG system that was fast to run and fast to set up for clients. Upload a PDF, ask questions, get answers with citations. Pretty standard stuff for anyone freelancing in the AI space.

The problem is that every tutorial I found stops at a Jupyter notebook. Working demo, zero production readiness. No auth, no caching, no way to handle more than one user. The happy path, and nothing else.

So I built the whole thing. Deployed, running, something I can actually show to clients.

Here's what that looked like.

Live Demo | Backend Repo | Frontend Repo

Following a question through the pipeline

The easiest way to explain this system is to trace what happens when someone asks a question.

Say a user uploaded a 150-page book and types: "What's the main argument of chapter 3?"

The fingerprint problem

First thing I need to figure out: have I seen this question before?

Not this exact string. That's easy. But what about "what is the main argument of chapter 3" without the contraction? Or "What's the main argument of chapter 3??" with extra punctuation? Different casing?

Same question, four different strings. A naive string comparison treats each one as unique, and each one costs an OpenAI embedding call. That adds up.

The fix I landed on: normalize the query first. Expand contractions, strip punctuation, remove stopwords, collapse whitespace. Then SHA-256 the cleaned string.

The normalization + fingerprinting code

function normalizeQuery(input: string): string {
    let text = input.toLowerCase().trim();

    // "don't" → "do not", "what's" → "what is"
    for (const [k, v] of Object.entries(CONTRACTIONS)) {
        text = text.replace(new RegExp(`\\b${k}\\b`, 'g'), v);
    }

    text = text.replace(/[^a-z0-9\s]/g, ' '); // strip punctuation
    text = text.replace(/\s+/g, ' ');           // collapse spaces

    const words = text.split(' ').filter(w =&gt; !STOPWORDS.has(w));
    return words.join(' ').trim();
}

const fingerprint = crypto.createHash('sha256')
    .update(normalizeQuery(query))
    .digest('hex');

All four variations produce the same hash. One fingerprint, one cache key. The embedding cache and response cache both use this, so every performance shortcut downstream starts here.

Cache check

The pipeline looks in Redis for a cached embedding vector at emb:{fingerprint}. If it finds a 1536-dimensional array there, it skips the OpenAI embedding call. About 200ms saved before we even talk to the vector database.

Embedding cache logic

let queryEmbedding: number[];
const cached = await cacheService.getCache(`emb:${fingerprint}`);

if (cached) {
    queryEmbedding = JSON.parse(cached);
} else {
    queryEmbedding = await embeddingService.getEmbedding(query);
    await cacheService.setCache(
        `emb:${fingerprint}`,
        JSON.stringify(queryEmbedding),
    );
}

There's also a response cache (resp:{fingerprint}) that stores complete LLM answers. I found out during testing that this breaks in conversation mode, though. The same question asked as a follow-up has different context because of chat history, so the cached answer would be wrong. The response cache only kicks in for standalone queries. The embedding cache works everywhere.

I added an X-Cache-Embed response header so the frontend knows which path was taken. Helps when debugging latency issues in production.

Vector search

The embedding goes to Pinecone for similarity search. Multi-tenancy is where things get interesting.

Most tutorials scope queries with metadata filters: where: { userId: 'abc' }. That works until someone forgets the filter and suddenly users can see each other's documents.

I used Pinecone namespaces instead. Each user's vectors live in a separate namespace. It's not a filter you can forget to add. The data is physically separated.

Namespace-scoped operations

// Every operation is scoped to the user's namespace
await this.index()
    .namespace(userId)
    .upsert({ records: vectors.slice(i, i + BATCH) });

const result = await this.index()
    .namespace(userId)
    .query({ vector: queryEmbedding, topK, includeMetadata: true });

await this.index()
    .namespace(userId)
    .deleteMany({ ids });

Redacting context before it reaches the LLM

Pinecone returns the top-K matching chunks. Before they go to the LLM, there's a step most tutorials ignore completely.

If someone uploads a security doc with phrases like "bypass authentication" or "disable firewall rules," and asks the right question, the LLM will repeat those instructions. It's in the prompt context. The model doesn't know it shouldn't say that.

So I scan the retrieved chunks for suspicious patterns and replace them with [REDACTED_REASON] before the LLM ever sees the context. The response includes a policy field (allow or partial) so the client knows whether redaction happened.

Pre-LLM redaction filter

const preFilterDocs = (text: string) =&gt; {
    const suspicious =
        /\b(bypass|disable|ignore rules|unrestricted|open firewall|run arbitrary)\b/gi;
    const redacted = text.replace(suspicious, '[REDACTED_REASON]');
    const found = suspicious.test(text);
    return { redacted, found };
};

const policyCheck = () =&gt; {
    const hasSuspicious = preFilterResults.some(r =&gt; r.prefilter.found);
    if (hasSuspicious)
        return { decision: 'partial', reason: 'context_redacted' };
    return { decision: 'allow', reason: 'ok' };
};

Streaming the answer

The redacted context hits GPT-4o-mini. Total response time is about 5.9 seconds, which sounds slow, but the user sees text after 3.5 seconds because of streaming. They're already reading before the model finishes.

The tricky part: source citations need to come after the stream ends. I split it into two SSE event types.

The streaming protocol

// Stream LLM chunks as they arrive
await llmService.streamAnswer(query, redactedContext, (chunk) =&gt; {
    fullAnswer += chunk;
    res.write(`data: ${JSON.stringify({ type: 'chunk', data: chunk })}\n\n`);
});

// Final event: source citations + policy decision
res.write(`data: ${JSON.stringify({
    type: 'done',
    provenance,
    policy: { decision: policyResult.decision, reason: policyResult.reason },
})}\n\n`);
res.end();

chunk events build the message in real time. done triggers the source citation chips below the answer. Two event types, one connection.

Frontend problems I didn't expect

The backend was the interesting part. The frontend is where things broke in ways I didn't anticipate.

Streaming and navigation don't mix in Next.js. When a user sends their first message, the app creates a conversation and updates the URL from /chat to /chat/abc123. I used router.replace(). It unmounted the component. The SSE connection died. The user saw half an answer and got bounced to an error page.

Fix: window.history.replaceState(). Updates the URL without triggering React navigation. Component stays mounted, stream keeps going.

There's also this: the backend always returns source citations even when it says "I don't know." It found context but couldn't answer. Showing citations under a non-answer confuses people. The frontend checks the response text against a regex and hides the source chips when the answer looks like a "no knowledge" response. Took me longer than it should have.

Going to production

Getting this running locally was one thing. Deploying it was a different exercise.

The first Dockerfile was 900MB and ran the dev server. After a few rounds, I landed on a multi-stage build: TypeScript compiles in one stage, the production image only gets the compiled JavaScript and prod dependencies. About 250MB.

First Railway deployment crashed because uploads/ didn't exist in the container. I'd put it in .dockerignore (you don't want local PDFs in your image), but multer needs that directory to write temp files. One-line fix: fs.mkdirSync('uploads', { recursive: true }) at startup. Then I realized the files should be deleted after indexing anyway. No persistent storage, no S3, no disk space to worry about.

The health endpoint hits Postgres, Redis, and Pinecone in parallel with individual timeouts. Railway restarts the container if it fails. Graceful shutdown drains connections with a 10-second limit. CORS is wide open locally, locked to the Vercel domain in production.

None of this is interesting, but skip any of it and the deploy falls over.

Numbers

From the production deployment:

What	How fast
Index a 150-page PDF (840 chunks)	~27s
Index a 42-page PDF (122 chunks)	~7s
First token appears	~3.5s
Full streaming response	~5.9s
Monthly cost	~$5-8

Most of the latency is OpenAI. Embedding generation and LLM inference, not server compute. Streaming covers the gap: 3.5 seconds to first visible text, and people start reading.

Tech stack

Layer	Technology	Why
Frontend	Next.js 15, Tailwind CSS, React Query	App Router, SSE streaming, server side auth
Backend	Express, TypeScript	Full control over SSE and middleware
Auth	Clerk	OAuth + webhook user sync
Vector DB	Pinecone	Managed, namespace isolation
LLM	OpenAI GPT-4o-mini	Fast, cheap ($0.15/1M tokens)
Embeddings	text-embedding-3-small	1536 dims, $0.02/1M tokens
Cache	Redis	Embedding + response caching
Database	PostgreSQL + Prisma	Users, conversations, documents
Hosting	Railway + Vercel	~$5-8/month total

What I'd change

My chunks are fixed at 500 tokens with 100 overlap. They cut mid-sentence sometimes, and the LLM struggles with the partial context. I'd switch to semantic chunking, splitting on paragraph boundaries instead.

I wrote a reranking service and then never connected it. A cross-encoder between vector search and the LLM would drop the marginal chunks before they eat up context window. It's sitting there, just not plugged in.

The other thing: if the LLM errors mid-stream, the user sees a half-finished message and nothing else. No error state, no retry button. I need a type: 'error' event in the SSE protocol. It's on my list.

TypeScript, Express, Next.js, OpenAI, Pinecone, Redis, PostgreSQL, Clerk. Railway + Vercel. About $5-8/month.

If you have questions about any of the architecture decisions, I'm happy to talk about them in the comments.

anuragmerndev / adv-rag

RAG-powered document Q&A API with streaming, dual-layer caching, and multi-tenant vector search

AdvChat — Backend API

RAG-powered document Q&A API with streaming responses, dual-layer caching, multi-tenant vector search, and pre-LLM content redaction.

Live Demo | Frontend Repo | Case Study

Architecture

Upload path: PDF → parse (LangChain) → chunk (500 tokens, 100 overlap) → embed (OpenAI text-embedding-3-small) → store (Pinecone, namespaced per user)

Query path: Question → normalize → SHA-256 fingerprint → check embedding cache (Redis) → embed if miss → similarity search (Pinecone) → redact suspicious context → stream answer (GPT-4o-mini) → persist (Postgres)

Features

RAG Pipeline — PDF upload, chunking, embedding, vector search, LLM answer generation
SSE Streaming — real-time response streaming with a two-event protocol (chunks + done with provenance)
Dual-Layer Caching — embedding cache (emb:) saves OpenAI calls; response cache (resp:) for standalone queries
Query Fingerprinting — normalizes queries (contractions, stopwords, punctuation) then SHA-256 hashes for cache deduplication
Pre-LLM Redaction — scans retrieved context…

View on GitHub

anuragmerndev / adv-rag-ui

Chat interface for RAG-powered document Q&A with real-time streaming and source citations

AdvChat — Frontend

Chat interface for RAG-powered document Q&A with real-time streaming responses, source citations, conversation history, and drag-and-drop PDF upload.

Live Demo | Backend Repo | Case Study

Architecture

The frontend connects to the Express backend via REST and SSE. Clerk handles authentication client-side, and the backend verifies tokens on every request.

Features

Streaming Chat — SSE-based real-time response streaming with chunk-by-chunk rendering
Source Citations — expandable chips showing document name and quoted content per answer
Conversation History — persistent conversations with titles, message counts, sidebar navigation
PDF Upload — drag-and-drop zone with file type validation (PDF only, 25MB limit) and progress feedback
Document Management — searchable list with multi-select checkboxes to scope queries to specific documents
Smart Input — arrow-key history navigation (up/down), Shift+Enter for multiline, auto-growing textarea
Skeleton Loaders — animated message-shaped placeholders while loading old conversations
Thinking Indicator — pulsing dots while waiting for first token
…

View on GitHub