Intelect: multi-tenant CRM with defence-in-depth isolation

White-labelled lead management on one shared PostgreSQL database, with tenant isolation enforced in the ORM and again by Postgres row-level security, and tests that run as a non-superuser so the policies are really exercised.

WhereOwn product

When2026

My roleDesigned and built

OwnershipSole owner

What it is

A CRM for businesses running paid ads. Each client gets a subdomain, branding, team and pipeline. Lead sources plug in as adapters that share validation, de-duplication and audit rows.

Isolation at two layers

An ORM hook adds the tenant filter to every select, update and delete on tenant-scoped models and refuses inserts for another tenant. A query with no tenant context raises instead of returning everything. No route writes the tenant filter by hand.
Postgres FORCE ROW LEVEL SECURITY policies on every tenant table, keyed on a per-transaction setting, so even raw SQL cannot see another tenant's rows. The application connects as a non-superuser role; migrations run as the owner.
The test suite runs against real Postgres as that non-superuser role, because superusers bypass RLS. The tenancy tests are the ones that matter: cookies don't cross tenants, reps see only their leads, raw SQL cannot read another tenant.

Operations

Caddy with a wildcard certificate via DNS-01, GitHub Actions building to GHCR and rolling out over SSH, a one-shot server setup script, backups and a support-impersonation path with its own audit trail. Provisioning a client is a form, not a deploy.