Better do it yourself: how we made the Perekrestok.ru inhouse mobile app
In this post, we will outline the features of outsourcing and inhouse application development, as well as talk about the details of the platform. Then we will try to come back in new articles and tell about our design, backend device and version development for iOS and Android.
Where did we start
What was inside and how it worked // Semyon Matsepura, head of the mobile development group of the online supermarket Perekrestok.ru
Since the launch of Perekrestok.ru, orders have been issued through the My Crossroads application, it combines the range and services of both a retail network and an online supermarket. Since January 2020, we began developing a new application called “Online. Crossroads”, while supporting the current one. First of all, house teams were selected and concepts developed: from the idea to the approved features.
Several months of work went into a more detailed study of the inner kitchen (especially retail, logistics, all kinds of promotions and bonus programs), we tried to take into account and optimize everything we reached before. New mobile APIs were written taking into account the operation of the applications (because from the outside it seems that both the site and the application were created to select goods and purchases, which means that they work almost the same way, but this is not entirely true).
If you initially spend time and develop the right API at the start, you can significantly speed up the development process. And we’ve also set up the work of requests, the mobile API is a contract work, it is very important how requests will be sent and answers will be received. Many days were spent choosing the best solution. Yes, of course, the backend team is actively moving towards using microservices.
It so happened that we approached the creation of a new application from several sides at the same time and began to remodel both backing and mobile applications (iOS and Android) in parallel. While the backenders are redoing everything inside, the mobile development team worked on the architecture, the designers continued to create the design system, and the marketers evaluated the competitors and made conclusions about the functionality of our application.
When creating a new application, we tried to develop its architecture as detailed as possible, to take into account even the smallest details in order to provide its simpler support in the future and to get a high-quality product at the output.
Inhouse vs Outsource
How we assembled teams for the product // Elena Tikhonova, Head of Mobile Applications
Companies often have a choice – to use their own resource when developing some applications and services, or to write a clear technical specification and safely outsource everything. In principle, this often depends on the specific task. Once and for all, to say that the house is cooler than outsourcing (or vice versa) is impossible. After all, there are situations when it’s quicker, easier and cheaper to quickly connect a third-party team to create a product than to detach full-time IT specialists, whose time is now more important for the company and costs more. Usually this is the creation of some one-time, promotional resources. It took you a landing only for a certain holiday – outsourced it, they did everything for you, the holiday passed, put the landing on the table. All. Exceptions are rare, but there are, for example, we really liked the work style of a specific person from outsourcing, and we continue to work with him now, he fit into the project well.
But if it comes to something more complex (and long-playing), requiring new integrations, constant support, then here the house becomes faster, cheaper and safer. It’s better to do something once and maintain it, than to remake services from scratch from time to time. However, if you had other examples in practice when outsourcing is actually better, please write in the comments.
When you have tight deadlines, you need people who are motivated by the product itself and will not be sprayed onto something else, be it additional freelance or deadline from other clients of the outsourcing company. Yes, with an inhouse it is important to gain a critical mass of developers. Because when you (like) have a department that is almost-almost staffed, but you still have to outsource someone for the tasks, it’s hard to consider a pure house. For us, such a necessary minimum fit into 5 people for each platform + 2 system analysts + 3 managers + 2 designers + 2 testers + 4 people from the backend team. Total 23 people.
We gathered our teams both with an emphasis on the professional skills of the guys, and on making them truly comfortable working together. Soft skills pay even more attention at times. Now the team is only increasing, and its old composition does not change.
If you also make a retail app
With all the features // Maria Timofeeva, product director of the online supermarket Perekrestok.ru
We have a couple of tips for you. Firstly, as mentioned above, try to make sure that the architecture and the entire internal structure of your application are laid down by the inhouse team. If you connect outsourcing at the start, you will have to jog along the rake vigorously, and then, with a high degree of probability, you will redo everything all over again. Or you will not redo it, but you will spend a lot of resources on full support.
Secondly, for the sake of speed of releases, you can skip some side steps of user scripts. To save time, it makes sense to release a feature in a slightly simpler form than you intended. And then screw up to full implementation. For 4.5 months we released an application that included all the functionality of the web version. Let in the basic form, but – all.
Look at the example of our application. In our case, the user’s path is a purchase. The flow associated with this should be worked out as detailed as possible: selecting products, adding them to the basket, and placing an order. But all sorts of things, even important for the service, such as a convenient scale for evaluating orders, they are also needed, but their study can be minimized. Return to this later, when all the main thing is done.
It is precisely because of this that we are often reproached for the fact that there are cards in the interface on which there is very little information about the product – price, photo and name. Like, some other food delivery applications have huge cards where you can view the product in full detail, including the degree of transparency of the fish scale and the weather like on the day of the grape harvest for wine.
So, in a similar way, you can approach the design in the event that you have few headings themselves. Fewer positions – more space for their display and information about each. But we have, quite frankly, enough positions. Therefore, the interface has screens with which the user orders the most familiar and often purchased products. In this case, it is usually important for him to simply understand that the product is in stock and quickly buy it. Therefore – a minimalistic card that fully performs its function.
Thirdly, and this, most likely, applies to any application with payment for orders, and not just for retail as such. Add support for Apple Pay / Google Pay and more. This is more important than it seems. Your application should have a good checkout page, which allows you to once again unobtrusively check, and correct errors if necessary, and quickly add the right product. Here it is important to consider that the number of loaders is minimal. Who likes when the screen freezes when adding a new product to the basket and you can’t scroll further?
Fourth, design. Study the user’s path and make it convenient for him first of all on this path. We convened several design consultants, and they cheerfully began to advise us as needed. They advised, in general, interesting things – wildly beautiful solutions, on the most modern stack, using all the fresh visual approaches.
The problem was that in the end it would have turned out an application with a bunch of beautiful pieces, maybe it would have taken even a couple of design prizes and in general. But the user would just be uncomfortable using it. He also comes to the food delivery application to order food, and not be inspired by great graphics and learn new technologies for mobile live. As for me, a story when design is put higher than functionality for the sake of design is a bad story.
And to make good functionality = know your product well. We brought together the CJM site, the mobile version and the old version of the application, took all the negative reviews with details, saw what people did not like, where the difficulties were, and tried to take this into account.
We’ll try to write a separate article about application design.
New application
Here is what we got as a result:
We welcome feedback, criticism and comments.
