I didn't design 100 apps. I designed the system that made them possible.
When Freshworks bet on becoming a one-stop platform with 100 third-party integrations in 100 days, the experience was already fragmenting before we'd shipped 10. This is how I stopped it.
What I walked into
Freshworks, the first Indian SaaS company on NASDAQ, had an ambitious bet: become the one-stop platform for every support agent's workflow. Not just tickets and chat. Shipping, payments, CRM lookups, productivity tools. All inside one product. The 100 Apps initiative was how they'd get there: 100 third-party integrations, in 100 days.
When I joined, a handful of integrations had already shipped. They worked technically, but the experience was chaos. The same action, tracking a shipment, looked and behaved completely differently depending on which carrier's integration you were using. Agents switching between FedEx, UPS, and DHL had to relearn the interface each time.
Each integration was owned by a different PM, built by a different team, moving on a different timeline with no shared system, no design language, no consistency.
"Without intervention, we'd ship 100 integrations and create 100 different ways to confuse the same agent."
100 integrations across four verticals, each with its own product owner, engineering constraints, and stakeholder expectations.
| E-Commerce | 28 integrations |
| Non-vertical | 54 integrations |
| Travel & Hospitality | 11 integrations |
| BFSI | 7 integrations |
The moment I became the bottleneck
Before I could fix the product, I had to be honest about something uncomfortable. The way I was working was making the problem worse.
I tracked how I was actually spending my time:
Every integration needed review. Every PM wanted input on their use case. Every developer had questions. I was the single point of failure in a system that needed to move at speed, and the way I was working was guaranteeing the fragmentation would continue.
I had 4–5 days per integration including design, review, and handoff. Whatever the solution was, it couldn't require more time per integration. It had to require less.
The only exit was upstream. Stop solving at the screen level. Solve at the system level.
The two weeks nobody wanted
I proposed stopping the sprint for two weeks to build a structural framework every integration would live within so that we could still hit the quarterly goal if we moved fast after.
6 PMs. Each with their own roadmap and their own stakeholders. Each being told by a designer that their sprint was pausing. The pushback was immediate.
I made my way through by showing the business cost, not by arguing design quality. I pulled up two integrations from the same vertical, shipping, and walked them through the flows side by side. Identical use case. Completely different interaction patterns. Then I showed the VQA data: 40+ review iterations per integration because nothing shared a foundation.
"The question quickly shifted from 'can we afford to pause?' to 'can we afford not to?'"
And so we paused.
I stopped designing integrations and started designing the container they'd all live within.
The framework I came up with:
Standardise the container. Leave the content flexible.
Every integration has the same header structure, same footer with primary actions, same component library in the body. What changes is the content inside, but where to look and how to act is always identical.
The two weeks I fought for saved months of irreversible debt.
From bottleneck to quality gate
Something unexpected happened after the framework was built. The constraint that felt like a pause became an accelerant. I could review 10 integrations in the time it used to take me to design one.
Developers started helping each other. Because every integration used the same structure and components, code became reusable across integrations. PMs aligned faster because there was a reference structure to point to. The framework didn't just solve the current sprint. It changed how the entire team worked together.
Design is about creating leverage
This project reinforced something I hadn't fully articulated before. When you're the sole designer across a large, fast-moving initiative, designing individual screens is the wrong level of abstraction. The real work is building systems and frameworks that multiply the impact of everyone around you.
The bottleneck wasn't my output. It was the structure I was operating within. Once I changed the structure, everything else changed with it.
The question I ask at the start of every complex project now: where's the leverage point? What's the one thing, if I get it right, that makes everything else easier?
In this case, the leverage point wasn't a better component or a more thorough design review. It was a shared container, a structural decision that made a hundred individual decisions unnecessary. That's the work worth doing.