Mobile App Development Case Study for Digital-First Banking without Physical Branches

Ihor Polych

CEO at Devlight

Liubomyr Miller

Delivery Director

About the client & story behind

Nolimi bank is a financial startup that was founded as a pet project by one of the successful Ukrainian entrepreneurs in 2015.

The founder didn’t look like a person who is about to start his way into a new digital business — he came from a classic business realm, not attached to digital in any way. His past business was a large seaport in Odesa with a fleet of 50 merchant ships, a ship repair plant, and a cruising agency. The total number of employees of the holding amounted to more than 50,000 people, and the entire business was valued at more than 1 billion USD. Everything was great, so why even move?

But our client had something more than drive for profit. He had a vision. Back in 2015, he had a vision of how fintech would rule the world, conquering it and producing some of the most valuable companies on the planet. Looking at that from 2022, we can say he was right.

Why client decided to develop the solution?

Pros and cons of the current solution

The final aim of our client was to create the first financial marketplace with banking services at its heart in Ukraine and then expand it to the whole of Europe. Sounds a little bit boring for today, right? But back in 2015 traditional banking was irrevocably outdated and needed to be renovated. Our client saw it like that: traditional banks will be replaced by banks on smartphones. This trend was just emerging in Europe and no one singled it out, so our client designated it as «Antibank». This word contained the main reference point of the vision.

Here are some of the basic principles of the project concept:

• digital-first banking without physical branches
• the best possible user experience through web and mobile banking is the main emphasis
• replacing strict and somewhat boring usual banking tone of voice with a new, fancy and friendly one
• 24/7 online support department
• customer-centric approach

Reading this in 2022 seems obvious and not at all innovative. This is the basis, the necessary minimum that we require from banks nowadays. But in 2015, this concept sounded like a breakthrough in the market. 

Users’ behavior and new trends

Clients of the banks weren’t very picky back in 2015. They were more than willing to visit branches on the regular basis, deal with constant paperwork, and if any problem would arise, spend up to 20 minutes at the call center waiting queue until the available operator shows up. And no one of the clients considered all stated above as problems. They were o-k-a-y with that. 

Some of the banks had digital banking. It was a big advantage for clients but it didn’t have many features. Mobile banking applications at the time were mainly able to make P2P transfers, top up mobile and maybe make IBAN payments of a certain type. There was no FaceId technology available for mass users, and contactless payments such as Apple Pay or GooglePay were not supported by most banks.

However, there was more and more integration of smartphones into people’s lives each day. And as its penetration into society was growing at a frantic pace, it was obvious to leaders of the industry that completely remote digital-first banking is the future that will come within the next few years. 

Competitive landscape

International market research has allowed us to highlight some of the strongest competitors:

• British market — Atom, Monzo, Moneese
• European market — N26, Revolut
• russian market — Rocket bank, Tinkoff bank

The domestic Ukrainian market research didn’t show us signs of strong competition in the digital banking segment. With 37 million citizens and 28 million bank clients, it had almost no signs of digitalization. Instead of moving toward the future, Ukrainian banks at that time moved towards the past: they increased resources that were spent on the expansion of the physical network of branches and mass card issuing and distributing among the population. PrivatBank was the absolute leader of the industry, having more than 18 million clients but a very UX-poor mobile application.

At the end of this market research, it was clear, that we were at the origins of a wide and deep blue ocean. And next steps for us would be the correct prediction of customer behavior patterns, consumption, and how to satisfy them.

Request to Devlight

How they came up with the idea?

The client had no experience in launching all-digital businesses. And that was the main problem.

Lack of experience was resulting in struggling with product building and launching roadmap development. The project team went through a lot of consultations: with market experts, brand experts, UI/UX specialists, marketing specialists, etc. They did help them, but not enough. The client still didn’t have a detailed picture of the result they want to have by the end. There was no roadmap, no step-by-step plan of product launching, and no features and modules it should consist of. So this unresolved problems and unclear tasks lay on Devlight shoulders. 

Exact request

April 2016. That’s when the project operational team contacted us with the request of creating a simple mobile app for payments. According to their plan, during 1,5-2 years this simple app should evaluate into a full-fledged mobile bank. At the moment the in-house team consists of mobile developers and UX/UI specialists. But the results of their work didn’t succeed to meet the expectations.

