— CASE STUDY / AI PLATFORM

Two AI products on one shared platform, shipped under the Kashi Labs brand.

Kashi Labs is the AI-product brand and shared platform under which Cloudbrief (daily AWS observability) and Paperbrief (multi-tenant RAG document Q&A) ship today. Both products run from one Lightsail box in Mumbai, one PostgreSQL instance, one OpenTofu footprint. The thesis: build the 80% once, ship two products that earn their place, and refuse the four-modules-at-launch fantasy that nobody operates well.

Founder & lead architect · 2026–present · Live · Early release

View live demo →

— Section B

Context

Generic AI loses to ChatGPT itself. The buyer that wants a tool that watches an AWS account for cost spikes, or chats with their own documents — without sending data to a US horizontal that defaults to English and stores in Virginia — needs vertical AI built around a specific job, not a general-purpose chat surface. Kashi Labs is the brand and the shared platform behind those vertical products.

Kashi Labs is the bet that the 80% of every AI SaaS is the same — auth, billing, file ingest, vector retrieval, structured extraction, AI orchestration, prompt management, chat UI, usage metering, observability — and building that 80% once is the only way a solo founder ships two products from one box. Two modules ship publicly today: Cloudbrief (daily AWS observability via a read-only IAM role; deterministic detectors plus Claude synthesis) and Paperbrief (multi-tenant RAG document Q&A with per-tenant isolation enforced in the database). Both share the same FastAPI process, the same PostgreSQL instance, the same nginx, the same TLS-at-the-edge through Cloudflare Origin CA. The Microsoft 365 playbook, scaled down for a vertical and operated by one person.

This case study began as a Phase-0 architecture write-up under the working name “AI Core Platform” for a planned four-module suite (Docusense, DataSense, ComplianceSense, TaxSense). Two of those modules shipped — renamed Paperbrief and Cloudbrief — and two were deferred. The honest reason: shipping and operating two products well, end-to-end, with real customers in early release, is harder than designing four. The platform was always the point; the module count followed reality.

Most software fails on decisions made in the first month, not the last. The job of Phase 0 was to make those decisions early — and the job of every month since has been to refuse the modules that would have diluted the two that earned their keep.

— Section C

My role

I’m the founder, sole architect, and product designer. I wrote every ADR, every principle, every capability contract, every module brief. The architecture decisions, the vendor choices, the rollout sequence, the India-first positioning: all mine. Phase 1 implementation begins after Phase 0 setup closes — accelerated with modern AI coding tools (Cursor, Claude) under tight direction. Every line that ships will be reviewed and owned by me.

— Section D

The hard parts

Five architectural decisions worth surfacing. Each one is the kind of choice people regret not making earlier — and the entire premise of this case study is that on this product, those decisions were made first.

Workspace is the tenant, user is a member

Enterprise buyers buy organizations, not seats. Self-serve individuals are still organizations of one. The temptation in early SaaS is to make user_id the primary key on every domain table — and then to spend a year migrating to a proper tenant primitive when the first enterprise contract lands. Kashi Labs refuses that path.

Every domain object — document, chunk, embedding, run, prompt version, invoice, audit log — belongs to a workspace_id. A user is a member of one or more workspaces. Row-level security and application-level scoping both use workspace_id, never user_id, as the primary tenant key. Personal workspaces are modeled as a workspace of one with a single owner. Self-serve and enterprise share the same code path; the same RLS policy serves a freelancer and a Fortune-500 procurement team.

One platform, four modules, thirteen shared capabilities

Four AI products built independently is four codebases, four billing surfaces, four chat UIs, four ingest pipelines, four prompt frameworks, four observability stacks. Four times the maintenance, four times the deploy risk, and a velocity curve that goes flat the day you start the third product.

Kashi Labs builds the platform once. Thirteen platform capabilities — identity and workspace, billing and entitlements, file ingest (structured and unstructured), structured extraction, vector retrieval, structured store with execution sandbox, scheduled external ingestion, AI orchestration, prompt framework, workflow engine, chat UI shell, notifications and usage and audit — are implemented in the core. Each capability must be used by at least two modules to earn its place in the core. The shipped modules (Cloudbrief, Paperbrief) are plugins on top, each contributing module-specific domain knowledge: AWS cost anomalies and reliability detectors for one; multilingual document chunking and grounded retrieval for the other. The platform paid for itself the day the second module shipped.

Module contracts, no DB reach-across

A modular monolith without discipline becomes a tangled monolith in three months. Cross-module imports of model classes, cross-module SQL joins, cross-module direct service calls — each one is a load-bearing wire that prevents extraction later, and the cumulative effect is a monolith that cannot be split even when the team is ready to.

The Kashi Labs platform’s third principle is structural: a module = entitlement + surfaces + contracts, never DB reach-across. Modules may not read or write another module’s tables directly. Cross-module needs go through the core (both Cloudbrief and Paperbrief use Vector Retrieval and the Scheduling service from the core, with module="cloudbrief" or module="paperbrief" in queries). Module tables live in module-prefixed schemas. A static check on pull requests rejects cross-module imports of model classes. The result: any module can be lifted into its own service in year two if scale demands it, without rewriting the rest.

