Case Studies

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:

• We had to work with the company on developing technical specifications and design for a new system while simultaneously supporting the first iteration that was already in stores and used by people;
• While supporting the existing system, we had to perform intense rounds of testing and code-studying.

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 updated app

The new ecosystem was planned to be much bigger than the first one. It consisted of many parts:

1. Client app — an app for people who have items they want hauled away. They place their order, specifying what category the trash falls into, taking a couple of pictures, marking time and date, and wait for hauler bids to come in. They choose their hauler based on the offered price and their rating;
2. Hauler app — an app for haulers who can see all available jobs on their territory and apply for them;
3. Web Client — a web portal for clients that has the same functionality as the mobile app;

Technologies and Approaches

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:

1. Microservice Architecture

   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.



2. React Native

   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:

   • Simple UI;
   • Business logic that can be generalized;
   • Absence of OS-specific functions such as Bluetooth, camera, particular map interactions.

   Apart from that, cross-platform framework had some advantages that we could really use for this project such as:

   • It shortens the development time quite significantly which is especially important for a quickly growing startup;
   • It allows us to be more flexible and respond to changes faster, testing less than with two separate applications.

   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.



3. Twilio

   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:

   • We log chat messages;
   • We remove old chat channels after the job is done.


4. DevOps

   During the development, we stuck to DevOps approach, namely:

   • Version control that allows to go back to the older iteration if necessary;
   • Auto-building of the apps that allowed us to minimize time between writing code and finding bugs in it;
   • Automatic project set up in a specifically designed environment that replicates production to test the app beforehand;
   • Automatic project setup across the board that was allowed by using Expo framework;
   • Environment configurations are set up via configuration files, not manually;
   • App monitoring for quick treatment of any failures.

   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:

• Interactive map both for a client and for a hauler. The map also shows the optimal route to the client’s location when the hauler starts the job;
• Tracking job statuses in real-time to notify the client of what is currently happening with their order;
• Rating system for both clients and haulers;
• Multi-channel chat managed via Twilio for haulers and client to discuss the details of the job;
• Content-filtering in chat for a more enjoyable experience;
• In-app transactions done via Stripe;

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.