What Building Arjun Pathshala in Days Taught Us About Our Own Stack
A second brand, a different language, a completely different visual identity — shipped without a new deployment, a new codebase, or a single new piece of infrastructure. Here's what actually made that possible.
Arjun Pathshala is a completely separate brand from Ekya Tech — a JEE/NEET mentoring program with its own maroon-and-gold identity, its own bilingual (English/Hinglish) toggle, its own blog, its own founder page, nothing visually shared with the parent site. It launched in days, not months, and it runs on the exact same Next.js app, the exact same Vercel project, and the exact same git repository as ekyatech.com itself. No new deployment target. No new hosting setup. No new DNS beyond pointing a path at the existing domain.
That wasn't an accident, and it's worth being specific about what actually made it possible, because "our stack is flexible" is the kind of thing every agency says and almost none of them can point to a real example of.
The chrome had to become conditional, not duplicated
The hardest problem wasn't styling — it was that the root layout unconditionally wrapped every page in Ekya Tech's navbar and footer. Arjun Pathshala needed none of that. Rather than forking the layout or standing up a second app, the fix was a single conditional wrapper that checks the route and renders either the shared site chrome or nothing, letting each brand's own pages control their own header. One small architectural decision — chrome as a conditional component, not baked into the root layout — is the difference between "add a brand" being a real engineering project and being an afternoon's work.
Design tokens scope correctly when you don't hardcode them
Ekya Tech's blue-and-purple brand colors live as CSS custom properties. Arjun Pathshala needed maroon and gold instead — a completely different palette, different typography pairing (a serif display face instead of the parent site's sans-serif), different motion feel. Because the color system was already tokens rather than colors hardcoded into components, a second brand meant defining a new token scope, not rewriting the components that consume them. The same animation component, the same layout primitive, the same button and card patterns work for both brands, rendering completely differently, because they were never coupled to one specific palette in the first place.
SEO infrastructure that's a function, not a page-by-page chore
Structured data (JSON-LD), sitemap generation, and metadata — title, description, Open Graph, canonical URLs — already existed as reusable functions rather than hand-written per page. Standing up a second brand's SEO wasn't rewriting any of that; it was calling the same metadata helper and the same breadcrumb/FAQ schema generators with different inputs. The blog itself is the clearest example: the same content type, the same post-rendering component, and the same listing-page pattern all existed once and got reused for Arjun Pathshala's blog with a second, separately-themed rendering pass — not a second system built from scratch.
What this actually means if you're evaluating a vendor for your own second product or brand
The real test of whether a codebase is reusable isn't whether the first thing you built from it looks good. It's whether the second thing — a different brand, a different audience, a different language, launched under real time pressure — takes days of composition instead of weeks of rebuilding. That's not a claim we're making about our stack in the abstract. It's what actually happened with this specific launch, on this specific infrastructure, which is the only kind of proof that means anything.
If you're building a product that might need a second brand, a second language, or a second audience down the line, talk to us about how we'd structure it — the architecture decisions that make that cheap later have to happen on day one, not when you actually need them.