Building Zomato’s Web Platform Team

How I built a cross-functional web platform team while replacing a legacy frontend.

Mar 29, 2025

When I was asked to rework Zomato.com’s frontend, the mandate had two parts: replace a decade-old monolith serving millions of users and build the team that could own the replacement. On day one, it was me, two engineers fresh out of college, a large legacy codebase, and no hiring plan. Eighteen months later, 21 engineers owned web, backend, infrastructure, security, and parts of the data stack. This is what worked for us, not a general hiring or architecture playbook.

Starting from Zero: A Daunting Challenge

Initially, Zomato’s frontend was a PHP monolith with jQuery mixed into backend-rendered UI. It had served us well, but page performance and change risk were getting worse. There was also no dedicated frontend team: UI work was spread across backend engineers and people contributing to frontend systems when they had time. No group owned the web experience end to end.

I spent the first week reading the code and talking to the people who depended on it. The immediate need was not a particular framework. It was a team that could own ambiguous problems while gradually replacing pieces of a running system.

We kept three operating rules: time-box work, prioritize the small number of frontend problems users felt most, and let team boundaries follow system boundaries. The third rule came from Conway’s Law: if we wanted independently deployable parts of the product, we needed teams with clear ownership and interfaces.

That was enough process for the first phase. The next problem was hiring people who could learn the missing parts of the system without waiting for a perfect specification.

Hiring Differently: Building a Team of Problem Solvers

To build the 21-person team, I conducted more than 150 interviews over a year. We were not only looking for React or CSS experience. We asked candidates to explain the hardest problem they had solved and how they had approached it.

The answers ranged from hackathon projects and production incidents to non-technical problems such as organizing disaster-relief logistics. The problem itself mattered less than the reasoning: how they found the constraint, made trade-offs, and learned what they did not know. A resume full of current keywords was not useful if the candidate could not describe work they had actually owned.

We also asked what candidates had taught themselves recently. One backend engineer with little JavaScript experience described how he had learned AppleScript to automate office work. His system-design reasoning was strong, so we hired him for the frontend team. A year later he was contributing to the build system and machine-learning data pipelines. We could teach React and TypeScript; curiosity was harder to add later.

The team developed a recognizable habit: people brought problems together with possible approaches, even when they did not own the area. That mattered more than a carefully designed culture program because it changed the way decisions were made every day.

Cultural Cornerstones: Laws We Lived By

As the team grew, we turned those rules into everyday habits:

• When a project estimate stretched to three months, we split it into smaller releases and asked what could be tested in six weeks. The shorter loop made it easier to change direction without creating a large unfinished project. We used the same rule for meetings: if a decision could happen in 30 minutes or in a Slack thread, we did not schedule an hour.

• In retrospectives, we asked whether we were working on the highest-impact problem. During the orders rebuild, a change to the order relay and image caching improved load time before the larger redesign was ready. We shipped that smaller improvement first and kept the redesign separate.

• We started by swarming on everything. Once the team was large enough, we created small cross-functional groups around areas such as infrastructure, security, orders, and the design system. Each group owned a vertical slice and communicated through explicit interfaces. That kept the organization from recreating the monolith we were trying to remove.

• We made it safe to question old assumptions. Several engineers, including me, had to replace inheritance-heavy habits with composition when we moved to React. A senior engineer who had spent years optimizing PHP templates had to learn a different model when we moved to a Node rendering engine.

That also meant dropping tools when they became a constraint. We replaced a CSS-in-JS library with Tailwind when it slowed our builds. We used Go, PHP, Python, and JavaScript where each fit instead of forcing one language across the system.

Bold Tech Bets: From Legacy to Cutting-Edge

Replacing the legacy system gave us room to change the architecture, but every new tool still had to solve a real problem. These were the decisions that lasted:

• Microfrontend architecture: We split the product into independently owned areas such as Ads Studio, Orders, Insights, Menu, Restaurant Pages, and the Homepage. Module Federation and shared integration code let teams deploy separately while keeping the experience coherent. The cost was real: shared design, state, and release coordination needed explicit ownership.

• Frameworks: We used React and TypeScript for new UI, then chose Next.js, Remix, or Astro by page requirements. Some microfrontends used Next.js until we replaced it with a custom rendering engine. Multiple frameworks added coordination cost, so common design, authentication, and integration practices mattered more than framework uniformity.

• Build tooling: We moved some products from Webpack to Vite for local development and adopted Rspack for the largest microfrontend. Build time fell by roughly 70% there, which made smaller changes cheaper to test.

• Custom rendering engine: As microfrontends and server-side rendering grew, we needed more control over streaming and caching. Two engineers built a Node.js renderer for the critical pages. It is still a bet, but it addressed a concrete limitation in the standard setup rather than adding another framework for its own sake.

The team learned new systems by doing the work, then sharing what it learned. Engineers ran short internal sessions after trying a new tool or pattern. That made it possible to take on Remix, Rspack, and model-training work without waiting for a formal training program.

Ownership made the work visible

As the site became faster and more reliable, the team could see the effect of its work. We shared those results publicly inside the company, so a win by one group became useful context for the others.