«Can you take over the entire process of project development, both in the mobile app and the web banking app, so that we could have our first version released by the beginning of 2017?», — that was the exact request of the project team to Devlight.   

What did they have at the moment? Almost nothing. No clear technical task, no requirements regarding the product concept, no understanding of the value product will bring to the end user, no deadlines, and understanding of how an app would integrate into the bank system. All they had was:

• professional operational team with extensive banking experience
• budget for product implementation
• vision, and a strong desire to bring the product to life

Customer thoughts and references 

One of the main clients’ references was russian Rocket Bank. At the time it was one of the most progressive banking in Europe. This reference gave us an understanding of end expectations. But it didn’t give us a clear picture of what the MVP should look like with its features. In our discussions with the client, we were torn between two concepts: the first was a PSP product without a personal card, and the second one was a full-fledged neobank with both web and mobile versions.

Another difficulty was that open API banking was just emerging in Ukraine. You couldn’t outsource digital banking services to any bank in Ukraine back in 2016. There just was no full-fledged BaaS project with a bunch of integrations in its architecture that would make it possible to acquire, pay for third-party services, take a loan or authorize remotely. Each integration had to be embedded separately and manually. And for each, there would be an added cost. It would increase greatly both the cost of the project and the future costs of services, which put the entire business model of the bank under attack.

But here comes the plot twist. In the middle of our negotiation with the client, our hero emerged — one of the international banks represented in Ukraine. It stated that it sees its future as an Open API banking, and promised to implement the technical task provided by the client by mid-2017. 

This moment erased the last doubts and became the starting point of our cooperation.

Expectation

Product performance

Deep banking experience was our clients’ main strength. This expertise complemented us perfectly and during the time of our cooperation, we managed to learn a lot of useful information and industry insights from them.

Through the research, analysis, and negotiation process we discovered an important measure: project BEP will come after 250,000 sold cards with an average usage volume of 18,000-22,000 USD per year.

These figures became a great motivation for our team as we realized the product should contain enough well-developed functionality for the client to have an urge to spend his money within our ecosystem.

Deadlines

The first-discussed deadline was early 2017. At that time public release should have been conducted. That meant we had around 8 months to develop a product.

But time frames for integration from the partner bank made significant adjustments to our plans. We realized we weren’t able to have a bank card as a product even in the middle of 2017. And this influenced all our plans and expectations a lot. 

Budget

The budget wasn’t the main factor from the beginning of our acquaintanceship with the projects team. It wasn’t the aspect that would determine whether we could collaborate or not. But we still had to make it as coherent as possible in the first stages.

As we didn’t get the clear technical task or PRD (product requirements document), we developed a kind of it by ourselves. It resulted in a simple WBS document with a general assessment of epics and modules, that we developed using the three-point method. This made us understand the approximate budget numbers better, while clearly acknowledging that the final budget for the product development and launching will appear much later when the Discovery session will show its results. 

Devlight’s service

As time went by and our cooperation got closer, our role in this project transformed from a simple mobile application contractor to a full-fledged partner. Our responsibilities had expanded to defining the product vision and forming the roadmap while being responsible for the design, development, and quality of the product.

And the client operational team had the chance to focus more on legal, financial, and banking issues to ensure a successful product launch.

So, after our final handshake, we got to work and distributed our responsibilities like that:

Our solution 

Research & preparation. Series of meetings with the client

At the beginning of summer 2016, we discussed all the important questions, shook hands, and got to work. Our first big task was to develop a specific product roadmap for the next 3 years. As we went through that process, we were guided by the following criteria:

• the first version of the product should be released no later than the end of January 2017
• there will be no bank card in the first version since the integration with the processing of the partner’s bank will not take place yet
• the back office processes were too undeveloped to launch to a large audience
• most product hypotheses were untested on the target audience

We received clear user personas from the marketing partner of the project. And with them, we received a list of untested hypotheses. So working with them both became task #1 for the Devlight product team at the first stage of the project.

Together with the client team, we conducted some user studies and surveys to find out what the potential target audience thinks of the so-called «Antibank» product, and what are their main headaches and motivations. 

Through the survey we discovered that: 

