A unified design language built solo in 3 months — covering tokens, 50+ components, icons, and documentation. Now powering all 5 apps at AppsForBharat.
AppsForBharat runs 5 consumer apps, each built and designed independently. With 6–8 designers working across products, there was no shared visual language — buttons had different corner radii, type scales varied, and colour values were duplicated with slight inconsistencies. Every new screen started from scratch.
Developers were constantly asking for specs on components that had been built dozens of times before. Onboarding a new designer meant weeks of absorbing undocumented conventions. The brand felt fragmented to users, even if they couldn't name why.
"There was no single source of truth. Each app had its own button, its own definition of what 'primary' meant."
Before designing anything, I conducted a full UI audit across all 5 apps — cataloguing every unique button style, colour value, spacing unit, and type style in use. The number was revealing: it gave me a clear mandate and helped me prioritise which inconsistencies caused the most friction.
I spoke with developers to understand what slowed them down most in handoffs. I spoke with designers about what they copy-pasted between files. Their answers shaped every structural decision in Tatva.
↑ Three apps, three different primary button styles — same company
The core insight behind Tatva's architecture: every app shares the same structure, but carries its own identity. Primitive colour ramps are defined once. Semantic tokens map roles to primitives. Each app then aliases those roles to its own brand palette — meaning a single component works across Sri Mandir, Khatu, Super Astro, and Daily Mantra with zero duplication.
This architecture means Primary Surface resolves to Saffron-50 in Sri Mandir, Divine Rose-50 in Khatu Light, and Cosmic Blue-50 in Daily Mantra — the same token, five brand expressions, zero duplication.
A unique challenge across AppsForBharat apps: all content exists in both English and Hindi. The type system had to work bilingually — same weight scale, same size ramp, different script. This was a deliberate architectural decision, not an afterthought.
Bilingual type system supporting English and Devanagari script across all 5 apps
Each component in Tatva ships with a full property matrix — Type, State, Size, and Content — configurable as Figma variants. One component covers hundreds of combinations. Developers consume the same structure via code tokens. No guesswork on either side.
It suddenly increased in the last few weeks
It suddenly increased in the last few weeks
Every element here is a Tatva component — the Popular badge, Prasad for Home tag, price block (₹450 ₹555 Save 20%), the bilingual CTA button (चुनें), and the 20k social proof footer. One consistent system across all 5 apps.
Sri Mandir app — all screens built with Tatva components, Devanagari script rendered natively via the bilingual type system
Getting 6–8 designers and their respective engineering teams to adopt a new system — especially one built by a single person without top-down mandate — required more than great documentation. It required trust.
With designers: I ran working sessions where I built screens alongside teammates using Tatva components — making it feel like a tool, not a constraint. I also made it easier to use Tatva than to go off-system, by keeping the library close to real product patterns rather than theoretical ideals.
With developers: I showed engineers how code tokens would reduce their own rework — not just ours. Once they saw that a button change wouldn't require hunting through 5 codebases, they became advocates.
Deciding scope: A design system that tries to solve everything solves nothing. I made explicit, documented decisions about what Tatva would and wouldn't cover in v1 — and why. This kept the system lean and credible.
After Tatva was adopted across all 5 apps, the results were measurable — across handoff speed, consistency, and team onboarding.
I'd involve engineers earlier — even in the token naming phase. The vocabulary designers use and the vocabulary developers use don't always match, and that gap costs time downstream. I'd also establish a versioning and contribution model from day one, rather than retrofitting governance onto a system that had already shipped. A design system without a contribution model is a single point of failure.