For a team that’s as dedicated to solving problems as Moniepoint is, product development is part of the day-to-day. But every now and then, there’s that period when things get a lot more intense than usual. All hands on deck, pushing around the clock, and unsure if it’s going to come out like you expect. The Moniepoint Personal Banking product was just like that, and here’s a peek behind the madness that brought it to life. 

A short history lesson.

Speaking with the engineering and design teams to get a full picture of the product we built, revealed a larger image than I expected. The first thing I learnt was that the idea of a personal banking product wasn’t exactly new to the team.

Between 2018 and 2019, Moniepoint (then TeamApt) tried many new things. Instead of the large company we are today, think of a SWAT team. A small elite group of engineers, kicking down doors and taking no hostages - fast and adept. They had the expertise, and had gained experience building products for banks.

More than 26 banks in Nigeria, and their customers, used products that they had built. They explored both B2B (building backend operations) and B2B2C (building mobile banking apps). Now, the team was pivoting into building directly for the market and experimenting with a few things.

The more common ones you’re familiar with are Moniepoint and Monnify, but one product that was explored is a personal banking solution called Kuwego. Not the flashiest of names, and even a bit cornier when you realise it’s made from kudi, owo, and ego, all of which translate to money in Nigeria’s major local languages. But the idea behind it and its infrastructure was solid.

True to our mission of creating financial happiness, it was to be a personal banking product that could fully support the user. It would offer the usual transfer, airtime and bill payments, but even more, make loans and savings possible. The team grew this product, and it had over 10,000 customers at the time, but resources were limited.

This was 2019, and both Moniepoint and Monnify saw rapid growth, so the team decided to focus most of their efforts on these two products. Kuwego, with all its promise, was put on ice.

Personal banking today.

If building a personal banking product wasn’t entirely new to the team, then what made it such a great idea now? The short answer - customer feedback.

For the 1.5 million businesses that use our products, the experience is seamless. Payments are lightning-fast, and downtimes are minimal to non-existent. In whatever way their customers need to pay, they can accept them easily.

But this customer/business interface is where most of the challenges lie. Sometimes card payments fail due to reasons that are entirely not the fault of the businesses, or the customers, really. We created the request for refund feature to mediate in periods like this, but what if they didn’t have to occur at all? What if all card and transfer transactions went through?

Even more, some of these businesses needed a way to manage their employees’ payroll efficiently. If their workers needed salary advances, it could and should be much easier to provide it automatically.

The team’s answer to these questions was a project phase. Let’s call it Project X 2.0

Project X 2.0

When Ope, SVP Channels, got a call from Tosin on a regular weekday in April, he had no idea it would spin out to become something this grand. On the call, he discussed some of the feedback the team had gotten from business owners, and how to implement them.

With the feedback they had received, there were two things the team needed to do. The first was to update the mobile app for businesses and give them a better experience. The second, and why we’re here today, was to create a personal banking application.

After that call, and having initially concluded that internal resources might not be enough to carry out the project, the plan was to outsource it. But there was a problem. Unlike the usual product development life cycle, where the amount of work needed to be done determined how long it would take, this was the other way around.

There was a deadline. And the search was for a team that could deliver within that short (and probably a bit crazy) timeline. Two weeks of calls and meetings passed, discussing with local and international software vendors (kinda like TeamApt used to be). The two weeks only brought bad news - the people available either couldn’t do it at all, or would take at least 8 months to get it done.

If you want to get it done, do it yourself.

At this moment, when outsourcing had become unsuccessful, the team decided that we would just do it ourselves, and in 3 months.

On 10th May, 2023, Tosin announced that the team would embark on another project sprint. If you’re wondering what the first sprint was about, you should visit our careers page to join us and find out. For this new sprint, there was something different that hadn’t been done for a while. Not since the SWAT team days.

As Ope had tried to figure out how exactly the team would pull off this insane project in the time available, he realised something. The only way to make this possible was to have everyone working in the same place in real-time. He brought this realisation to Tosin, who agreed.

The team working together from across the world was usually just fine. Everyone collaborated seamlessly from different time zones, putting in their best work. But to meet the demand of what we were trying to do, everyone had to be together at the same location. 

And that’s exactly what they did.

From the UAE to the UK, US, Canada and even Pakistan, every engineer who would be a vital part of this project was brought down to Lagos. Everyone stayed in the same hotel with everything they needed, and all they had to do was focus on the work.

The first step is planning.

Before anyone’s flight was booked, it was important to consider how exactly we would do this. Firstly, meeting the timeline meant it would be impossible to build from scratch. And it wouldn’t make sense to, anyway.

The entire reason we were doing this was because our business owners trusted our services. We had an infrastructure that already banked over 1.5 million businesses. Hence, we decided to just build based on that.