• clients were not ready to entrust their finances to a newly created service without a recognizable brand
• as banks weren’t digitalized at all at the time and users didn’t have experience with it, they had great difficulties in using their bank cards online
• the client wanted to use several cards from different banks at the same time, without choosing just one bank
• web-oriented PSP services were more convenient for the user than a mobile application

The further we progressed, the more obvious the conclusions became.

To make sure we chose the right path, we conducted a deep competitive research of similar projects in Europe and Ukraine according to the following parameters:

• analysis of the declared value proposition and analysis of brand values
• analysis of features quantity and quality 
• competitors’ heuristic design audit
• analysis of user journeys and feedback on the Customer Experience of users
• analysis of competitive advantages of projects

Solution hypothesis and internal discussions 

As a result of competitors’ research and surveys we received the following hypotheses:

• Since the integration with the partner bank will be ready only after a year, there is a sense to launch the first version of the product in the form of a Web App – PSP service with the ability to use cards of different banks
• the product value of the MVP version is the largest number of online financial services in one resource. All insurance providers, all utility payment providers, telecom and internet companies, schools, kindergartens, online games, and even government services are on one platform.
• the mobile application will be efficient when there are at least 100,000 active users on the platform and integration with a partner bank is implemented
• the product should solve most of the current customer pain points associated with the daily use of the bank

Proposal structure and Final discussion with the client 

The next step was to finalize the vision of the product development process. To do that, three meetings with the client were held. And here’s what we got in our product roadmap as a summary:

Stage 1: Build a web PSP for rapid market entry and testing of the processes and team. Carrying out most of the integrations with partners who provide financial services.

Stage 2: Testing of the integration with the bank, issuing a test bank card

Stage 3: Building a full-fledged neobank mobile application with its own card inside the product

Stage 4: Searching for a partner bank with a license that covers the countries of the European Union, and who may provide licenses for other countries in the future

Stage 5: Iterative-incremental product development process, with a focus on the mobile application.

Finally, we agreed on the strategic direction of development and were able to dive into the work on the actual digital product creation.

The process of value creation 

Creations of web solutions and used approaches

Right after proposal approval, we began with the implementation of the first stage of the product — the creation of a web app.

Here is what the process of web app development looked like:

1. Collecting and ordering all existing ideas through ideation sessions with the client.
2. Conducting 25 in-depth customer interviews to understand the current customer experience, their pains, and problems when using similar services.
3. Creation of the VPC, based on customer jobs, pains, and gains. Designing services that solve client problems and pains, as well as additional motivation to use the product.

1. The next step is designing a customer journey map. It helps thoroughly understand the customer’s journey throughout the service and the value of the product. Here we used the framework proposed by Alexander Osterwalder in his book [add description]
2. With a ready VPC, a list of services that we are planning to provide to a client, and a CJM, we started with forming a list of product requirements.
3. First, we systemized the backlog and brought it to a logical and orderly form. [add an image of the backlog, and add a story about filtering backlog using the Kano model]
4. Then we developed user stories and acceptance criteria for all the features. The whole team worked productively and precisely on the development of edge cases for each user story. It was crucial to consider every little point of this process.

Backlog is ready? Great. Now is the time to formulate business requirements for each user story and feature to which they belong.

Usually, we go with the following approach:

Each feature is being discussed in detail with the expert from the client side, we determine all possible states of each user story. Then, for a better understanding of features work within the system, we design the BPMN process for each user story.

After that, we work with each BPMN element to look for necessary data that will be received and sent during the interaction of the end user with the product. Once this work is completed, the technical team begins to design the system Data Flow diagram.

User interface development was the next step in the Nolimi bank project.

We usually use the three-stage approach to work with interfaces in the process of product development.

1. Design of black and white high fidelity prototypes
2. Usability tests of black-and-white high-fidelity prototypes with users carrying out. We do this to avoid the problem of a complex or incomprehensible interface for the client even before the start of work
3. Design system and UI product creation

Before moving forward, let’s look closer at the design system development. We needed to make the user experience of interacting with the system as uniform as possible, as we kept in mind that there will be a mobile app following the web version. That is why at the very beginning of the web solution development, we created a uniform design system that will be a solid base for all future additional apps, products, and services. 

