At the beginning of the year, we got an interesting case. In two weeks we made a basic courier application with functional updates without the need to upload the build to the store.
The project turned out to be a classic MVP, the implementation model is suitable for small b2c and almost any b2b projects. If you need a working application on a tight schedule, I advise you to pay attention to this approach. The text will be of interest to project managers and, most likely, it will not contain anything previously unknown to programmers.
A bit of history
VkusVill began to experiment with online delivery last year. For this, a logical business strategy was selected and approved: the development of two different applications, for the client and the collector / courier.
It was convenient, there were few customers, the application load was small: about 100 orders per day, in the process of development - up to 1000.
Then a pandemic began, retail began to reorganize towards delivery everywhere. The client flow increased significantly, there was a minimum of time for changes and approvals - everyone realized that the existing implementation was bad and needed to be changed urgently.
Problems of our implementation
- The apps were Android only. But the pandemic shook all spheres, and couriers from iOS began to come to delivery services.
- The application took a very long time to update, for example, once we got under a seven-day review from Google. It was impossible to optimize the product under these conditions.
The entire network depended on the delivery service during the isolation period, so the main question facing the team was: "What to do with the couriers?" Then we decided to make a telegram bot. Because we know how to use bots .
The increase in the number of orders confirmed the success of the chosen business model. But then we began to run into the limitations of the bot as a platform. In particular, the development had several tasks:
- See the route and all orders on a convenient map
- Be tied to several points of sale at once
- Receive up-to-date information on the status of orders
- , . , , , .
- . telegram : 8 .
- “” - , .
We were covered with flashbacks about the problems with the review. Plus, with a standard approach to development, we would have to go through all the stages of design, design, analysis by the UX editor, layout and assembly. We estimate this would take one to three months and consume resources from the main application.
An interesting fact: in FullStack, four heroes are involved in the VkusVilla front: 2 for iOS and 2 for Android. If you want to keep them company, write to me - kafa@automacon.ru.
Start of development
At that moment we were lucky: we found the guys who told us about the no-code platform Bubble.io. According to them, the application on our requests could be made there in a week. Moreover, they showed exactly how it could function and even passed the test to see if it could work with our rather tricky backend.
To be honest, Bubble seemed like a rather crude technology to me, in terms of the user interface it is a somewhat strange and not responsive system.
But while getting to know it, an idea came up: to use the principle of the platform to quickly create your own application. Because if Bubble can cope with this task, then why can't SPA, for example?
We decided to write a user interface in ReactJS using the Capacitor framework . The project is assembled into an optimized and compressed set of files that are uploaded to a remote server. Capacitor has access to native functions, the application is launched through a WebView, where the URL with the project assembled in ReactJS is specified. According to this logic, the project had to open as a regular site with the ability to call native functions. Surprisingly, Apple has no problem letting technology like this into its app store.
We wrote it, which we passed on to the guys with the Bubble competency and one of our React programmers. It looked rather primitive: we take a design guide, think over a simple UI and put together a front that will carry out all the functionality of the bot.
Each team (if we count our programmer as a team) had 2 weeks to complete the task: based on the guideline, independently create the most simple and convenient application. The developers had to consult directly with the project leader from the business side.
Let me emphasize that we deliberately abandoned the design, design and involvement of an analyst.
Why were there two teams?
In this case, the fact that we work with VkusVill played a role. In their culture, the method of duplicating suppliers is actively used. I was curious to see how the third-party Bubble team would work on the project. Perhaps we could have adopted from them some tricks, management techniques and communication features.
At the same time, I did not have unconditional faith in the success of the application based on the constructor, so I did not want to spend 2 weeks creating one solution.
What happened
First of all, the idea of parallelizing the commands turned out to be very logical: the no-code interface solution somehow did not work out right away.
Since the task of doing according to the guidelines was at once, the implementation somehow demotivated me a little. From the point of view of response, Bubble has an obvious problem: everything is pressed clumsily, often twice. In the process, one more dances with tambourines were discovered: it took the team more than 2 days to replace the "native" Google maps for Bubble with Yandex. Another 1 day - to make the functionality of opening routing through 2Gis. At the same time, the solution turned out to be a crutch: if 2Gis was not installed on the device, it was still offered. In terms of labor costs, the no-code team got a little more than 80 hours (originally this was the limit) while the application turned out to be raw. This was the end of cooperation with them.
The solution in ReactJS turned out to be much more optimal: firstly, the full functionality was completed in 67 hours, and secondly, from the point of view of guidelines and logic, everything turned out to be quite working: The
publication on iOS was successful: there were no questions for the review, the next day the application was in store. We didn't upload Android to the Play Market, we just placed the .apk in the cloud storage.
After the launch, all the advantages of such an assembly became tangible. The application was not ready for full-fledged tests, and updates and improvements are more convenient to do without the need for publication.
Now the application has been working for several months, we have added quite a lot of functionality, made a good Kazdev with couriers. Everyone is happy.
Few conclusions
Surprisingly, the development on bubble.io took longer, and the final product was more crude. The constructor constraint played a significant role here.
At the very beginning, when setting the technical assignment, I drew the teams' attention to the importance of using the guideline with ready-made visual elements: fonts, icons, general style, etc. Despite this, the guys from Bubble got an extremely primitive interface. It is unlikely that the banal "did not have time" could play a decisive role; rather, the fact is that the platform is poorly customizable. If someone can explain the reason, write in the comments.
It may surprise many that we did not know about such a methodology and is already widely used. Nevertheless, it was a revelation for me and I think that it is a very good solution for corporate applications with a small number of Users. The application turns out to be many times more convenient and fundamentally different from the adaptive version of sites, the implementation time is shorter than when working with ReactNative or Flutter, the difference is not noticeable visually.
To summarize, the project seemed like a good challenge for the team, and for me personally, managing it was a great way to take a break from the routine of long, careful and very thoughtful design of "big" tasks.