Even more, Chidum, SVP of Engineering, knew that everyone working on the same source code would bring on more problems. There was a possibility of merge issues, which would only compound as they were fixed. Testing, depending on which components were built out first, would also be impossible. For example, if transfers are built first, it would be impossible to test it without the login process.

With all these potential challenges, they decided to use a concept called microservices app. If you’re familiar with our infrastructure, you’ve probably heard of the term “microservices” a few times. This worked with the same concept, but instead of communicating with the different parts via APIs, there was a “super app” component interfacing with the different smaller apps.

They broke down the app into smaller functions so each person could build it independently of the other, and the main app would be made up of these parts.

Imagine you wanted to build a car and had limited time and people available to do it (yes, the process is automated. Just imagine). You could have everyone working on the car, and building it at the same time. Maybe you begin with the frame, then move to the engines, adding in the doors, one thing at a time.

What they did, instead, was to break it into smaller parts. So different team members worked on different parts, and someone brought everything together seamlessly.  There was onboarding, transactions, dashboard, and many other parts we treated as smaller apps, with a super app that referenced all the apps.

It’s a lot more complex, but that’s the simple way to put it.

Same bank, minor differences.

Most of these functions already existed for the business app but functioned differently. For example, a business owner could have multiple accounts within the same app, while a personal user needed just one. So, while using the same base, the engineering team built a different flavour of the business app that functioned as a personal experience.

A flavour of an application is, essentially, a variant of a particular application that allows you to modify the existing application. So, you have a new application that behaves in a different way, but works based on the fundamentals that have been implemented on the existing application.

This was the same concept across the board. Each microservice app was built to match the custom experience of the personal user based on what previously existed for businesses. This was great for two reasons;

• Firstly, it meant we could build the personal app easier, faster, and more efficiently, meeting the deadline.

• Secondly, it meant that subsequent updates would be less complicated. We could scale easily, and add in new functionality more seamlessly. If we wanted to develop a new feature going forward, we only had to build it in one place.

Beginning the build.

With a general idea of the approach to build this, it was time to get to it. Even though the entire project was meant to last 3 months, the bulk of the work would happen in 6 weeks, while the entire team was in one place.

When we first started, we stuck with the traditional team structure, but soon realised that this would not work. We had to break them down into smaller bits. In payments, for example, you had transfers, airtime, bill payments, etc. So we started looking at what complete flows we needed to build.

So while there were major teams, these were broken down into smaller groups to focus on specific flows.

For this to work, everybody had to be in sync. So the next thing was syncing the dev team with our design system, Kamona. A button is a button wherever you go. The spaces are the same as well. If you were to do an animation of a dropdown or pop-up, it had to be the same. The work here, was agreeing on a design pattern we would use everywhere.

Then these components were assigned to be created, and were in a shared library accessible to everyone. We also built all the widgets separately in a smaller application that everybody depended on. With this, the experience would be uniform across the app.

Building out these components and widgets gave the team time to work on the logic of it, which was the main thing. With the components in place, it became as easy as putting in a line of code, and we had the view we wanted on the application. Then we could concentrate on the View-Model.

As this was being implemented, there was still more planning that Chidum, Adrian, and a couple of other team leads had to do. It was like creating our own domain-specific language that we would use elsewhere. As some worked on the components, others worked on the flow.

There were questions the team asked to define this. If a person was going to do a transaction, how would they start? What goes where? The flow helped tell a story of the user’s journey using the components that were being created, before going into development. 

All or nothing.

So the first week was spent working on the components, while the leads worked on different flow iterations. From the second week, the PMs broke the flow down into smaller steps each team would work on. There was also a back-end component and an analysis of how the flow would interact with our existing APIs.

A lot of trust was involved, expecting everyone to do what they needed. Everyone focused squarely on their contributions for the next 4 weeks. The disadvantage of this was that everything didn’t seem like it would work until almost the end.

Instead of thinking of it as the team building a personal banking app for six weeks, think of it as one person building an onboarding app for 6 weeks, and another on transfers for 6 weeks. None of it made sense until we all put it together. The whole app was in a very incomplete state throughout the process.

It was an all-or-nothing approach.

By the 5th week, it was finally time to put everything together. Given that the teams had all focused on their parts, this first integration understandably didn’t go so smoothly. To find the issue, we had to test everything one after the other. The Enterprise Architect in charge of this process, Paul, ensured that all the hitches were worked through and fixed. After this first integration, however, and identifying the challenge, it was smoother.

By the end of 6 weeks, the team had successfully pulled through. All the different moving parts had come together and at last, there was a single product - the Moniepoint personal banking app.

And there you have it.

Anyone who’s familiar with product development knows that, of course, the end is hardly ever really the end. But the team had done the bulk of it. In Chidum’s words, “this was only possible because everyone gave 120%”.

Grit and technical depth are part of our core values, and for these 6 weeks, they became a whole lot more than just words on marble. If you’d like to be part of a team that’s doing cool, and sometimes absolutely crazy things like this, visit our careers page.