Ports-and-adapters everywhere

Every vendor choice an early-stage AI platform makes is a guess. The right embedding provider in 2026 may be the wrong one in 2027. The right vector store, the right LLM router, the right OCR engine, the right workflow queue — these are all guesses that benefit from being reversible.

Kashi Labs implements every core capability as a typed Python interface (port) with one or more adapters: local for development, hosted for production, mock for tests. Picked pgvector for the launch? Swap to Qdrant in year two by writing one adapter, not editing 200 callsites. Picked OpenAI for embeddings? Anthropic Claude is already the chat adapter — adding a second embedding provider is one adapter, not a refactor. Fifteen ADRs document each choice and the reasoning at the time it was made; the architecture survives the choice changing.

India-first, multi-region capable

Indian data residency is not a feature toggle. It is a default. If the architecture assumes US-region storage and then adds India later, every workspace ID, every signed URL, every cross-region query has to be retrofitted. Kashi Labs inverts the default: ap-south-1 (Mumbai) is the deployment region, data residency is a workspace plan attribute, and multi-region routing is deferred but not architecturally impossible.

Workspace IDs are designed to carry region prefixes when multi-region lands. Storage buckets are per-region from day one. Billing is INR-first with GST invoices and Razorpay; USD is a secondary path for non-Indian customers. The Hindi, Gujarati, Marathi, and Tamil language paths are first-class in the ingest, embedding, and chat flows — not English with a translation layer bolted on. The wedge against US horizontals is structural, not marketing.

— Section E

Architecture

One platform core delivering shared capabilities; two vertical modules shipped, more deferred until each earns its place.

Cloudbrief

first candidate for extraction
Paperbrief

first candidate for extraction
DataSense
TaxSense

Two modules shipped today: Cloudbrief (AWS observability) and Paperbrief (RAG document Q&A). Two more were designed in Phase 0 and deferred.

— Section F

Stack

Backend: FastAPI · Python 3.12 · PostgreSQL 16 (pgvector + pgcrypto + native RLS) · APScheduler (per-org schedules) · modular monolith — one FastAPI process serving both modules
AI: Anthropic Claude (chat, OCR, synthesis) · OpenAI text-embedding-3-small (embeddings only)
Frontend: React · Next.js (static export per product) · TypeScript · Tailwind CSS
Marketing: Astro (kashilabs.ai umbrella + per-product marketing sites)
Infrastructure: AWS Lightsail Mumbai (4 GB box — runs both products + Postgres + nginx) · Cloudflare (DNS, Origin CA 15y, edge cache, Pages for static frontends) · AWS SSM SecureString (all secrets — API keys, pgcrypto key, OAuth secrets) · OpenTofu (full IaC — Lightsail, S3, SES, IAM, SSM, CloudWatch alarms, SNS, Cloudflare zones) · Ansible (box config: nginx vhosts, systemd units, cron, certs from SSM) · Nightly pg_dump → S3 with 30-day retention

— Section G

What shipped

Live at kashilabs.ai (the platform umbrella), with two products in early release at cloudbrief.app and paperbrief.app. The platform runs end-to-end on production infrastructure and onboards real customers.

— Two products shipped under one platform: Cloudbrief (daily AWS observability) + Paperbrief (multi-tenant RAG document Q&A). Both share the same FastAPI process, the same PostgreSQL instance, the same TLS edge.
— Shared platform capabilities in production: identity + workspace, JWT auth, file ingest, vector retrieval (pgvector), AI orchestration (Claude + OpenAI embeddings), per-tenant pgcrypto column encryption, usage metering, immutable access audit, scheduled per-org jobs (APScheduler).
— Single-box deploy in Mumbai ap-south-1 — 4 GB Lightsail, ~$24/mo infra, full IaC in OpenTofu. Both products survive a single tofu apply for disaster recovery.
— Cloudflare Origin CA 15-year certs across kashilabs.ai, cloudbrief.app, paperbrief.app — no certbot rotation. Strict TLS at the edge.
— SES verified across all four corporate domains (kashilabs.ai, kashitechnology.com, cloudbrief.app, paperbrief.app) with DKIM signing.
— Migrated to a dedicated AWS account in 2026 — old account decommissioned. Migration took ~30 seconds of read-only downtime end-to-end because of the IaC footprint.
— Two modules deferred from the original Phase-0 plan (DataSense for spreadsheets, TaxSense for Indian tax forms). Designed, but not greenlit until the two live products earn the right to a third.

Not yet shipped: paid-plan billing UX (Razorpay primary, Stripe for international — both wired in SSM, both blocked on customer onboarding signals), a Slack / email digest channel, a per-finding feedback loop, the deferred modules. The architecture supports all of these — they’re sequencing decisions, not unsolved problems.

Designing an AI platform with this shape — multi-module, vertical, India-first, with two products earning their keep before a third gets approved?

Let’s talk.

Book a call →