Uber-Like app

for mechanics and truck drivers

Multiplatform Web and mobile solution for the service industry, helping fleets and car workshops to meet each other on a single platform, similar to how Uber-like services are helping passengers and drivers.

The platform works both ways. On the one hand, It helps to find professional mechanic help for a truck driver if they faced issues with their vehicle while en route, in the form of a pair of mobile applications. The platform is ready to offer 3 different services, including tire change service, tow service, and custom service, where a driver can simply record an audio-recording or attach some photos for better clarify and mechanic will start from the vehicle diagnostics. At the same time, the platform helps for workshop owners and fleet managers by handling tedious administrative tasks such as registering new members, monitoring finances, dispatching orders, tracking employees and contractors progress as a web application.

Challenges

This project contains of dozens of smaller user flows linked to each other, and some of those are quite complex. Many of those flows had required numerous revisions before accepted by the Customer. At the same time, The Customer’s vision regarding particular parts of the system has been changing for the first few months many times, and even previously confirmed pieces were altered afterwards
1
In order to understand how numerous user flows should run and what UI components are more suitable from the business perspective, it was vital to learn who is our target audience and how they plan to use those applications
2
In this project, we had to integrate multiple external systems, such as Firebase and Stripe and different pre-built libraries, like Mapbox. Where some of them required more time, engineering skills and patience, and sometimes the issue was not about the external component itself. For example, we have faced a problem when trying to build a mobile application for mechanics on the Android platform. The Mapbox library, which we have been using for navigation purposes from the very beginning of the project and had successfully used for the iOS version, appeared to be incompatible with the rest of all our Android libraries as-is.
3
One of the technical tasks of the project was to provide the ability for a driver to ask someone to pay on their behalf. That way, a driver could send a payment request through the provided phone number to someone else, which is a more convenient way of paying for services if the driver is not a truck owner but a fleet member.
4
When we started working on the project, the first versions of the iOS mobile applications were already there, built with Objective-C and UIKit by the Customer. However, it was decided to build all the newer pieces of functionality using different tech stack (Swift and SwiftUI, respectively). Which means that the iOS part of the project is currently built with 2 different programming languages, and it is something that needs to be fixed.
5
Even though we had to build only Android application for the drivers first, we understood that Android application for the mechanic must be built too. We had to find a way to shorten time for the Android development and a way for the future synchronization with backend specifications because there are many endpoints in the system.
6
The main business flow in the system implies that there will be some repetitive parts of the business logic and UI components between the mobile applications for 2 main user roles. So we had to design our source code the way it could be reused and worked on by several developers in parallel (on this project we have 3 Android developers working together). We also expected that a lot of testing will take place in the system because our QA specialists will need to cover 4 mobile applications' interaction in total.
7

Solutions

At first

we thought it would be more efficient to discuss UI/UX solutions with a limited part of the team and then with the Customer for the final confirmation for the sake of saving time. In fact, it actually helped our designers to think out their UX solutions better when we started bringing the entire development team to the internal conversations before presenting the mockups to the Customer.

Many hours

have been spent on discussions of those topics with the Customer starting from the very beginning of the project, the intensive user research has been conducted, tons of empathy have been applied.

Our developers

had to rewrite a substantial part of the previously written code for the Android applications in order to meet the compatibility requirements here.

Using

the stripe-checkout library, our frontend developer has written additional logic for requesting a weblink leading to the webpage with the payment request details from the backend. Based on this link, the frontend would be requesting a new Stripe session and upon the person’s confirmation, the payment event would be performed.

Because

the original code was closely-coupled, and we definitely didn’t want to break something already working during the refactoring, our team decided to start from the top part of the application and then gradually rewrite individual parts of business logic

It is a common practice

now, to generate boilerplate code of the application. The developers are generating network layer from API specifications, using code generation libraries. Since there’s a huge set of endpoints on this project, we decided to use this approach to spent less time on the mobile development and to keep our app in sync with backend specifications in the future. We have this approach for the first time. The project is massive, and it was a risk for us in case of something going wrong down the road.

The entire Android-based code

was broken down into separate weakly coupled modules, which could be taken by different people without putting on pause another developer’s work. We have separate graphical reusable modules, like some repeating screen layouts, specific UI components as well as technical modules, like working with the audio. We also used Dependency injection, so the object’s attributes could be configurable by the external entities in the system.

Results

The application allows the owner to expand his business by attracting new vendors and contractors who can use the convenient application and receive orders by paying a commission. In the next stage it is planned to make the outlined application distributed as a SaaS solution, which can be used by car services on a white-label basis.

Results