When Modulr's chief software architect Ritesh Tendulkar landed his first fintech software engineering job at CorporatePay in 2008, the word 'fintech' didn't even exist, let alone have its own Wikipedia or dictionary entry.
Little did he know then it would be the start of a 10-year career in fintech. CorporatePay was one of the largest privately held providers of corporate prepaid solutions to the travel industry in the UK before it was sold to business payment processing provider WEX in 2012.
At CorporatePay, Ritesh met Myles Stephenson, Modulr's CEO, and other co-founders of the company. Witnessing some of the problems companies faced when it came to topping up money on their prepaid cards, gave them one idea for developing Modulr, a business-to-business payments platform that makes sending and receiving payments, and reconciling them, more automated and less error-prone.
We spoke to Ritesh about the "Herculean" task of designing Modulr's B2B payments platform from the ground up, the company's API-first approach and the type of developers it is looking to hire in its London and Edinburgh offices.
Q: What problems were you specifically looking to solve when you started Modulr?
Ritesh: The first problem was the time it took to make payments and receive money. Opening a new bank account is an onerous process for a lot of businesses. If your business model requires you to create 10, 100, or even 1,000 bank accounts, a lot of businesses can't do that quickly enough.
The second thing was availability. Even though we found partners that could create bank accounts in bulk, they couldn't do it in real time when we wanted them to. That is where Modulr's Application Programming Interface (API) comes in. We wanted to create an API so people could access services without having to log in somewhere manually.
Q: Every fintech has an API these days. So what is different about Modulr's?
Ritesh: We're API first: Anything Modulr builds is exposed to our clients using APIs. Most companies that are not fintechs will have software systems they are already running and then create a component that provides API services. It is an add-on solution to what they already have, which limits what you can and cannot do, and how easily you can do it. Modulr's API uses REST JSON, which means the amount of data exchanged is smaller and it's developer-friendly.
Q: When you're building a software platform from scratch, how do you balance what you need to deliver to get the product to market, and features you need to add later to account for new developments in payments and software?
Ritesh: Before we even started writing code, most of the work we did was understanding at a high level what the system needed to do, the major functions, how we would prioritise them, which features we should build first, and what we should build later.
You also need to think about what you're building is going to look like in six to eight months time. If you don't have that vision then you'll solve the little problems fairly quickly, but you'll have a system that won't scale well. New technologies are not that easy to anticipate. But if you build systems right, these things are easier to manage.
Ultimately, you need to be flexible. A lot of 'techies' fall in love with what they build and won't listen to any criticism. But you cannot get too attached to what you've built.
And, no matter how grand your plans are, you need a team of software engineers sitting in front of computers that can convert your vision into a good piece of code (Java, Spring Boot, Postgres, RabbitMQ, TypeScript, Angular) that is maintainable and easy to understand. That's where the rubber really hits the road.
Q: You're continually adding new services to the Modulr platform. How does that inform how you approach software development?
Ritesh: Modulr is based on a microservices architecture. Any feature that the platform develops comes from different modules working together. Microservices is a buzzword at the moment, but it doesn't come without its own issues, which software developers need to be aware of. For example, the sharing of data between services has to be worked through. Any feature that we add, we have to understand is this a generic feature that fits within a microservice we've already got, or do we need to build a new microservice? If we do the latter, how will it interact with the data that is already in the system?
Q: What qualities in software developers is Modulr looking for?
Ritesh: We are building a lot of complex systems, which we want to make simpler for our customers. Once these systems are built, they have to be supported and updated as newer features are added and the volume of transactions increases. Moreover, we are regulated by the Financial Conduct Authority and handle client's money and take our regulatory commitments very seriously.
To help us do all this, we need engineers that are problem solvers. They must be excited by the technology and new tools, but also be pragmatic in terms of understanding the trade-offs between these approaches and able to deliver solutions built in an optimum way, keeping pace with the frenetic pace of a fintech.
Q: What is the best thing about working for Modulr?
Ritesh: It's much more rewarding than working in a bigger company as you can change things and see the results fairly quickly. Typically in smaller teams, everyone needs to pull their weight. There's no room to hide. In bigger organisations there's so many people around you, you're work is shared. You may work on major enterprise systems and solve challenging problems, but more often than not you don't have an opportunity to see how these affect people in their day-to-day lives directly. Larger organisations are also a lot less agile, which limits how quickly you can do things.
Visit the Developer Centre to find out more about Modulr's features and functionality. If you're interested in job opportunities at Modulr please email us on: careers@modulrfinance.com