AMA with Jayesh

This topic was automatically opened after 2 hours.

Hi Jayesh, so good to see you doing this! What sparked your interest in FinTech?

Welcome everyone! And say “Hi” to @Jayesh_Sidhwani, Chief Architect at Jupiter! :man_technologist:
Jayesh is here between 6 and 7 p.m. to answers all your questions about the tech behind Jupiter, what we’re doing differently, and what it takes to build a fully digital bank from the ground up! Comment on this thread with your questions and we’ll answer it live, right here!

Hi Jayesh. What is the scale at your system operated. And what were some of your learning while scaling up?
Thanks you for doing this.

1 Like

What is the coolest thing you’ve learned since you started working on ‘building a bank’?

1 Like

Hi @Jayesh_Sidhwani , What are the challenges you faced here building a bank which you didn’t when you were at Hotstar?

1 Like

Hi everyone! Jayesh here. It’s great to see your questions already rolling in! I’ll start answering in just a few minutes. Keep them coming!

3 Likes

Hey Jayesh & Team. The Jupiter iOS Application Snapshots put up on website looks quite intuitive.

@Jayesh, I am curious to know about:

  1. The frameworks/programming languages team is using to power the server side of the product?
  2. If you guys are focussing on hybrid or native approach for client side mobile development?
1 Like

Hi Jayesh, thanks for doing this.
An architectural question - in the case of customer onboarding and account opening, how much of the process orchestration complexity have you taken into your platform as opposed to leaving the orchestration with the partner bank? In asking this, I am assuming it would have been a nightmare for you to use the bank’s APIs, let alone orchestrate them :slight_smile:

Hello Jayesh. Greetings.

Interested in knowing how you are going to impact the people at large and how things will improve. Also, interested in knowing how tech is handled in general specially in terms of scaling, etc. It should have taken a much consideration at your end

Hey Ratika! Fintech has always been my favourite space.

It started off with trying to understand how the stock markets work, to losing some money, to being intrigued by its fundamentals. I am a big believer in budgeting my expenses and have been using YNAB for a few years.

While being a consumer of a bunch of fintech products, the lack of innovation in the banking sector always intrigued me. Around mid-2007, we got the iPhone and that triggered the whole smartphone revolution. Buying things online and chatting with friends suddenly became easier and more natural than ever. So while on one hand we had this whole bunch of new experiences, our banking experience somehow remained old-school.

The last decade however has been great – we now have products that let us do everything from making payments to investing online. While it revolutionised the old banking industry, imo, it also fragmented it. I strongly believe that there is a need for re-bundling. Something that combines the goodness of these products while still providing a coherent banking experience to the user.

That’s what I crave, and that’s what sparked my interest in fintech.

6 Likes

Hey Ishail, Hotstar and Jupiter are extremely unique experiences for me. Hotstar was all about scale.

Jupiter is a bank and so requires a very different mindset. While Jupiter might not achieve Hotstar’s scale (I wish it does), there is very very little margin for error. You just cannot afford to go wrong. That means you have to think very carefully and deep when you’re building the product – there’s no blitzscaling at Jupiter. You go slow, but you do it right.

At Hotstart, security was one of the problem statements. At Jupiter, it is at the centre of everything we do. Security is a fabric that impacts everything we build.

9 Likes

Hey Pratyush, trying to answer one part of your question as @Tushar_Maroo also asked me about Tech- stack

Building from scratch is always fun because you can pick exactly what you need from such a wide variety of technologies! However, I’d be a little conservative and choose battle-tested technologies for production.

Here’s the stack I’d pick if I had to build from scratch:

Language/Frameworks:

This really depends on the problem statement – if you’re building APIs then I have found the JVM stack to be really mature. In fact, Kotlin appears to be a good language – it’s got the right mix of functional aspects along with the robustness of JVM.

At Jupiter, we primarily use Java and Kotlin for our server-side programming. For web applications, we use the SpringBoot framework.

I have personally found Ruby and the RoR framework to be really handy for building admin dashboards. The framework lets you be really agile while developing.

When it comes to pulling off one-time scripts, I have moved from Python/Ruby to Go.

Monitoring Stack:

I have a lot of experience with Prometheus + Grafana. I’d pick that anyday! There was a great blog by the folks at Zerodha on this topic

CI / CD:

Github Actions is my new favourite. We use it extensively for builds and pre-build checks. It is my go-to CI tool these days.

For CD, I’d pick either GoCD and Spinnaker. We use Spinnaker at Jupiter and we love it!

Deployment:

I would choose Docker + Kubernetes. At Hotstar, our platform team built a massive cluster that would handle a load to the tune of a few million requests per second. The entire infrastructure scaled seamlessly!

We use Docker & Kuberenetes at Jupiter as well. The ecosystem has fine tooling as well, which makes it a stronger option.

Data Lake

I’d pick S3 as an option for Data Lake. My choice of a warehouse will really depend on the scale of the problem. I’d pick AWS Redshift if it is affordable. If not, I’d look out for other options.

7 Likes

@Kushan_Shah Also happened to ask “What is Jupiter’s engineering process like? How do you manage engg team? What is the engg culture like? What keeps you up at night?”

Interesting questions Kushan!
We are a fairly small engineering team at Jupiter and we’d like to keep it that way. We have a few engineering philosophies that we follow: one which is to ‘do-it-right-the-first-time’. This is ingrained in how we attempt to solve any problem.