And black and white prototypes were used for fast feedback receiving both from the client team and the end user. The process looks like this: the team of designers and business analytics conducts their own research and develops first sketches, that are based on user stories and BPMN which were developed in the previous stages. We work on the creation of high-fidelity wireframes using one-week sprints. At the end of each sprint, we have a team demo on Fridays, and the client takes part in them too. This allows us to get quick feedback and move faster. The VA team, which accompanies the process, moves one or two sprints earlier to prepare the necessary information and artifacts on time.

As soon as the prototypes are ready and approved by the client, we move to user testing. To do Nolimi bank user testing, we used the Maze service. Through the service, we can understand whether the prototype is simple, intuitive, and easy to use for the end user. To do so, we conduct 3-4 consecutive iterations of testing with 20-25 users until all edits are made and there are no more comments in the focus group. At this point, the prototype is ready, and we can move forward.

Above we talked about design system development. But we weren’t the only team that was engaged in the process. In the Nolimi bank case, the client hired an outsourced marketing agency that we worked closely together. Their team consisted of a digital marketer, a brand designer, a brand strategist, and a copywriter who was responsible for the tone of voice and all the texts of the platform.

As they did their part, we received from them the brand book and instructions for its implementation. And right away we began with the final design system creation and development of the final color screens of the web app.

The next stage of the development process — the project architecture design and its development plan — was within the scope of our client’s competencies. From our side, they needed the following requirements and wishes regarding the process:

1. UX-driven API design, based on our prototypes
2. The microservice architecture of the project with the principle of a thin client on the frontend and heavy logic on the backend
3. Using AWS as an infrastructure provider with mandatory use of Docker for virtual scaling of the system under load
4. Angular as a language for Web programming, Java as a language for backend systems

We prepared for the beginning of the project development stage for 3,5 months. We used the principle of two-week sprints during the development process, and it showed an excellent result.

Our development team consisted of:

• solution architect
• DevOps
• 2 Java Devs
• 2 Angular devs
• AQA + QA
• UX/UI designer for support purpose

4 months — that’s how long it took to develop the solution. And at the beginning of February 2018, the project was released.

A lot of testing: manual, loading, and security was carried out in the middle of January. We used previously prepared test cases and security checklists. As soon as we were in the green testing zone, the in-house team of marketers entered the game.  And traffic poured into the resource.

At this stage, our work was done. We took a 4-month pause until the beginning of the next stage which is mobile application development. But until then, we could breathe out and take some rest work on other projects. 

How did we come to a mobile application creation and what roadmap did we create for its development?

At the beginning of summer 2018, it was clear that our partner bank was ready with all the planned development it assigned for. It meant that we could start with the integration process for issuing our own plastic and virtual card.

Finally, it was time to create a mobile application.

At the very beginning of the development process we understood that to succeed mainly we needed to focus on three directions of work:

1. Study analytics and conduct CusDev of the current web solution, which at that time already had about 85,000 active users.
2. Conduct a VPC session for the mobile application.
3. Check all ARIs provided by the partner bank, conduct all defects tests and tests for compatibility with our system

The first two stages were our responsibility, and the last one was the responsibility of the on-site team.

We invited the client team to have a 5-day workshop with us. This work allowed us to determine the value proposition of the mobile application and to plan its launch.

The discovery part of the Nolimi bank development. How did we find the pains and solutions for the target audience?

Trend Canvas filling in was the first task for the client team as they arrived at our office. It’s a framework that allows teams to quickly synchronize with the external environment around the future product, review competitors, and ideas on the market, and define our focus.

In the process of Trend Canvas filling in and discussion we understood, that the previous concept is the right one and we should move in the direction of creating a full-fledged neobank.

Here are challenges that stood in our way at the moment: 

1. The client’s team did not have a sufficient liquidity pool and willingness to work in the credit business. It meant that there won’t be loans on our product. This forced us to look for an alternative business model for monetization.
2. The ARI methods of the partner bank were far from ideal, which meant the absence of 40% of the discussed functionality in the first releases of the application.
3. A large-scale release of the neobank Monobank was supposed to take place in Ukraine at the end of 2018. It created considerable competitive pressure on our team. (The release was successful and Monobank became the absolute leader in the Ukrainian market with more than 4 million customers on board)

A lot of creativity was required from us to bring enough value to customers from the very first release, thereby keeping the customer in our product.

The next day we started discussing the value proposition of the mobile app as well as determining which problems will have to be solved in the first release.

