Custom AI SaaS Platform, White-label AI agent builder for businesses to ship their own AI products

Project Overview

The client wanted to sell AI agents to their own customers under their own brand. We built a white-label SaaS platform that lets businesses spin up a tenant, brand it, feed it their content, and ship an AI agent that answers questions and captures leads. No code is required from the tenant.

Client Background

The client operates in the AI products space and sells to other businesses. Their customers want AI features in their workflows but do not want to build LLM infrastructure, manage prompts, or maintain a retrieval pipeline. The client needed a platform they could resell so each of their customers gets a private, branded instance with isolated data.

The Problem

Most white-label AI tools stop at a logo swap. That is not enough for a real B2B product. A serious offering needs strict tenant isolation, a permissions model that fits how customer teams actually work, retrieval over each tenant's own documents, and a place for operators to see the leads their agents collect.

Building that stack from scratch is expensive. Without it, the client could not credibly sell to mid-market customers who ask hard questions about data boundaries, access control, and brand control.

Challenges

• Multi-tenant data isolation that holds up at the database and the vector store, not just in application code.
• A permissions model that supports admins, operators, and viewers across multiple resources per tenant.
• Branding that goes beyond a logo: colors, copy, domain, and the chat surface itself.
• Document and website ingestion that handles messy PDFs and live URLs without manual cleanup.
• Two language stacks in one product, since AI work fits Python and the API surface fits TypeScript.
• Keeping latency acceptable for live chat while still doing retrieval on every turn.
• A lead capture surface that operators trust enough to act on.

Our Approach

We started by separating the platform into three concerns: the agent runtime, the control plane, and the tenant-facing surface. That made it possible to pick the right tool for each job instead of forcing one stack to do everything.

We agreed early that tenant isolation had to be enforced at the data layer, not assumed at the application layer. Every query filters by tenant. Every vector lookup is scoped to a tenant namespace. Branding and RBAC sit on top of that as policies, not as afterthoughts.

We treated ingestion as a first-class pipeline, not a one-off script. PDFs and URLs go through the same path, get chunked, embedded, and written into the tenant's vector space. That keeps the agent's behavior predictable across content types.

What We Built

User Experience

End users see a branded chat surface that belongs to the tenant, not to the platform. Conversations feel native to the tenant's product. Lead capture is conversational, not a hard-coded form.

Admin Operations

Tenant admins manage their own users, set roles, upload knowledge sources, and watch the lead dashboard. They do not need to file tickets for routine changes.

Automation

Document and website ingestion runs as a background pipeline. New sources are parsed, chunked, embedded, and indexed without manual steps. Re-indexing happens when sources change.

Integrations

The platform talks to OpenAI and Claude through provider-specific clients. A vector database holds tenant-scoped embeddings. The lead dashboard exposes data in a shape that is friendly to downstream CRMs.

Security

RBAC is enforced per tenant, per user, and per resource. Tenant data is isolated at the database level. Vector queries are scoped so one tenant cannot retrieve another tenant's chunks.

Performance

The chat path is kept short on purpose: retrieve, assemble, call the model, return. Heavy work like ingestion runs out of band so live conversations stay responsive.

Technical Architecture

The platform is split into a Next.js frontend, a NestJS API gateway, and a FastAPI agent runtime. PostgreSQL holds tenant, user, and lead data. A vector database holds embeddings scoped by tenant. The frontend is the only public surface; everything else sits behind the API.

Key Decisions

• Split FastAPI and NestJS. FastAPI runs the AI workloads where Python libraries are strongest. NestJS handles the API gateway, auth, and tenant logic where TypeScript and a structured framework pay off. The tradeoff is two runtimes to operate, which we accepted for code clarity.
• Enforce tenant isolation at the data layer. Every row and every vector carries a tenant identifier. The tradeoff is more discipline in queries; the benefit is that a code mistake cannot quietly leak across tenants.
• Use RAG instead of fine-tuning per tenant. Tenants change content often, and RAG keeps the loop short. The tradeoff is more retrieval work per request; the benefit is fresh answers without retraining.
• Support both OpenAI and Claude. This avoids single-provider risk and lets the client pick the right model per use case. The tradeoff is two integrations to maintain.
• Build branding as configuration, not forks. Each tenant's look is data, not a separate deployment. The tradeoff is a stricter design system; the benefit is one codebase to ship.

Results

• Tenants can be provisioned, branded, and loaded with their own knowledge base without engineering work from the client's team.
• Operators have a clear view of incoming leads in one place instead of digging through chat logs.
• Adding a new tenant does not require a separate deployment or a code change.
• Tenant data stays inside its own boundary in both Postgres and the vector store.
• The platform supports the client's resale model end to end, from tenant signup to live agent.

Project Highlights

• Real multi-tenant isolation at the database and vector layers, not just in app code.
• Per-tenant RBAC across users and resources.
• Full branding control per tenant, including the chat surface.
• RAG over PDFs and website content with the same pipeline.
• Lead capture dashboard built for operators, not just analysts.
• Dual-stack design that puts each problem in the language that fits it.

Screens and User Flows

The core flow is tenant onboarding followed by an end-user conversation. A tenant admin uploads documents and URLs, the ingestion pipeline embeds them into the tenant's vector space, and the agent goes live on the tenant's branded surface. End-user messages trigger a retrieval call, an LLM call, and a lead check on every turn.

Future Growth Opportunities

• Per-tenant custom domains and SSL, since branding is already config-driven.
• SSO for tenant admins via SAML or OIDC, which slots into the existing auth boundary.
• Analytics per tenant on agent quality, top questions, and unanswered queries, built on the data already collected.
• Outbound integrations to CRMs and helpdesks, since lead data is already structured.
• A marketplace of prebuilt agent templates that tenants can clone and customize.
• Voice and phone channels on top of the same agent runtime and retrieval layer.