Our engineering team is divided into pods. A pod is a logical group of backend and frontend engineering teams, a product manager, alongside business and operation managers. The pod then becomes a self-contained entity that works on a problem statement independently.

With that structure, we have set up a few processes that ensure that while the pods work independently, the entire team is aware of what everybody else is doing. We are also meticulous with documentation. Any new problem statement we work on is documented first. We have a set template for writing an engineering spec, which covers the problem space, various solutions, a high-level and a low-level design, the execution timelines, and also the cost of ownership, when the product goes to production.

The specs are then published on an internal wiki that the entire engineering team can read. Besides this, we have bi-weekly architecture councils – we call this a Jedi Council. No kidding. It is called a council (mainly because we wanted it to sound cool), but the entire engineering team participates. Anybody from the engineering team can nominate themselves and present their engineering spec/architecture to the wider team. It is a great forum to receive advice and be critiqued on the spec.

Apart from the architecture councils, we do bi-weekly Demo-Days. Attendance is mandatory at these Demos for the entire organisation. We use this time to present our engineering work to the wider organisation and receive feedback.

While documentation is always good, this process also creates a lot of transparency in how we operate as an engineering team. Specifically:

  • It keeps everybody aware of what everyone is doing, so we don’t reinvent the wheel
  • Allows folks to work on different problem statements and not be constrained to their pod

Our engineering team is self-managed. We do not have managers, but we have team-leads. The team-lead is also the developer on the team with an extra responsibility of mentoring the other team members and bringing consensus on various discussions. At Jupiter, everybody in the engineering team codes and is expected to manage their work. Team-members can reach out to anybody in the team for mentoring. Ceremonies like the arch-councils and demo days are great ice-breakers and make the team more comfortable in seeking help from one another.

What keeps me awake in the night is a really tough question, because it is different on different days. The problem statement is really fascinating (and tough), and the engineering team is really amazing. The regular nights are all about how we can meet our launch timelines. At times, I think a lot about the newer problem statements the team can solve. There is a constant itch to do better; to see the final pole sooner - that keeps me awake.

7 Likes

Thanks @Jayesh_Sidhwani. That covered more than what I could have thought of learning on a Friday eve. Fintech inspires me as well and your answer gives me deep insights on fintech technical ecosystem.

Working on iOS & being curious about backend, I will explore the server side stuffs that you have mentioned.

1 Like

Akshita Agarwal asked What are the difficulties you are facing /have faced while building the tech team from scratch?

I’d say that building a tech team from scratch at Jupiter has been just as easy or difficult as building one for any other product. None of our engineering team members have built a bank before, so it is the first time for all of us. However, our business and operations teams have decades of experience building banks, and that has helped us a lot. In fact, some of them have played instrumental roles in building a few of the top-10 banks in India. The value is immense!

This creates the perfect blend between people who know this industry and people who can create the product. And we strive to nurture that blend every single day.

At all times, it is important to stick to our first principles, and we have a few. These first principles always align us to a common goal. A lot of the time, we deviate; but as leaders, our job is to create an echo-chamber to keep realigning the team back to the first principles.

2 Likes

Aryan Jain asked You have had co-founded some of the startups, please tell the key takeaways from that journey of yours as a techie and not entrepreneur

Being an entrepreneur has taught me that running a startup is not only about building a product.

Being an engineer has allowed me to be patient. All bugs are solvable. If you don’t know something, learn it. We are all students.

Last but not least – have a strong set of first principles. And stick to them. I keep my first principles in my Notes app. I have even set weekly reminders to read my first principles and reiterate them to myself. This has helped me everywhere – engineering or otherwise. Having and relying on your first principles is the best decision-making mental model you can create for yourself.

2 Likes

This is very insightful. Thanks, Jayesh.

1 Like

Abhishek Mane asked Could you please tell us software development processes you have set. How to improve developer’s productivity?

Planning our work is key for all of us. At any time, we have at least 3 months visibility on what we want to build. That allows us to better structure our teams and our deliverables. We work in 2-week sprints. The product managers on the teams decide the priorities of the work items.

In my experience, a developer’s productivity is impacted by multiple things. It starts with the amount of clarity that the dev has about the task they are coding for. The execution efficiency is directly related to the amount of clarity they have before starting. And this clarity isn’t just about the requirements – it’s also about how they plan to engineer it. All of this helps me draw a rough sketch of the implementation plan, brainstorm with my peers, and crystalise my understanding. Only then do I proceed to writing actual code.

The next phase tackles the productivity concerns while writing code. Here, I love to set aside time just for myself. An engineer can’t get away from meetings, but is important for us to make the most of the non-meeting times we get. It is important to zone right in – whatever lets you do that – and get down to business. The tools you use also have a direct impact on your productivity.

Here’s a great blog on how important managing your time is for increasing your productivity.

It is also important to know your language. When tackling a problem, your focus should be on solving the problem and not figuring out how the language/framework works. It is crucial to spend your weekends or free time mastering the programming language and the framework you use.

A general rule of thumb is that if you do anything 3 times manually, automate it. You’ll save more time than you think.

2 Likes

Thank you everyone for your questions!
and Thank you so much @Jayesh_Sidhwani for taking out the time!

Obviously we’ve over-ran our time, but Jayesh has been kind enough and will answer questions, which you have already sent across at the time of registration during the course of the weekend. So keep a look-out :slight_smile:

And sorry, if we’ve not been able to answer some of your questions. There’s only so much we could answer at this stage. But please stay with us and we could have more conversations along the way :champagne: