Building Zomato's Thriving Pirate Community

When I was first asked to evaluate and reimagine Zomato.com’s frontend, I felt equal parts excitement and dread. The mandate was clear: take a decade-old legacy monolith and transform it into a modern, scalable system serving millions of daily users – and build a team from scratch to do it. On Day 1, it was just me, two engineers fresh out of college, a pile of legacy code, and a blank hiring plan. One and a half years later, I look around at a 21-person strong engineering team that not only rebuilt the web frontends via microfrontends, but evolved into a full-stack, cross-functional unit handling everything from infrastructure and security to backend, machine learning, and product – end to end. Even more gratifying, we have zero attrition to date (100% retention), a rare feat in our industry. This is the story of how we got there – the principles we embraced, the culture we fostered, the tech choices we made, and how a scrappy “small community of pirates” went from one overwhelmed engineer to a proud engineering culture. It’s not a how-to manual, but rather a personal journey of what worked for me.

Starting from Zero: A Daunting Challenge

Initially, Zomato’s frontend was a classic monolith – a PHP codebase rendering UI with jQuery sprinkles, tightly coupled to backend logic. It had served us well, but then it was creaking under the weight of new features and the expectations of modern web users. Slow page loads, difficulty in maintaining code, and an inflexible architecture were holding back innovation and delivering sub par UX. To make things harder, there was no dedicated frontend team in place. Most UI changes were handled by backend engineers or folks writing frontend systems out of hobby, with no single group “owning” the web experience. So when I was put in charge of fixing this, it truly felt like being handed the keys to an old ship and told to rebuild it mid-voyage.

I spent my first week combing through the code and talking to colleagues to chart a path forward. One thing was obvious: we needed to build a team – not just any team, but people who could think big and tackle ambiguous problems. This wouldn’t be a simple upgrade; it was a fundamental rebuild. We’d have to gradually replace parts of the plane while flying it, and simultaneously build a crew capable of flying and fixing that plane together.

But before diving into hiring, I wanted to set some ground rules for how we’d operate. In those early days of planning, I pinned a few famous “laws” on my desk as guiding principles for our nascent team:

