Vikas and I love Bob’s Bar in Indiranagar. Quiet enough to talk, and buzzy enough to havr fun while talking, it is a great place to discuss “how would you do this” with friends. So it was that after I decided to join Shoffr as the tech guy, we sat there one evening and talked about how we would build the technology that powers Shoffr.

That technology would power it was not in doubt. Today all companies are software companies. Much of any company’s customer experience is delivered via technology touch-points like apps. Everyone has technology running to optimize and scale operations. But what specific principles would guide us in building our tech stack?

So we went back and forth over it and came up with some guidelines.

• The technology should be super flexible so that we can quickly adapt it as we grow. Especially in the early days, this is critical since no one knows how things will really pan out.
• Buy rather than build as far as possible. I knew that in the beginning, most of our tech problems would be mundane. Since many of the problems are mundane, we will try to buy as much off-the-shelf software as we can. This gives us time to solve the problems that are core to us instead of building everything by hand.
• Use as boring/familiar a tech stack as possible. This would mean that everyone on the team would be well-versed with the tech stack and so more productive, and help would be easily available online should we falter somewhere.
• Hire extremely reluctantly. Overlarge teams are less-productive than small teams working with familiar tools.
• A side effect of hiring reluctantly is that we only build the most important things at any point. The meat of our operations is the car and the driver and not two dozen features on the customer app. The idea was to slow down, hear from customers and operations, and then solve the most pressing problems.

These ideas have played out in interesting ways over the last few months.

• There were off-the-shelf tools available for end-to-end adoption. But we had two reservations about them.
  • The no-code ones were too difficult to customize as needed. I tried a couple and found that I was spending more time figuring out the tool than building what I had to.
  • We wanted to be free to evolve our customer touchpoints regardless of how we ran our backend operations. Most of the tools out there were all or nothing (or too expensive)
  • So we decided that we will build the external interfaces and get them to talk to our own backend. This backend will then integrate against whatever other tools are required. This is a fairly standard design but listening to all the no-code hoopla, I had hoped to do far less by hand than this.
• At this early stage, an app also didn’t seem justified – even our most power-users wouldn’t use it more than 1-2 times per week, given the nature of airport travel. A minimalistic + responsive website would serve the purpose, and take much less resources.
• Since I was the only developer in the beginning, I started building the backend and the website in Spring Boot + Thymeleaf + MySQL which is both boring and what I am most familiar with.
• Then we got Saurabh Thakur to work with us for some months and he was disgusted by the server-rendered/client-rendered hodge-podge I had made of the frontend. So he convinced me that we should write the website in Nextjs. I managed to convinced him that we will not put the typical backend-of-frontend node.js layer between React and the core backend. So today the customer website is rendered in react/next and calls the backend directly.
• The backend integrates a bunch of other tools like Guphup (for SMSes), Amazon (for S3), Google (for maps and sheets APIs), Slack (for trip notifications messages to operations team), and Paytm (customer payments), and Zoho integration is ongoing. We have been able to quickly tweak all these integrations multiple times in the last month alone.
• I was very worried about changing requirements when I started writing the backend, so I specifically chose to separate the workflows from core APIs to maintain the flexibility of the code. I will share more low-level details on this in a follow-up post, but this has paid out handsomely so far.

More on the tech-product side of Shoffr in upcoming posts 🙂