How we made a mobile app for six countries
The flagship project ID Finance is an online alternative lending service MoneyMan. He works in seven countries - Poland, Spain, Mexico, Brazil, Georgia, Kazakhstan and Russia. When we first launched it in Russia in 2015, we could not ignore mobile platforms: the share of smartphone users among Russians was 67% of the total number of mobile phone users. As an internal study showed, 80% of customers used smartphones on the Android platform, the choice of platform for developing the first application became obvious
At first, it was decided to outsource the development of the application and at the same time to recruit a development team: we were limited in resources, and we wanted to get the application as quickly as possible.
Development outsourcing turned out to be expensive and slow, there was no one inside the company to follow the external development team, after publishing the app’s rating in the store was frighteningly low - 1.2 out of 5. Everyone was dissatisfied: both customers and business. It was necessary to change something and the outsourcing was abandoned in favor of a small team of android developers inside the company, which at the beginning consists of two people.
Projects on the outsourcing, in addition to poor quality, are fraught with other problems, the
application from the outsourcers predictably came in a disgusting state, it lacked architecture in principle, there was a feeling that it was done by a junior on his knee in three months. In the application class, the developers found a completely magical comment, the censored version of which sounds something like: “API - g *** oh, get it out of here.” Then the API changed about once every two weeks, and few people liked it: it’s difficult to maintain, business analysts did not report changes, the backend was also not very willing to share what was happening with them.
From the history of commits, it was clear that the dudes did it more or less knowledgeable, but we won’t know why the application turned out so bad.
We began to remake the application and made a separate layer, which is solely responsible for network interactions. This made it possible not to rewrite half of the application for minor changes. We have successfully implemented the architecture on which the Moneyman application lasted three years without any problems. It is no longer relevant, but still alive, and then it allowed us to expand rapidly, in 2016 from one country to two (Russia and Kazakhstan), and in 2017-2018 the application was launched in four more countries, now it is planned to launch another one.
Application component interaction diagram
After the launch in Kazakhstan, it became obvious that the number of countries will only grow and it will be very difficult to maintain, it was decided to create a common framework. Here we made an evolutionary mistake: in this framework we pulled everything that was common between applications. Yes, packages for countries have become light and thin, but we are faced with the fact that our business in different countries is developing very differently, and the features of applications at one point are very different. They started to remove something from the framework, transfer it back to packages, sometimes redundantly. Now in the application there is a balance, when the framework makes sense and contains everything that applications in different countries have in common, and in the application for each country you can easily change something without resorting to rewriting. The biggest test for our framework was the launch of two countries in one month, which he successfully passed. This was largely due to the fact that a significant part of the functionality was implemented in the framework.
The existing design solution, although consistent with guidelines, was obsolete and did not correspond to modern concepts of design. So there was a component design system. Now it is in the process of development, the first country in which the design system will be maintained will be Spain.
A design system is also a framework that is responsible for the UI and does not concern business logic. The design system pattern does not imply the use by the developer of elements that live outside of it. If the developer suddenly wants to make the button a slightly warmer shade of orange, he will have to add this button to the design system and go through all the stages of coordination with this button and only after confirmation will this button become available for all applications in the system. Thus, the developer will not be able to dissonance the appearance of the application and all applications in the ecosystem will be consistent.
The screen on the left is the old application for Spain, on the right is the new one. At first glance, it may seem that the changes are cosmetic, but the design system will allow us to maintain the consistency of all Moneyman applications without much effort.
Unfortunately, a full-fledged design system is quite an expensive thing, and can result in a separate project, with its own backend, frontend, staff of designers, etc., but even with limited resources, it works well.
We update applications as needed. Sometimes every two weeks. But often the changes concern only the backend, and, although this is “off-process”, such updates are sometimes skipped in the sprint.
From the unpleasant - we practice Forced update, which prevents the user from using the application until he updates it to the latest version. We use this when the API changes and some functions of the application may stop working. On the backend side, the system is very large and maintaining compatibility for all versions of the API is expensive.
The plans include the release of the Moneyman application in another country and the introduction of a system design for Moneyman applications in all countries.
Why outsourcing doesn't work
At first, it was decided to outsource the development of the application and at the same time to recruit a development team: we were limited in resources, and we wanted to get the application as quickly as possible.
Development outsourcing turned out to be expensive and slow, there was no one inside the company to follow the external development team, after publishing the app’s rating in the store was frighteningly low - 1.2 out of 5. Everyone was dissatisfied: both customers and business. It was necessary to change something and the outsourcing was abandoned in favor of a small team of android developers inside the company, which at the beginning consists of two people.
Projects on the outsourcing, in addition to poor quality, are fraught with other problems, the
application from the outsourcers predictably came in a disgusting state, it lacked architecture in principle, there was a feeling that it was done by a junior on his knee in three months. In the application class, the developers found a completely magical comment, the censored version of which sounds something like: “API - g *** oh, get it out of here.” Then the API changed about once every two weeks, and few people liked it: it’s difficult to maintain, business analysts did not report changes, the backend was also not very willing to share what was happening with them.
From the history of commits, it was clear that the dudes did it more or less knowledgeable, but we won’t know why the application turned out so bad.
What we fixed
We began to remake the application and made a separate layer, which is solely responsible for network interactions. This made it possible not to rewrite half of the application for minor changes. We have successfully implemented the architecture on which the Moneyman application lasted three years without any problems. It is no longer relevant, but still alive, and then it allowed us to expand rapidly, in 2016 from one country to two (Russia and Kazakhstan), and in 2017-2018 the application was launched in four more countries, now it is planned to launch another one.
Application component interaction diagram
After the launch in Kazakhstan, it became obvious that the number of countries will only grow and it will be very difficult to maintain, it was decided to create a common framework. Here we made an evolutionary mistake: in this framework we pulled everything that was common between applications. Yes, packages for countries have become light and thin, but we are faced with the fact that our business in different countries is developing very differently, and the features of applications at one point are very different. They started to remove something from the framework, transfer it back to packages, sometimes redundantly. Now in the application there is a balance, when the framework makes sense and contains everything that applications in different countries have in common, and in the application for each country you can easily change something without resorting to rewriting. The biggest test for our framework was the launch of two countries in one month, which he successfully passed. This was largely due to the fact that a significant part of the functionality was implemented in the framework.
Design system
The existing design solution, although consistent with guidelines, was obsolete and did not correspond to modern concepts of design. So there was a component design system. Now it is in the process of development, the first country in which the design system will be maintained will be Spain.
A design system is also a framework that is responsible for the UI and does not concern business logic. The design system pattern does not imply the use by the developer of elements that live outside of it. If the developer suddenly wants to make the button a slightly warmer shade of orange, he will have to add this button to the design system and go through all the stages of coordination with this button and only after confirmation will this button become available for all applications in the system. Thus, the developer will not be able to dissonance the appearance of the application and all applications in the ecosystem will be consistent.
The screen on the left is the old application for Spain, on the right is the new one. At first glance, it may seem that the changes are cosmetic, but the design system will allow us to maintain the consistency of all Moneyman applications without much effort.
Unfortunately, a full-fledged design system is quite an expensive thing, and can result in a separate project, with its own backend, frontend, staff of designers, etc., but even with limited resources, it works well.
Updates for Updates
We update applications as needed. Sometimes every two weeks. But often the changes concern only the backend, and, although this is “off-process”, such updates are sometimes skipped in the sprint.
From the unpleasant - we practice Forced update, which prevents the user from using the application until he updates it to the latest version. We use this when the API changes and some functions of the application may stop working. On the backend side, the system is very large and maintaining compatibility for all versions of the API is expensive.
Moneyman app now:
- launched in 6 countries
- the number of application installations tends to 500,000
- The average app rating is 4.6.
- More than 8 thousand reviews in the Russian store
- A team of five developers is working on the application
The plans include the release of the Moneyman application in another country and the introduction of a system design for Moneyman applications in all countries.