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

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:

1. Sign up. Land on Free tier with a monthly summary cap
2. Use up the quota. API returns 429s
3. Click upgrade. Dodo checkout. Payment processes. Webhook fires
4. Backend catches the webhook. Updates the subscription. Raises the limit
5. 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:

1. User submits a YouTube URL
2. Backend extracts the video ID, checks the videos cache table
3. Cache miss: pull transcript via YouTube's captions API
4. Truncate to about 4000 tokens (roughly 20 minutes of spoken content)
5. Send to OpenAI, get summary back
6. Store transcript and summary in the cache, keyed by video ID
7. 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

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

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.