How we made a mobile application 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 avoid mobile platforms: the share of smartphone users among Russians accounted for 67% of the total number of mobile phone users. An internal study showed that 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 simultaneously recruit a development team: we were limited in resources, and we wanted to get the application as soon as possible.
')
Outsourcing development turned out to be expensive and unwieldy, there was no one inside the company to keep track of the external development team, after publishing the app 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 outsourcing was abandoned in favor of a small team of android developers within the company consisting of two people at the beginning.
Projects on the outsource, in addition to poor quality, are fraught with other problems.
The application from the outsourcers predictably came in a disgusting state, there was no architecture in it, in principle, there was a feeling that it was done by junior on the knee for three months. In the application class, the developers found a completely magical comment, the censorship version of which sounds something like: "API is g *** oh, we’re getting out of here." Then the API changed about once every two weeks and few people liked it: it was difficult to maintain, business analysts did not report changes, the backend was also not very willing to share what was happening.
According to the history of commits, it was clear that the dudes made him more or less well-versed, but we won’t find out why the application turned out so bad.
We started 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 existed for 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; one.
The scheme of interaction of application components
After launching in Kazakhstan, it became obvious that the number of countries would only grow and it would be very difficult to maintain, it was decided to make a common framework. Here we made an evolutionary mistake: in this framework, we pulled everything that applications had in common. 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 moment are very different. Began to remove something from the framework, transfer back to the packages, sometimes redundantly. Now in the balance application, when the framework makes sense and contains everything that applications have in common in different countries, and in an application for each country, you can easily change something without resorting to rewriting. The biggest challenge for our framework was the launch of two countries at once in one month, which it 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 it corresponded to the guidelines, was outdated 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 implemented will be Spain.
A design system is also a framework that is responsible for UI and does not apply to business logic. The design system pattern does not imply the use by the developer of elements that live outside it. If a developer suddenly wants to make a button of 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 be available for all applications in the system. Thus, the developer will not be able to bring dissonance into 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 backend, front-end, design staff, 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 not “by process”, such updates are sometimes skipped in the sprint.
From the unpleasant - we practice Forced update, which does not allow the user to use the application until he updates it to the latest version. We use this when the API changes and some application functions may stop working. From the backend side, the system is very large and maintaining compatibility of all API versions is expensive.
The plans include the launch of the Moneyman application in another country and the introduction of a system design for Moneyman applications in all countries.
Why outsourcing is not suitable
At first, it was decided to outsource the development of the application and simultaneously recruit a development team: we were limited in resources, and we wanted to get the application as soon as possible.
')
Outsourcing development turned out to be expensive and unwieldy, there was no one inside the company to keep track of the external development team, after publishing the app 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 outsourcing was abandoned in favor of a small team of android developers within the company consisting of two people at the beginning.
Projects on the outsource, in addition to poor quality, are fraught with other problems.
The application from the outsourcers predictably came in a disgusting state, there was no architecture in it, in principle, there was a feeling that it was done by junior on the knee for three months. In the application class, the developers found a completely magical comment, the censorship version of which sounds something like: "API is g *** oh, we’re getting out of here." Then the API changed about once every two weeks and few people liked it: it was difficult to maintain, business analysts did not report changes, the backend was also not very willing to share what was happening.
According to the history of commits, it was clear that the dudes made him more or less well-versed, but we won’t find out why the application turned out so bad.
What we fixed
We started 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 existed for 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; one.
The scheme of interaction of application components
After launching in Kazakhstan, it became obvious that the number of countries would only grow and it would be very difficult to maintain, it was decided to make a common framework. Here we made an evolutionary mistake: in this framework, we pulled everything that applications had in common. 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 moment are very different. Began to remove something from the framework, transfer back to the packages, sometimes redundantly. Now in the balance application, when the framework makes sense and contains everything that applications have in common in different countries, and in an application for each country, you can easily change something without resorting to rewriting. The biggest challenge for our framework was the launch of two countries at once in one month, which it 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 it corresponded to the guidelines, was outdated 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 implemented will be Spain.
A design system is also a framework that is responsible for UI and does not apply to business logic. The design system pattern does not imply the use by the developer of elements that live outside it. If a developer suddenly wants to make a button of 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 be available for all applications in the system. Thus, the developer will not be able to bring dissonance into 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 backend, front-end, design staff, 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 not “by process”, such updates are sometimes skipped in the sprint.
From the unpleasant - we practice Forced update, which does not allow the user to use the application until he updates it to the latest version. We use this when the API changes and some application functions may stop working. From the backend side, the system is very large and maintaining compatibility of all API versions is expensive.
Moneyman app now:
- launched in 6 countries
- the number of installations of the application tends to 500,000
- average application score - 4.6.
- More than 8 thousand reviews in the Russian side
- A team of five developers is working on the application.
The plans include the launch of the Moneyman application in another country and the introduction of a system design for Moneyman applications in all countries.
Source: https://habr.com/ru/post/419397/
All Articles