As was stated above, we used Osterwalder VPC while working on the project. Its beauty and specialty are that, if done right from the start, you can identify most customer problems and design services to solve them.

Before starting with VPC, we made a questionnaire with several questions, and after it was ready we made about 50 blitz calls to current customers of the web application to learn more about their experience, motivation, service problems, and expectations for new products and services. The majority of customers were satisfied with the service. They also were interested in the possibility of continuing to use it as a mobile application.

But they also outlined some problems:

1. The absence of the company’s mobile application, for quick and convenient use of the service on smartphones
2. The need to attach cards of other banks, and constantly go through the 3DS procedure during the payment process
3. High commissions due to the use of cards from other banks
4. No consolidated cost analytics or it was not convenient enough

After we carried out the survey and got all the needed information from customers, we structured this information and entered it into the appropriate part of Canvas for further processing.

Then we conducted a one-day VPC workshop and identified the value of our product as follows:

1. Neobank, with its own virtual and plastic card. Emphasis on convenience and the ability to pay for almost any services in the country, including most of the services provided
2. Ability to issue and delegate up to 4 prepaid cards to your relatives or other persons if necessary
3. Ability to add cards of other banks to the product by analogy with the web app, i.e. card wallet
4. Free basic card package and application.

Having approved the VPC with the client, we moved on to the next stages of discovery. They were similar to the stages of creating a web service. But let’s take a quick look at them:

• customer journey map design to determine all the nuances of the customer’s journey during service receipt
• backlog formation, sorting, and prioritization for the first release
• development of user stories and acceptance criteria
• BPMN design, collection of all business requirements for all states of functionality in a mobile application
• design and usability test of a black and white prototype of the application
• designing an API based on a black and white prototype of the application in the Postman API product
• creating an application design using a ready-made design system
• determination of the technological stack of the mobile application, selection of the marketing stack of third-party services for integration into the application
• finalization of the technical task for product implementation
• product development, testing, and launch

And the last few important points that required special attention throughout the process were:

1. Mobile application analytics
2. Customer journey map orchestration system in a mobile application
3. Technological stack and other useful services
4. Project management approach

Results and Outcomes 

Process of solution launch and going live

In the spring of 2019 testing of all system and services were completed and we were ready for public release. The marketing team did a lot of work to prepare for the project release and the start of communication. They developed highly effective funnels for attracting customers to the mobile application and designed an excellent onboarding session for new users.

The result spoke for itself. On the first day of launch, 2,000 cards were opened and we received more than 6,800 product downloads. We expected a large flow of customers, but not that big. So, half of the client’s team worked in two shifts during the first three weeks. This critical situation forced them to acquire a new qualification as they had to combine their core functions with the functions of call center operators, thereby helping users throughout their product journey.

After three weeks of frantic work, more support managers arrived and the flow of clients stabilized. Finally, it’s time to breathe a sigh of relief. And open the champagne bottles 🙂

Conclusions

Retrospective

Analyzing the Nolimi bank case from today’s perspective, we can outline the weakest link in the chain — the partner bank. It constantly refined/reworked the API methods on the go, often without informing us at all. It was the biggest problem that accompanied us during the entire process of developing the mobile application.

The bank had a lot of limitations that influenced our work. They created limitations in the design of UX that deprived us of the opportunity to create the best possible user experience for our users.

Final results

As always, we made conclusions out of the story of difficulties working with the partner bank. And not only conclusions but also a plan on how to avoid such problems in the future. We developed a clear system of constant automatic monitoring of all API methods, versioning of documentation, and updating of automatic smoke tests for keeping the service working correctly. It was important for us to work at the SLA level of 99.99, which forced the team to instantly respond to any change on the part of the bank. We have successfully scaled this experience to all our other projects so far.

At the end of 2020, the entire project was sold to a large European banking group to increase its presence in the growing Ukrainian market. 220,000 cards were active in the project at the time of sale. And after the sale features like credit and installment were added to the service, which opened new prospects for product development.

For three years we’ve been interacting with the clients’ team. We managed to build a strong relationship where all the problems were solved through joint discussion and joint development of a solution. The client team was satisfied with working with us, as well as we were satisfied with working on the project, despite many difficulties and limitations. And, since the project is fully monetized, we consider the result more than successful 🙂