I kept moving closer to the problem.

2010–2020

From making pages to designing products

I started my career at Elves Technology in 2010 as a web designer. My tools were Adobe Photoshop and Dreamweaver. Often, I would receive little more than a client’s visiting card and be expected to turn it into a complete website: the words, the images, the interface, and the final build.

Even as my roles became more design-heavy, I kept making websites with tools such as Sublime Text. I enjoyed visual design, but I was more interested in why something worked: how information was structured, what people were trying to do, and where an experience became confusing. That interest pulled me deeper into UX.

At Synechron, I pushed my team to move from Photoshop to Sketch. Later, as the industry debated Adobe XD and Figma, I argued for Figma. I even earned an Adobe XD certification despite never particularly liking the tool. Eventually, client work made Figma unavoidable.

The tool debate was never really about tools. I was looking for a better way for designers and engineers to work together. Design systems were inconsistent and often stopped at the design file. I wanted to understand how the interface, the code, the documentation, and the team could operate as one system. My years at Synechron and Globant helped turn that curiosity into a product-design practice grounded in research, structure, and collaboration.

2021–2022

When design became business

Bajaj Finserv changed the scale of the problems I was solving. I was no longer only a UX designer, UI designer, or visual designer. I was a lead responsible for a team of UX designers, UI designers, and UX writers.

That team became my responsibility and, in many ways, my family. I had to hire people, approve leave, manage conflict, create opportunities, protect the quality of our work, and help people grow. My work was no longer contained inside a screen. It moved into boardrooms and conversations with product, design, engineering, operations, legal, and business leadership.

Working at Bajaj felt like doing an MBA while getting paid for it.

Everything my team designed had a business goal behind it. That experience taught me to connect user experience with organizational reality: incentives, risk, operations, revenue, and the difficult work of getting many groups to move in the same direction.

2022–2024

From design systems to production systems

At Zeni AI, I had the chance to use that business understanding while staying close to the craft. I also found the best working relationship of my career. My manager and I collaborated like musicians jamming: sharing an idea, trying it, challenging it, and making it better together.

We experimented with Figma Enterprise, built a design system connected to Storybook, and explored how design decisions could survive the journey into code. I was leading a team, but I was also becoming more interested in the space between product design and engineering. A design system was only real when designers and engineers could use the same decisions in the product customers received.

2024–2025

Becoming a founder

In October 2024, I went against advice I had believed for years: only start a business in a field where you have experience or an unfair advantage. I started Order.law, a legal research and case-management product, without either.

It was difficult. Progress often felt like one step forward and five steps back. I had to learn legal workflows while working across product strategy, research, UX, visual design, front-end development, API integration, marketing, and SEO.

In September 2025, we started using Codex in our development workflow. I built and shipped the first version of our public website in weeks. AI-assisted development changed what our small team could attempt, but speed alone was not enough. Without discipline, the code and the decisions could quickly go in every direction.

We scaled down to a two-person team and adopted specification-driven development. We wrote down what we intended to build before building it. We introduced MCP-based workflows to preserve context, document decisions, and repeat important tasks using the same rules. The goal was not simply to generate more code. It was to build a product we could still understand and maintain.

The lesson

What Order.law taught me

Order.law did not achieve the business goals we had set for it. We built a product I still believe in, but building the product and building a sustainable business were two different jobs. Dividing my time between product development, founder-led sales, and closing customers was harder than I had expected.

What did work was our writing, SEO, and marketing. People found the work and began approaching me to ghostwrite for founders and leaders. Companies asked me to help with their websites and marketing. Nearly all of it was inbound. The work that brought people to us was also the work that helped pay the bills.

The lesson was uncomfortable but clear. A strong product does not automatically become a strong business. My best path to growth was not pushing people through an outbound sales process. It was making useful things, explaining them clearly, and earning enough trust that people wanted to work with me.

Now

Why I’m building Overhyped

Overhyped grew from that lesson. It gave me an unusual opportunity: learn the discipline more deeply, solve real marketing and website-visibility problems for paying customers, and turn repeated work into a product.

Today, I am building Overhyped across product strategy, design, front-end engineering, SEO, AEO, writing, and client delivery. The work brings together everything I learned before it: making websites, understanding users, leading teams, connecting design to code, reading business constraints, and telling a clear story.

We continue to maintain Order.law. It still has potential, even if it is not yet paying the bills. I do not see that journey as wasted time. It taught me how to build beyond the boundaries of a traditional product-design role and how to listen when the market values something different from what I expected.

The tools have changed. The instinct has stayed the same: understand the problem, make it clear, and build something useful.