The Making of A Food-Tech Unicorn

CTOtalk
CTOtalk
Published in
6 min readMar 29, 2021

A good start to the weekend — a session with Rahul Jaimini, Co-founder & CTO of Swiggy at CTOTalk by OrangeScape (known for it’s product ‘Kissflow’).

Rahul Jaimini was the third person to join Swiggy as the Technical Lead along with the two founders. The journey of Swiggy over the few years is a really inspiring story to hear and thanks to Rahul for sharing this.

Swiggy was not a big success at the start — at least for the first six months. Imagine there was no app, very minimal DEs (Delivery Executives), less support from restaurants, and many road blocks. To crunch the numbers, a comparison with the current metrics will help one easily understand their growth over the years.

  • From just one neighborhood (Koramangala in Bangalore) to 500+ today,
  • From 30 Restaurants to 30,000 today,
  • From 5 Employees to 5,000 today and,
  • From 5 Delivery Executives to 50,000 today.

Mind blowing, isn’t it? But one thing Swiggy never compromised to is their ambition to code and passion for food.

Swiggy hired a person with the role ‘Head of Expansion’ and targeted 5 more neighborhoods a year later (2015). It was surprising to hear the fact that for 8 months, his team lived out of hotels, always flying to various cities to eye their potential in those cities.

The History

Before the application we use today was born or written, the history was not customer friendly or very ease to use for all the stakeholders involved in the platform. There were a lot of problems for each stakeholder…

How Swiggy operated in the year 2015?

Delivery executive assignments

  • The delivery executives were assigned manually for each order.
  • They were sent SMS to notify, and at the worst case a missed call.
  • There was no live tracking, they had to notify with a call to update the status.

Restaurants

  • They called the restaurant to notify the order each time.
  • They had to pay the Delivery Executives to deliver.
  • Few restaurants also declined the order due to pricing issues.

Operations Team

  • They often complained wp-admin dashboard is always slow. (Yes, they started with WordPress)
  • Some also mailed ‘db is slow’ instead of ‘dashboard is slow’ which gave heart attacks to the technical team.

Hiring at Swiggy

Looking to work at Swiggy? Read this.

Swiggy was not a funded startup until 2015. They hesitated to hire people at the start but they eventually accelerated their presence as time flew.

They preferred ‘Intent over Talent’. Swiggy always preferred candidates who had great interest on the company’s vision, problems, and the people inside. With great intent comes great responsibility. They continuously hired people who felt they had an ownership on Swiggy because those are the ones who will learn quickly and be happy with the company’s goals and road maps.

Problem + People + Pay = Dream Candidates
A
good candidate is what they needed than a great candidate. Any one who has their basics strong and the will to contribute can grasp the needs quickly.

He goes on to say, “Find your DNA and never dilute it”. He added that during his tenure till date, he spent 2/3rd (Around 60%) of his time in hiring and he says he loved to do that.

Swiggy’s values

Swiggy framed a few values that they strive for wherever they go. This is the fuel that makes them grow every day.

  1. Customer First Attitude,
  2. Strive for Excellence,
  3. Be curious and be learning,
  4. Exhibit bias for action,
  5. Act like the owner,
  6. Be humble and be honest,
  7. Have high levels of integrity,
  8. Stand-up, Disagree and Commit.

His thoughts on ‘Road Maps’

“Don’t try to become Aamir Khan on Day 1”

It takes a lot of time and commitment to grow big. This was the take away from his section of Swiggy’s road map planning. He says and insists road maps define the problem. One should always have a detailed road map of what they are gonna achieve in the coming days as it gives more clarity and helps to be focused on what you are going to build.

“3 months of customer feedback than 6 long months of coding”

He says that it’s always better to build in modules and integrate it. Get customer feedback as it is more important than building the product for long duration without launching them.

He also insisted on Security. Security is a Process and not a Product. It’s a wall and ladder thought. People will always try to build a ladder to match the height of your wall. It’s an integral part of your road map and the wall must be raised every day, hence it is a process and not at one time set-up.

A few small stories of Swiggy that is not known to public.

1. Shutting down business for one day

Once the new application was created for delivery executives, the adoption rate was only around 10–15%. Today, the delivery executives completely operate using an app only. In 2015 delivery executives preferred the old system since the app was entirely new to them. Since the adoption rate was low, the team decided to stop the business for one day and helped delivery executives transition to the new app overnight. At that time they clocked around 600 orders per day (April 2015). This was a great success to them though.

2. Choice of Tech Stack

Swiggy operated on WordPress for the first two years. They used PHP & Django during the thriving stages. Today they have some of the best engineers with them and are creating wonders. They are always ready to experiment new technologies and they focus on SPEED. Since UX is their first priority, they preferred PWA as their choice to accelerate the speed of their website, to be on par with the mobile app.

They follow PWA as a philosophy now. Rahul envisions that in future, they will not have 3 teams developing for mobile and will instead use PWA to deliver the same experience.

It’s okay to make bad choices to build, but it’s not okay to make bad choices while scaling up.

3. The time when it took their app 11 secs. to load

Unknowingly in an update, they added a lot of stuff and the result — the app’s cold start took 11 seconds due to an API call being slow. They later found that out and it took 15 days to publish the new version after the fix to regain the speed of 3 seconds to open the app.

They simply didn’t want to compromise on speed and customer experience.

4. Team sliced into divisions

They observed that the team performed well when they were cut down into various divisions like one for delivery, one for restaurants, one for fulfilment, etc. They were able to work more efficiently and take more ownership on those roles. It was more productive than a whole bunch of people working on multiple things.

5. Outsourcing at Swiggy

All the things at Swiggy were not built internally. Sometimes it’s always good to outsource few needs to get things done. For instance:

  • The first version of Swiggy’s android app was outsourced. But the APIs were built by them to make sure their core back-end processes are abstracted.
  • Their current new app for owners of restaurants is outsourced. It’s outsourced because they wanted to test the possibility of React Native in their product.

6. Volume of orders today

It’s always a 3X growth every three months since they started. From 100 orders on 2014, it’s millions of orders per day in 2018. It’s disclosed that there is a 1000x growth since their founding year.

(Reposted with edits from Saasjungle.com by Praveen Thirumurugan)

--

--

CTOtalk
CTOtalk

Published in CTOtalk

CTOtalk is India’s first knowledge-sharing platform for and by CTOs. We host discussions and produce resources around the topics of technology and engineering by CTOs for the community.

CTOtalk
CTOtalk

Written by CTOtalk

CTOtalk is India’s first knowledge-sharing platform for and by CTOs