DHRUVIX

DHRUVIX is a multi-product B2B SaaS company: one brand, one design system, one identity layer - six products plus a platform control plane, each deploying independently.

I lead it as Product Designer & Architect, owning the platform strategy, the multi-tenant data model, the design system, and the engineering direction.

The core bet: instead of rebuilding authentication, billing, role-based access, and theming separately inside every product, collapse them into one shared foundation that all products consume.

This is a systems problem before it is a screens problem.

Each vertical product - Axion (studio & agency invoicing), 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 six auth systems, six billing integrations, six permission models, and six design languages - and six places for a security or tenant-isolation bug to hide.

• 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

I structured DHRUVIX as three layers: a platform control plane, the tenant-facing products, and a shared foundation they all build on.

Tenant isolation is a rule, not a convention. Every tenant-scoped query filters by organization_id, with Postgres row-level security as the database-level backstop - so a single forgotten filter can’t leak one customer’s data to another.

The hierarchy is Organization → Workspace/Shop → User, and plan entitlements decide which products and features each organization can reach.

• organization_id on every tenant-scoped row
• Row-level security as the backstop, not app logic alone
• Entitlements gate product + feature access
• Identity centralized - products never re-implement auth

One design system gives six products a coherent feel while letting each keep its own identity.

It’s a three-layer token architecture: primitives (Layer 1) → semantic tokens (Layer 2) → components. App code reads semantic tokens only, never raw hex - so a product can re-skin by swapping its accent without touching component code.

• 3-layer token architecture (primitive → semantic → component)
• Per-module accent over a shared neutral base (“Axion Coral” anchor)
• shadcn components built entirely from tokens
• No raw hex in product code - enforced by convention + lint

Before migrating two existing products (Axion on Firebase, Aurix on Postgres/Prisma) onto the platform, I audited their codebases for SaaS readiness - not as a designer reviewing screens, but reading the actual data layer, auth flow, and security rules.

I graded nine areas - multi-tenancy, identity/SSO, subscriptions, feature flags, usage limits, billing, RBAC, audit logs and admin separation - each with status, affected files, effort sizing, and a prioritised top-five fix order.

The audit surfaced production-grade risks early: world-readable/writable database rules and query-level tenant-leak paths - caught before any second customer was onboarded.

AplaFund is the sixth product and the one that tested the platform hardest. It manages a co-operative savings group: eleven members, monthly share deposits, small loans, and a meeting where the register is read out loud.

The users are not SaaS users. They are members of a fund in a village, and the thing I was replacing was a paper register that everyone already trusted. A screen has to earn that trust back.

So the interface is bilingual end to end - Marathi and English on every label, not a translation layer bolted on. The month runs as a four-step cycle the group already recognises: payment window, tally, meeting, lock. I did not invent that sequence; I found it and stopped fighting it.

• Bilingual by construction - no fixed-width labels anywhere
• Amounts stay in Latin numerals; translating digits helps nobody
• Language toggle is A/अ, not a flag - one village, not two countries
• The month locks. An immutable record is what a register is for.

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.

Axion 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.