• Parkinson’s Law: Work expands to fill the time available (How to overcome Parkinson's Law). This was a reminder that we needed to stay lean and time-boxed – long timelines or bloated processes could lead to wheel-spinning. We opted for short sprints and aggressive (but realistic) deadlines, forcing us to focus on what mattered and deliver incrementally rather than letting tasks swell endlessly.
• The Pareto Principle (80/20 Rule): 80% of outcomes often come from 20% of causes (Pareto principle - Wikipedia). With a tiny team (initially just me, and soon 2 early hires), we had to prioritize ruthlessly. We identified the 20% of frontend issues causing 80% of user pain – like page load times and mobile web glitches – and attacked those first. This not only maximized our impact early on, but also won credibility and buy-in from leadership for our bigger plans.
• Conway’s Law: Organizations design systems that mirror their communication structure (Conway's law - Wikipedia). I took this to heart in designing our future team and architecture. If we wanted a modular, decoupled frontend system, we needed to avoid a monolithic team. Instead, as we grew, I envisioned small cross-functional squads owning different areas, communicating via clear interfaces – exactly how we wanted our software components to interact. In essence, we planned to organize for the architecture we aspired to. Conway’s Law would work for us, not against us.

There were other mental models we kept in mind too – Brook’s Law warned that simply adding more developers to a late project could make it later, so we paced our hiring deliberately (no massive hiring sprees that would overwhelm onboarding). Hofstadter’s Law (“it always takes longer than you expect, even when you take into account Hofstadter’s Law”) gave us a sense of humor when estimating projects – a healthy acknowledgement that some unknowns would bite us. And of course, a dose of Murphy’s Law kept us cautious: if something can go wrong, assume it might. We built in feature flags and fallbacks for releases, knowing the chaotic nature of large-scale consumer apps.

These principles weren’t just posters on desk – they influenced how we structured meetings, how we set OKRs, how we approached writing our first lines of code in the new stack. With a philosophy taking shape, the next step was finding people who resonated with it.

Hiring Differently: Building a Team of Problem Solvers

To build a 21-person team from zero, I conducted well over a hundred and fifty interviews in the span of a year. But our approach deliberately broke the mold of typical hiring playbooks. We weren’t just looking for React experts or CSS wizards – we were looking for builders and problem-solvers with the right attitude. In fact, one very important thing that we wanted to understand from resumes, cover letters or discussion was: “What’s the biggest, gnarliest problem you’ve solved, and how did you approach it?”

This question usually led to a story – and it was in those stories that I could see the gears turning in a candidate’s mind. We heard about hackathon projects done with zero budget, production incidents mitigated at 3 AM, tricky algorithmic puzzles cracked through persistence, or even non-tech problems like organizing disaster relief logistics. The content of the problem mattered less than the thought process and grit behind it. We deliberately gave less weight to resumes studded with famous or trendy keywords if the person behind them couldn’t passionately describe real challenges they had owned. In other words, we optimized for substance.

Our hiring process also emphasized culture and learnability. We’d have casual chats about tech trends or ask candidates to teach us something they learned recently. This helped identify the naturally curious “lifelong learner” types. One open-ended question we used was: “Tell me about something new you taught yourself in the last year.” The answers ranged from “I learned Rust by building a toy web server,” to “I took up assembling PCs,” to “I’m reading about machine learning to better understand the responsibilities of a data scientist.” What we looked for was a spark in the eye – that genuine excitement of someone who loves to learn, which told us they would thrive in a fast-changing environment.

Over time, as these individuals joined, our little group gelled into what felt like a small community of pirates within the company. We weren’t a formal navy, with rigid protocols – we were more like a crew on a shared adventure (a vibe even the leadership acknowledged). And indeed, this pirate ethos served us well. Pirates improvise, pirates are unafraid of the unknown, and pirates have each other’s backs. We prized those traits over any specific skill. If someone didn’t know a tool or a language, that was fine – could they learn it? If a new problem came up that no one had experience in, would they shy away or say “Arr, let’s figure it out!”? We sought the latter.

One particular hiring story stands out: We were interviewing a developer who had mostly backend Java experience, very little JavaScript. On paper, not a fit for a “frontend” role. But the way he dissected a system design problem in the interview – systematically, deeply, based on first principles and intuitions – caught our attention. He also mentioned he had taught himself AppleScript to automate some office tasks simply because it seemed fun. We took a chance and hired him. Fast-forward one year, and he became one of our most versatile engineers, contributing to everything from our custom frontend build system to some machine learning data pipelines. This reinforced for me that hiring for attitude and aptitude over specific experience can pay off big. You can teach React or TypeScript on the job; you can’t easily teach curiosity or resilience.

Our hiring approach – almost like assembling an expedition team – meant that by the time we hit ~10 people, the group had a distinct character. New, experienced hires would often say in their first week, “I’ve never worked with a team quite like this.” There was a palpable energy, a sense that we were part of something special. I remember during one of my one-on-one sessions, a new engineer said, “Everyone here talks about problems while offering a number of solutions and approaches. It’s addictive to walk into such sessions.” That comment became a point of pride.

Cultural Cornerstones: Laws We Lived By

As the team took shape, we doubled down on a culture that would enable transformation rather than resist it. We frequently invoked those early principles (sometimes half-jokingly) in our day-to-day work to reinforce the mindset:

• When planning a project, if someone suggested a 3-month timeline for an MVP, someone else would inevitably quip, “if we give ourselves 3 months, it’ll take more than 3 months. What can we deliver in 6 weeks instead?” We’d then often break the project into smaller phases. This allowed us to course correct quicker if things were not going as planned. It's easier to predict if you will read this sentence by next minute, but gets difficult to predict how much you read within a minute. This created a healthy impatience that kept our velocity high without burning out – a delicate balance. We kept meetings short and purpose-driven for the same reason; work shouldn’t expand to fill an hour meeting if it can be solved in 30 minutes or via a Slack message. (How to overcome Parkinson's Law)

• In sprint retros, we often reviewed if we were focusing on the right problems or getting lost in rabbit holes. “Is this one of the 20% tasks that will give 80% impact?” (Pareto principle - Wikipedia) If not, can we deprioritize it or find a simpler approach? For example, when rebuilding our orders module, we had grand plans for a perfect overhaul. But an 80/20 view showed that a quick improvement to the order relay mechanism and image caching would yield faster load times (a major win) without a full redesign immediately. So we did the quick wins first, saw a big performance gain, and tackled the redesign in parallel without time pressure. Focusing on high-impact changes first became part of our operational DNA.

• Initially, with a tiny team, we all swarmed on everything – not ideal, but unavoidable. As soon as we had enough people, we carved out mini-teams around key areas: e.g. one sub-team focused on the infra, one on platform security, on orders, on design systems, etc. Each squad was cross-functional – meaning it had a mix of skills (frontend, backend, maybe a design liaison) so they could own features end-to-end without heavy dependencies. This mirrored a microfrontend approach in architecture: each feature or section of the site would eventually be a semi-independent module, interfacing with others via clear APIs. By structuring “team = focus area,” we made sure our team chart wouldn’t force a new monolith. Instead, we’d have vertical slices of ownership (scoped at teams, not individuals). The idea behind microfrontends is exactly this: independent teams owning independent parts of the app, each developed end-to-end (Micro Frontends - extending the microservice idea to frontend development). And indeed, that’s how it played out – our organization and system architecture evolved in lockstep.

• Perhaps the most important value I have always vouched for is “unlearn and upskill.” The tech world moves fast; what built yesterday’s success might not work tomorrow. We made it safe – even celebrated – for team members to question old assumptions and throw out obsolete ways of doing things. For example, many of us (myself included) came from a background of inheritance. We had to unlearn some patterns and understand composition when moving to writing React. One senior engineer who had spent years optimizing PHP templates had to consciously unlearn that paradigm when we switched to a Node based custom rendering engine. Approaching things with fresh eyes and a willingness to relearn from scratch has been a life saving skill when it comes to digital engineering.

This “unlearning” ethos also meant we didn’t get too attached to any single technology or methodology. We were constantly experimenting, evaluating, and if needed, pivoting. Early on we adopted one CSS-in-JS library, only to later drop it for a simpler Tailwind CSS approach when we realized it slowed down our build. No hard feelings – the motto was progress over pride in one’s own ideas. As long as we kept learning, it was OK to replace a tool or change a process. We never truly deprecated a technology or library. While generally we have been using Go to write server code, we still use PHP, Python or JavaScript to write systems. It is all contextual and on a "need to build what?" basis.

Bold Tech Bets: From Legacy to Cutting-Edge

Rebuilding a legacy system grounds up gave us the rare opportunity to leapfrog into a modern tech stack. We wanted to set up the frontend for the next 5+ years of growth, so we were bold in picking our tools – sometimes bleeding edge bold. Over the course of the transformation, here’s a quick tour of the tech stack journey and how the team handled it:

• Microfrontend Architecture: Instead of one giant frontend application, we gradually split the product into microfrontends – each a self-contained app for a specific feature set (Ads studio, Orders, Insights, Menu, Restaurant Pages, Homepage, etc), all integrated into a seamless user experience. We used Module Federation and a bit of custom glue to have these micro-apps load on demand. This approach meant different teams could deploy their part of the frontend independently without breaking others, aligning with our team structure. It wasn’t without challenges (ensuring consistent design, managing shared state, etc.), but it paid off as the systems grew – we could scale development much more easily than with the old monolith.

• React, Remix, Next.js, Astro – the works: We basically went from zero to one hundred with modern frameworks. Our first new page was built in React (a no-brainer choice given its popularity and our need for a rich interactive UI). Soon after, we introduced TypeScript across the board to bring type safety to our JS – a decision that significantly reduced runtime errors and gave engineers more confidence in refactoring. For server-side rendering and routing, we experimented – some microfrontends used Next.js (which gave us great out-of-the-box server rendering and page-based routing, but we have now deprecated it in favour of a custom rendering engine), while for others we tried Remix (for its optimized routing and loader logic). We even used Astro for a few mostly-static pages where shipping less JavaScript made sense (blogs). Using multiple frameworks might sound chaotic, but our philosophy was to use the right tool for the job and our microfrontend setup allowed different parts of the site to use different stacks under the hood. Crucially, we established good integration practices (common design system, shared auth logic, etc.) so that to end users it all felt like one coherent product.

• Modern Tooling (Vite, esbuild, Rspack): One pain point with the legacy stack was the slow build and deployment process. We attacked that aggressively. We moved some products from Webpack (mature and robust but a bit slow for our needs) to Vite (leveraging lightning-fast esbuild under the hood) for local development, cutting cold start times from minutes to seconds. We also experimented with Rspack (a Rust-based bundler) as it emerged, and ended up adopting it for our largest microfrontend, cutting build times by ~70%. Faster builds meant faster iteration – which again fed into Parkinson’s Law (less idle time to expand the work). It was amazing to see a frontend build complete in 30 seconds where previously we’d wait 5 minutes – imagine the morale boost in the team.

• Custom Rendering Engine: Perhaps our most ambitious technical project was building a custom Node.js rendering engine for our server-side rendering needs. We found that as we added more microfrontends and SSR, the out-of-the-box solutions had limitations in terms of performance, security and streaming. So a small task force within the team (two of our “performance nerds”) decided to create a rendering server that could pre-render React pages ultra-fast, manage caching smartly, and even do some edge rendering. This was a huge learning experience – essentially building something akin to Next.js from scratch but for our specific needs. In the end, this custom engine is powering our most critical pages. It was about pushing the envelope when needed. The pride the team took in this project was immense – it is a bold bet and is still in a roll out phase.

Throughout this transition, one thing that stands out is how hungry to learn the team was. Rarely did someone say “I don’t know X and I’m not comfortable.” More often, it was “I don’t know X yet, give me a week and I’ll try building something with it.” That attitude allowed us to jump on emerging tech like Remix, Rspack and even training models ourselves without a formal training. Team members ran internal brown-bag sessions to share what they learned. We essentially created a learning flywheel – every time someone mastered a new skill or tech, they’d bring the rest of the team up to speed, who would then be inspired to go learn something else new. It was contagious.

The Flywheel of Pride and Ownership

As we started delivering results – a faster website, new features, a more robust architecture – something magical happened internally: a self-reinforcing flywheel of team pride. Each success, even a small one, boosted morale and motivated us to reach the next milestone. We made sure to celebrate wins publicly. If one mini-team rolled out a particularly neat feature (say, an AI-driven UI module), the whole team felt a sense of pride. That pride translated into higher motivation, which led to even better output in the next project. It became, as one of our senior engineers coined, “Pride-driven development.” 😄

More formally, this echoes a known truth of team dynamics: *pride and confidence can boost motivation, engagement, creativity, and collaboration (How to Build Pride and Confidence in Your Team)】. We absolutely saw that. When a teammate built something impressive, others reacted with *inspiration*. I recall when one of our interns single-handedly built a web app leveraging RSCs within a week of its announcement, allowing the product's home page to have a video, an interactive map and animations, still loading the content in a snap. Instead of others feeling upstaged, it fired them up: soon another team member started profiling our pdf rendering services and wrote a system to generate and sign PDFs blazing fast. We recently open sourced the service and called it Espresso. It was like a friendly game of one-upmanship where everyone won and the platform kept getting better.

We also fostered pride by trusting the team with big responsibilities. From early on, I pushed for us to own not just the “frontend code” but anything that affected the frontend experience. That meant diving into backend performance issues, or working with the infra team on deployment pipeline improvements, or collaborating with security on auth flows. We became known as the team that “figures stuff out no matter where it leads.” While that meant more work, it also meant more ownership. And with ownership comes pride. Folks weren’t just coding in a narrow lane; they were contributing to the entire product experience. Truly full stack.

I believe, this sense of ownership has also kept retention high. When people feel this is my baby too, they’re less likely to jump ship for another company (and in some cases teams too) where they might be a more cog-like contributor. We weren’t just building a web app, we were building a culture and a reputation. Internally, other teams started reaching out to my team for advice on problems or to collaborate on cross-functional initiatives.

A Small Community of Pirates: Boldness, Trust, and Fun

Why do I keep referring to pirates? Let me explain: Early in the journey, I sent the team a poster that read “Move Fast, Be Audacious.” It was inspired by a famous Steve Jobs quote about pirates: “It’s better to be a pirate than join the Navy”, meaning it’s more fun (and sometimes more effective) to do things differently, to be a bit rogue in pursuit of big goal (Steve Jobs' speech that made Silicon Valley obsessed with pirates)】. We embraced that identity playfully. We weren’t reckless, but we weren’t afraid to challenge bureaucracy and take risks.

This pirate mindset manifested in several ways:

• 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:

Reflections: What Worked and What We Learned

Looking back on this journey from a lone engineer with a mandate to a 21-strong full-stack team, a few reflections stand out to me:

• Culture and Principles Beat Process. We didn’t start with fancy processes or rigid methodologies. We started with principles – those laws and values that guided our decisions. That set the tone for everything. A small team with a strong culture will outperform a large team with a weak one. By instilling values like ownership, learning, and focusing on impact, we unlocked everyone’s intrinsic motivation. Process followed naturally (we iterated into a lightweight agile approach that suited us), but culture led the way.

• Hire for Attitude, Train for Skill. This old proverb proved so true. Our most impactful team members were not those with the shiniest resumes or exact skill matches, but those with the best attitudes – problem solvers, eager learners, team players. By composing a group of such people, we created a multiplier effect where everyone kept leveling up each other. It also led to 100% retention; when people are growing and having fun, they stick around.

• 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. I’ve come to realize how important it is for a team to have an identity and pride in their work. It’s not ego; it’s about believing that what you do is special and telling that story. We internally demoed our work often, celebrated each other’s achievements, and even shared our journey externally (through blog posts, meetups). This created a virtuous cycle of pride -> motivation -> great work -> more pride. It also signaled to potential recruits that this is a team where you can do the best work of your life. In a competitive talent market, that’s huge.

• “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!).

In conclusion, the journey of rebuilding Zomato’s frontend was as much about people as it was about technology. Yes, we went from PHP/jQuery to a modern tech powerhouse with React, TypeScript, microfrontends, and even machine learning in the mix. But the real transformation was turning a blank slate into a high-performing, happy, and resilient team. We became a mini community that cares for each other and takes pride in our craft. We learned that with the right culture a handful of motivated engineers can build and maintain systems that serve tens of millions, all while having fun and growing in their careers.

For senior tech leaders reading this, I’d say: never underestimate the intangibles like culture, curiosity, and team branding. Those can be your secret weapon in attracting top talent and fostering innovation. Fancy tech is great, but it’s the people behind it who make the magic. If you create an environment where a bunch of “pirates” can unleash their creativity and passion, amazing things happen. Zomato’s frontend is living proof – it’s now a vibrant, ever-evolving ecosystem, run by a crew that’s not afraid to sail uncharted waters. And as captain of this crew, I couldn’t be prouder of what we achieved together.

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.