DHRUVIX
Multi-Tenant SaaS Platform - Seven Products on One Foundation
Seven products, seven times the same plumbing
Every vertical product needed identical platform foundations, and building them per product meant seven places for a tenant-isolation bug to hide.
DHRUVIX is a multi-product B2B SaaS company: one brand, seven products, plus a platform control plane, each deploying independently.
Each vertical product, from Axion (studio & agency invoicing) to Aurix (jewellery retail) and the ones after them, needs the same platform plumbing: who can log in, what plan they’re on, what they’re allowed to see, and how they’re billed.
Building that per product means seven auth systems, seven billing integrations, seven permission models, and seven design languages.
This is a systems problem before it is a screens problem.
What that actually costs
- Duplicated auth & billing inside every product
- Inconsistent design language across the suite
- Each product re-solving multi-tenancy from scratch
- No single place to onboard, entitle, or bill a customer
- Seven separate places for a security or tenant-leak bug to hide
What I had to design around
Founder-led, two products already live on incompatible stacks, and a sixth product whose users had never used software.
Two live products, two stacks
Axion was already on Firebase, Aurix on Postgres/Prisma. The platform had to absorb both without breaking either: migration, not greenfield.
Tenant isolation, non-negotiable
A multi-tenant platform leaks customer data exactly once before it stops being a business. Isolation had to hold even when someone forgets a filter, so it could not live in application logic alone.
The sixth product broke every SaaS assumption
AplaFund runs a village savings group: eleven members, monthly deposits, a meeting where the register is read aloud. The users are not SaaS users, and I was replacing a paper register everyone already trusted.
A screen has to earn that trust back.
Founder-led, no platform team
I owned platform strategy, the data model, the design system and the engineering direction. Sequencing mattered more than scope; anything built early had to still be right at product seven.
Collapse the plumbing into one foundation
Three layers, one tenancy rule, a three-layer token system, and a code audit before anything migrated.
Three-layer architecture
I structured DHRUVIX as a platform control plane, the tenant-facing products, and a shared foundation they all build on.
What sits in each layer
- Control plane (app.dhruvix.in): leads & CRM, plans & entitlements, auth & identity (SSO + magic link), onboarding & billing
- Products (per-subdomain): Axion, Aurix, Nexora, Dwello, ShutterHQ, AplaFund, Admeda: thin apps that trust the platform rather than reimplement it
- Shared foundation (Turborepo): ui, auth and db (Prisma + row-level security) packages, plus api-types, emails and config
What I chose, and what it cost
Three calls that shaped the platform, and three things in the shipped product that are still wrong.
the third one still bugs meShared foundation over first-product speed
Build auth, billing, RBAC and theming once in a shared monorepo before shipping the next product.
Slower to the first product. It compounds across all seven; the seventh becomes mostly configuration, not a rebuild.
Centralized identity over convenience
Auth lives once in the shared package; products never re-implement it.
Products give up local control over their login flow. In exchange: one place to secure, one place to reason about.
Honest sequencing over demo appeal
Ship the design system and control-plane data model first; platform identity and billing follow.
Sequenced by dependency and risk, not by what demos best, so early progress was invisible to anyone watching screens.
What I'd fix
Three things in the shipped product are wrong, and I know why each one is there.
The plan editor exposes raw feature keys (auditLog, removeBranding, loansPerMonth) straight from the entitlements schema into the admin UI. It was fast to build and I was the only user. The moment a non-engineer prices a plan, it breaks.
The sales board has ten deals stacked in Won and nothing in Lost. A kanban column that only grows is a list wearing a board’s clothes. Won should archive into Subscriptions, not sit there.
The empty states carry more design attention than the full ones. A studio with two hundred bookings has never been in front of me, so I have designed for the first day and not the thousandth.
Where it stands
Two products live, the platform rolling out, and adding the next one is closer to configuration than construction.
slow start, compounding returnAxion and Aurix are live products; the unified DHRUVIX platform is rolling out, design system and control-plane data model shipped, with identity and billing in progress.
Because the foundation is shared, adding the next product is closer to configuration than construction.