Uber-like apps have been gaining immense popularity over the last few years which gave rise to a lot of startup businesses that are now calling their apps "Uber for X". The name entails that the services operate in the same manner as the popular app but not necessarily in the same field. We worked on an Uber-like startup that ended up being very successful in its area of expertise. It was a nontrivial but all the more interesting case for our team.
Our client already had a system in place when they contacted us to develop a new, more complex and refined version. The system is designed as an uber-like service for trash hauling where a client creates a job with photos of the trash they no longer needed and haulers come in to take it away. The start of the project was quite challenging:
Since the live product called for improvement, it was decided to make the development process as quick as possible to replace the current product with a new one.
The new ecosystem was planned to be much bigger than the first one. It consisted of many parts:
While developing this huge system with many different parts that had to be perfectly tuned with one another, we used the following technologies and practices:
When starting the project, we considered two types of architecture: monolithic and microservice. While using monolithic architecture was cheaper, easier, faster and required less support post-launch, after taking potential business growth and future expansion into account, it became clear that monolithic architecture is not flexible and scalable enough. Thus, we decided to use microservice architecture based on AWS: since we would have many atomic services instead of one huge backend, changing one service would in the worst case lead to this service’s failure, without affecting the whole system.
Moreover, we used Elasticsearch for data indexing since ELK stack (Elasticsearch, Logstash, Kibana) are already integrated into AWS: it is cheaper and faster than copying data into Postgres and sorting it from there.
The chosen stack of technologies allowed us to set up automatic data migration.
The original app was developed on native iOS and Android platforms so with the app we had a choice either to stick to this approach or move the app to a cross-platform framework.
The 2.0 version was suitable for a cross-platform solution for the following reasons:
Apart from that, cross-platform framework had some advantages that we could really use for this project such as:
Having taken all that into account, we decided to develop the app with React Native. We also decided to pair it with Expo framework that allowed us to update the apps via the air without resubmitting them into stores, saving us a great deal of time. At the time, the Expo framework was still in quite a raw state and its maintenance took additional development and testing time. However, the benefits of being able to update the app via the air far outweighed the disadvantage of supporting and maintaining the framework that has become far more complex now than what it was when we started.
The original app 1.0 utilized Twilio for sending messages so we decided to use it as well when developing multi- and single-channel chats for haulers and clients. Twilio processes the messages on its servers and then sends them to the recipient. However, when we started working with Twilio, it turned out that we needed content filtering in chat messages that the service does not provide from the box, so we had to develop this functionality and integrate it ourselves. We filtered potentially harmful and non-related photos, profanities and information that was not meant to be revealed until the job has started: for example, the client’s address.
Another Twilio restriction we had to deal with was the channel limit. After the job was done, we did not delete the chat so that app's support team would have the messages on hand if an argument arises and that led us to reaching a limit quite fast. We dealt with the problem in the following way:
During the development, we stuck to DevOps approach, namely:
This project included API service, 3 web-apps and two versions of mobile apps. The development involved many specialists, and every two weeks there was a scheduled release, so the DevOps approach with its aim at speed and quality proved to be the most optimal for this type of project. It is extremely effective when it comes to standardizing development infrastructure, automating testing and releases, and shortening the failure reaction time and system restoration period.
The app has the following notable features:
The system was released in 2018 in AppStore and Google Play and we continued active development with various improvements as the company became more aware of what customers needed for the process to be more convenient.
Currently, the trash hauling app is in a support stage: we help our clients with whatever they need, be it a fix, a change or a brand new functionality improvement. We managed to develop a big uber-like ecosystem in a relatively short period of time while supporting the first iteration we knew nothing about when the project started.
This project is an amazing example of a startup that did not stop once gone live: the company analyzed the flaws their first product had and vastly improved on them, opting for the second, more fleshed out and complex iteration. We think it is very inspiring for people in general but for startups specifically, and we are very proud to have been a part of such an outstanding project.