Revenue OS — AI Sales & Revenue Platform
A multi-tenant B2B platform covering the full revenue lifecycle, from lead ingestion and AI research to outreach, bookings and revenue analytics.
Overview
Revenue OS is a production-grade, multi-tenant platform for B2B sales teams. It covers the whole lifecycle: lead ingestion, validation, deduplication, enrichment, AI research, ICP fit, qualification, scoring, personalised outreach, reply intelligence, booking, CRM, proposals, deal tracking and revenue analytics.
The Problem
Sales teams stitch together many separate tools for leads, enrichment, outreach and CRM. Data gets duplicated, AI features run without guardrails, and nothing gives a single reliable view of the pipeline.
Solution
A modular monolith with hard domain boundaries. Thin FastAPI routes call application services and repositories on SQLAlchemy 2.0 async; PostgreSQL is the single source of truth. Long-running work is stored as a job row and published to a Redis Stream through a transactional outbox, then processed by separate workers. Every tenant-owned row carries an organization ID enforced at the data-access layer.
Architecture
Key Features
- →Multi-tenant data model with tenant isolation at the data-access layer
- →Versioned REST API with JWT access tokens and httpOnly refresh cookies
- →Transactional outbox + Redis Streams job contract; unknown jobs retried and dead-lettered, never dropped
- →Provider adapters for LLMs, enrichment, email, calendar, CRM and storage
- →Alembic migrations as the only way the schema changes
- →Observability plan: Sentry, Langfuse AI traces, structured JSON logs and audit logs
Tech Stack
Key Decisions & Challenges
Never losing a background job
Publishing to a queue and writing to the database can fail independently. The transactional outbox writes the job and its event in one database transaction, so work is never lost or duplicated.
Tenant isolation
In a multi-tenant system one missing filter can leak data. Tenant filtering is enforced centrally in the data-access layer and covered by dedicated security tests.
Testing & Quality
- ✓23 backend tests passing (pytest), including API and security tests
- ✓ruff linting, plus frontend lint, unit tests (Vitest) and production build
- ✓Alembic baseline migration verified by generating SQL
- ✓Health and readiness endpoints for deployment checks
Lessons Learned
- →Writing architecture docs before code made a large system manageable
- →Clear job contracts make background processing testable
Results
Phase 1 (foundation) is complete: backend core, database layer, migrations, job contract, meta APIs and the frontend shell with its design system, all with green tests and builds. Identity and the first business domains come next.
What I'd Do Differently
- ↻Set up the Docker-based local stack first so every phase is verified against real Postgres and Redis
Related Projects
Need something similar?
I can build a system like this for your business — tell me what you need and I'll reply with a plan and a quote.