One intern built an RSC-based page within a week of its announcement while keeping load time sharp. Another engineer used that same habit of experimentation to profile our PDF rendering service and build a faster replacement, later open-sourced as Espresso. The useful part was not competition for credit. It was seeing a working example and trying the next thing.

We also owned more than “frontend code.” Backend performance, deployment pipelines, and authentication affected the web experience, so the team worked across those boundaries instead of waiting for handoffs. That added responsibility, but it also gave engineers enough context to make better decisions.

That ownership made the team easier to collaborate with. Other groups started asking for help on performance, frontend architecture, and cross-functional projects because they knew who could make an end-to-end decision.

A team identity, used carefully

We jokingly called ourselves pirates after I sent the team a “Move Fast, Be Audacious” poster. The label was useful only because it gave the group a shared shorthand for curiosity, directness, and helping one another. It was not a license to ignore safety or process.

That identity showed up in a few habits:

• Learning & Unlearning: Pirates don’t attend formal training; they learn on the seas. Similarly, we learned by doing. When we needed to implement something like, say, a new data transfer protocol for payments on the frontend, instead of handing it off to a “security team,” one of our engineers took the lead to become the in-house expert on it, learning directly from external resources and the security folks. In turn, he taught the rest of us the dos and don’ts. We became generalists when needed, specialists when needed – fluid in roles.

• Bold Bets: We weren’t afraid to bet on new technology or a radical approach if we believed in it. Some bets failed (we tried a NoSQL solution for a particular data store and later reverted to relational when it proved too complex), but no one was blamed for trying. The trust level was high: I had my team’s back, and they had each other’s. We’d rather try and occasionally fail than stagnate. It’s very much a pirate attitude – sometimes you sail into uncharted waters; sometimes you hit treasure, sometimes you hit a storm. But the journey itself makes you stronger and smarter for next time.

• Camaraderie and Fun: Importantly, we had fun along the way. War rooms in our team felt like pirate adventures. Once, while working on a particularly challenging bug that was affecting our SEO (search engine index issue due to SSR glitch), a few of us camped in the office late, ordering pizza, blasting music. We fixed the bug by 2 AM, high-fived, and even raised an imaginary pirate toast with our soda cans. These silly little cultural moments – in-jokes, codenames (BTW, naming things is hard!), celebrations – made the grind enjoyable. It created a strong bond. We knew we could count on each other when things got tough.

By cultivating this “small community of pirates” vibe, we inadvertently also crafted a team brand that attracted talent. People in the organisation (and even friends of friends outside) heard that “the Zomato frontend team is doing some cool stuff”. We started getting referral candidates who specifically wanted to join our team because they’d seen us speak at some meetups and conferences or share tech blog posts. In essence, our culture became a magnet for like-minded builders. This kind of organic employer branding is gold – it’s far more genuine. And it feeds the flywheel:

What I would repeat

Looking back from one engineer to a 21-person cross-functional team, four decisions mattered most:

• Use principles before process. We started with ownership, learning, and impact. Process followed once the team had real problems to solve.

• Hire for problem-solving range. The strongest hires were not always exact skill matches. They could explain how they learned, what they tried, and where their approach failed.

• Cross-Functional Ownership is Powerful. Blurring the lines between “frontend” and “backend” or between roles helped us go faster and build better. Developers who understand the product and a bit of design, designers who peek at code, frontend folks who aren’t afraid of database queries – those overlaps created empathy and sped up execution. We became a true cross-functional unit that could deliver end-to-end, which meant less handoff and more autonomy. Conway’s Law went from a cautionary tale to a tool in our toolkit – we designed our team structure intentionally to produce the architecture we wanted, and it worked.

• Innovation thrives with Trust and Safety. We achieved some pretty cool innovations (like our custom rendering engine or adopting cutting-edge frameworks early) because team members felt safe to propose crazy ideas and run with them. There was psychological safety to fail, which paradoxically led to more big wins. When engineers don’t fear blame, they focus on possibilities. We made sure to treat failures as learning, not as something to hide or punish. As a result, people were proactive in pushing boundaries.

• Pride and Team Brand Matter. A team identity can be useful when it is rooted in real work. We demoed internally, celebrated each other’s achievements, and shared parts of the journey externally through posts and meetups. That helped people understand what the team cared about and why the work mattered.

• “Unlearn and Upskill” as a Lifestyle. Perhaps the biggest takeaway for me personally is seeing the power of continuous learning. Some of the technologies our team uses daily didn’t even exist or weren’t mainstream when we started. By embracing “unlearn and upskill” as a core value, we future-proofed our team. It’s a mindset that keeps us adaptable. As a manager, I learned that my job isn’t to have all the answers, but to create an environment where the team can discover answers – to remove roadblocks, provide context, and then get out of their way. Many times I found the best thing I did was not interfere too much, but rather trust the talented people I hired to figure it out (and they did!).

The frontend changed from PHP and jQuery to React, TypeScript, microfrontends, and a custom renderer. The harder change was organizational: give small groups enough context and ownership to make end-to-end decisions, then let them learn across the boundaries the old system had created.

Although we call ourselves pirates (🏴‍☠️), I don't know when we naturally adopted a 2-D Viking as our team symbol. It exists everywhere, from our desks (name cards) to laptops (stickers and wallpapers), even as Easter eggs in some internal tools we have built. We've retained the Viking because most of us liked it.