Arathi Pallath

Arathi Pallath

I didn't design 100 apps. I designed the system that made them possible.

I didn't design 100 apps. I designed the system that made them possible.

Somewhere around integration 12, I realised we were building a problem faster than we were building a product. Here's what I did about it.

Somewhere around integration 12, I realised we were building a problem faster than we were building a product. Here's what I did about it.

Product Designer
Product Designer
App Integrations
App Integrations
Enterprise SaaS
Enterprise SaaS
0 → 1 Framework Design
0 → 1 Framework Design
0 → 1 Framework
Rapid timeline · 100 apps in 100 days
Rapid timeline · 100 apps in 100 days
Company
Freshworks
Products
Freshchat
Freshdesk
Team
Product Managers
6 Product Managers
Frontend Engineers
Multiple Engineering teams
Support platform teams
Challenge
Freshworks launched an ambitious initiative to build 100 third-party integrations in 100 days, expanding support workflows beyond tickets and chat. As integrations shipped, experiences began fragmenting rapidly. Similar tasks behaved differently across integrations, creating inconsistency for users and increasing design, engineering, and review overhead. Without intervention, the initiative risked scaling complexity faster than customer value.
What I owned
I was the sole designer supporting the initiative, responsible for creating a scalable framework that could support rapid integration development while maintaining a consistent user experience.

  • Identified systemic UX fragmentation across integration experiences

  • Audited shipped integrations and uncovered scaling risks

  • Reframed the challenge from individual integration design to platform consistency

  • Built a reusable structural framework for future integrations

  • Aligned 6 PMs and multiple engineering teams around a shared model

  • Defined reusable patterns, layouts, and interaction structures

  • Established scalable review and governance processes

  • Reduced design bottlenecks across the initiative

Project complexity
  • 100 integrations in 100 days (rapid delivery timeline)
  • Sole designer across the initiative (single point of design ownership)
  • 6 PM workstreams (different priorities, roadmaps, and requirements)
  • Multiple engineering teams (parallel implementation across teams)

  • Cross-functional alignment challenge (required pausing active development to establish foundations)

Impact
  • Reduced design review effort through reusable framework patterns
  • Decreased visual QA cycles by creating a shared foundation
  • Enabled faster integration delivery without sacrificing consistency
  • Increased reuse across design and engineering teams
  • Established a scalable system adopted across future integrations
  • Transformed design from a delivery bottleneck into an organizational multiplier
Challenge
Freshworks launched an ambitious initiative to build 100 third-party integrations in 100 days, expanding support workflows beyond tickets and chat. As integrations shipped, experiences began fragmenting rapidly. Similar tasks behaved differently across integrations, creating inconsistency for users and increasing design, engineering, and review overhead. Without intervention, the initiative risked scaling complexity faster than customer value.
What I owned
I was the sole designer supporting the initiative, responsible for creating a scalable framework that could support rapid integration development while maintaining a consistent user experience.

  • Identified systemic UX fragmentation across integration experiences

  • Audited shipped integrations and uncovered scaling risks

  • Reframed the challenge from individual integration design to platform consistency

  • Built a reusable structural framework for future integrations

  • Aligned 6 PMs and multiple engineering teams around a shared model

  • Defined reusable patterns, layouts, and interaction structures

  • Established scalable review and governance processes

  • Reduced design bottlenecks across the initiative

Project complexity
  • 100 integrations in 100 days (rapid delivery timeline)
  • Sole designer across the initiative (single point of design ownership)
  • 6 PM workstreams (different priorities, roadmaps, and requirements)
  • Multiple engineering teams (parallel implementation across teams)
  • Cross-functional alignment challenge (required pausing active development to establish foundations)
Impact
  • Reduced design review effort through reusable framework patterns
  • Decreased visual QA cycles by creating a shared foundation
  • Enabled faster integration delivery without sacrificing consistency
  • Increased reuse across design and engineering teams
  • Established a scalable system adopted across future integrations
  • Transformed design from a delivery bottleneck into an organizational multiplier
Executive Summary
Executive Summary

What I walked into

What I walked into

100 integrations. 100 days. Every PM had a different vision. The experience was already fragmenting before we'd shipped 10.

100 integrations. 100 days. Every PM had a different vision. The experience was already fragmenting before we'd shipped 10.

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

I was the sole designer across the entire initiative.

Working simultaneously with 6 PMs and multiple engineering teams, each moving at their own pace with their own constraints.

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.

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.

And so I thought, "without intervention, we'd ship 100 integrations and create 100 different ways to confuse the same agent."

And so I thought, "without intervention, we'd ship 100 integrations and create 100 different ways to confuse the same agent."

Each integration was owned by a different PM, built by a different team, and was moving on a different timeline, with no shared system, no design language, no consistency.

Each integration was owned by a different PM, built by a different team, and was moving on a different timeline, with no shared system, no design language, no consistency.

01 · The Problem
01 · The Problem

The moment I became the bottleneck

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.

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:

I tracked how I was actually spending my time:

60%

Requirement alignment meetings and slack across 6 PMS

30%

Visual QA catching implementation inconsistencies

10%

Actually designing

Every integration needed review. Every PM wanted input on their use case. Every developer had implementation 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.

Every integration needed review. Every PM wanted input on their use case. Every developer had implementation 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.

The only exit was upstream. Stop solving at the screen level. Solve at the system level.

The only exit was upstream. Stop solving at the screen level. Solve at the system level.

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

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

I stopped designing integrations and started designing the container they'd all live within.

I stopped designing integrations and started designing the container they'd all live within.

02 · Reframing The Problem
02 · Reframing The Problem

The two weeks nobody wanted

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.

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 and not by arguing design quality.

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

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.

The question quickly shifted from "can we afford to pause?" to "can we afford not to?" and so we paused.

03 · The framework
03 · The framework

Standardise the container. Leave the content flexible.

Standardise the container. Leave the content flexible.

Every integration had 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.

Shared structure

Header
Content zones
Action areas
Loading states

Flexible content

Intergration specific workflows
Custom data
API specific configurations

📍 The two weeks I fought for saved months of irreversible debt.

📍 The two weeks I fought for saved months of irreversible debt.

04 · The outcome
04 · The outcome

From bottleneck to quality gate; I could review 10 integrations in the time it used to take me to design one.

From bottleneck to quality gate; I could review 10 integrations in the time it used to take me to design one.

Something unexpected happened, after implementing the framework.

Something unexpected happened, after implementing the framework.

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.

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.

15 · Reflection
15 · Reflection

What I carry forward

What I carry forward


The biggest lesson for me wasn't about design systems / frameworks. It was recognizing when a team is scaling inconsistency faster than value. Once I saw that pattern, the most impactful thing I could do wasn't design another integration, it was change the way integrations got designed. 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?


The biggest lesson for me wasn't about design systems / frameworks. It was recognizing when a team is scaling inconsistency faster than value. Once I saw that pattern, the most impactful thing I could do wasn't design another integration, it was change the way integrations got designed. 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?

Create a free website with Framer, the website builder loved by startups, designers and agencies.