GARAGE - Mobile Application for Technical Service Networks

In mid-2020, a representative of the investor, the visionary of the “Garage” project, contacted us. At a meeting attended by technical specialists and consultants, we discussed the main concept of the project. This was part of a free consultation. In short, in the Garage application we help the driver find the right service station, while the owners of stations or technical service networks receive customer traffic. In this article, we will share a secret: how to save an application client around 60,000 dollars through competent architecture design and the use of special technology for mobile application development. We will also cover some details that we are allowed to disclose. These details will help you better understand what application development is and how to create your own application for business.

So, “Garage” is 2 applications for two types of users: for drivers and for employees of a technical service station or a network of such stations.

On one side, there is the application for drivers: it displays a map where all service stations in the city are marked. A car owner can quickly find suitable services for their car. To do this, they add their cars, select certain characteristics and the services they are interested in, and then book a convenient available time in the calendar. They will be sent notifications so that they do not miss their service visit. The closest route to the service station will be built on the map taking traffic into account.

On the other side, it is an application-accounting system in which the service station administrator can enter data about their service station, input their services, set the working schedule, view the calendar where clients are booked for specific times, see statistics on the success of their service station locations, create their own unique service map, and set prices for them.

Reports were prepared for each task in the project. In total, 600 different tasks were completed for the project, many of which are micro technical specifications in themselves. If you plan to order a project from us, we can show you an example of such a report (of course, some data has been erased due to commercial confidentiality).

Design

The project design was carried out by a specialist on the client's side. It was a modern, aesthetic design. But since a designer's competence usually does not include designing from a technical point of view, we later proposed some changes that better aligned the visual side with the technical part of the project.

Mobile applications

The mobile application was planned for both iOS and Android. It is important to understand that the classic way of developing mobile applications is the so-called “native” approach. It implies that you will use a separate specialist in Java for Android and Swift or Objective C for iOS. This is a reliable and proven method, but it is quite expensive, especially if you have a complex client-server application with many screens, a non-standard data schema, and complex data search operations.

We proposed an alternative development method: hybrid. This is when you develop one application for both the iOS and Android platforms at once. In essence, you create a web application that runs in the same form as a native one. Visually, it is almost impossible to distinguish these applications; they are uploaded to stores and markets in the same way and installed on the desktop with an icon in the same way.

But, of course, there are nuances. First, there are some functions that are quite difficult to port to a hybrid application. And if the application is made by an inexperienced specialist and without the support of an experienced designer, the application will glitch. There may be not very noticeable “slowdowns,” delays when touching the interface: from 300 ms to 1000. Or there may be complete failures in the functioning of some virtual elements. Our team managed to port all the necessary built-in functions for both operating systems, overcome all difficulties, and create interfaces that work at exactly the same speed as classic mobile applications; no one will distinguish it from a native one. At the same time, thanks to competent architecture and key technical decisions, we were able not only to make a fully functioning application, but also to make it several times cheaper than developing separate apps. According to our calculations, we saved the client from 60 to 80 thousand dollars (depending on which rate is used for calculation).

We will not pretend otherwise: all of this did not come easily. It was a serious challenge, difficult work, sometimes sleepless nights. There were many nuances and problems. And the first versions of the application had various not very pleasant rough edges. However, the project was developed over 4.5 months (for such an application this is a very short period), and by the 3rd month polished 90% of the roughest “edges” had been.

By the time the application was delivered, everything worked strictly according to the technical specification, and we even found time to carry out additional paid work as well as add pleasant and convenient functions to the project: bonuses that no one had thought about at the technical specification stage.

Details about the applications' functionality

Registration: the user could gain access to the maps after selecting a language, verifying the phone number, and agreeing to the service rules.

Map: Google Maps was selected and integrated. Not the cheapest solution; in the article about the Internet City application we talked about the nuances of choosing maps. But we needed some Google Maps functions that were easier to buy and pay for according to the tariff than to rewrite from scratch based on free maps.

Service station search: the driver could easily select certain preferences for the service station, after which all suitable ones would be displayed on the map. They could also be viewed in a list format, sorted by distance to the service station.

Distance calculation: one of the very useful Google Maps functions. Thanks to a special Google service, we calculated distances to various points. And not the direct geodesic distance, but the distance taking into account all the broken lines formed by roads. There were some optimization nuances here that also saved the budget required by Google Maps tariffs.

Route rendering: it is important for the driver that the application works in navigator mode and leads them directly to the service station. To do this, it is necessary not only to draw lines on the map, but also to determine the driver's location and constantly update it as they move. There are some problems with this in mobile networks, especially with Google Maps. Sometimes geolocation may be determined inaccurately; you may have noticed such lags in taxi services when the car in the application suddenly appears on top of a multi-story building. We had to fight this.

Calendar booking: after selecting a specific service station, a booking is made. Booking logic is always a difficult algorithm in almost any application. We will not and cannot go into the details.

Adding a car: drivers can add photos and basic data of their car (VIN, model, etc.). All of this is necessary both for finding relevant service stations and for recommending the most suitable one.

Profile: the driver has their own page where they can see all data about their cars, credit cards (several can be added), payments, upcoming bookings, and the history of everything that happened in the application.

Reminders: the driver must be notified that their appointment time is coming soon. And this must happen even if the application itself is turned off. This effect can be achieved using push notifications. For this, a special service that sends them out was integrated. We recommended a service with good tariffs and a large number of free pushes per month.

Payment system integration: for payment for services, we considered various payment services. For the tasks of this project, the Fondy service turned out to be suitable. We implemented it according to Scheme B: this is an extended and non-trivial scheme that implies implementation through an API, rather than standard simple forms\buttons.

Integration of an omnichannel tool: in order to conduct various marketing activities with the client, it is necessary to be able to send them notifications to the networks or messengers convenient for them. For this, we advised and integrated a special service that can do this. This also saved the development budget, since each messenger or network can be implemented independently for free. But it will not be free in terms of the time programmers spend on development and debugging. In this project, it was not worth it. However, we described the development of the Social Jet marketing platform, and there it was relevant to work with the API of each social network and messenger. Individual decisions are made for every project; universal ones do not exist, and this is important to understand when developing your own project. Technical decisions are made by the system architect, management decisions are made by the project manager, and the business analyst helps make decisions on project requirements.

Administrative panel

Most of this section cannot be described by us due to a non-disclosure agreement. In short, it is a panel with statistics, analytics, CRM elements (customer relationship management system), a calendar plan, payment data, information about clients and their cars, the history of operations with a specific car, as well as various functions necessary for system administration of one's service station. Of course, in the admin panel one can add various information about the service station, lay out price lists, add photos to the service station gallery, and so on.

Architecture design

All details are under NDA

Writing the technical specification

A professional technical specification was developed for the project by our business analyst. All details are under NDA.

Organization of teamwork

The management of this project was not trivial. The feature of the project was that part of the team was fully under our control, part of the team was under our command but outside the staff, and part of the team was essentially not subordinate to us, but we interacted closely with them (for example, with the visionary, system administrator, and designer). From the first days, our certified project manager modeled the processes within the project, managed deadlines, controlled the main stages of delivering specific functions, drew the necessary diagrams (for example WBS), and, based on hierarchically dependent functions, kept the timelines of all phases under full control.

Difficulties and challenges

Of course, the most serious difficulties and challenges were, as always, in architectural decisions, or more precisely, in various technical conflicts between subsystems. In particular, there were special dances around loads and fairly expensive traffic to Google mapping services. One wrong move, and the project would start spending more money on its operation than it earned.

Quite little time was allocated for the technical specification, and for the entire project in general. The project deadlines were limited by certain marketing strategies and deadlines.

A relatively limited budget was allocated for the project (less than 50,000 dollars). This is a modest budget for a project of this caliber, but due to the fact that the architect (and concurrently the founder of our company) was invited into equity participation as a partner of the LLC, it was decided to take on the project.

The project was a startup, which meant that it did not have a clear and pronounced business model. In projects of this kind, it is even more difficult to build architectural hypotheses and make architectural (key) decisions.

Plans changed periodically in the project. Not in a key way, but within the limited timelines and budget, extreme management professionalism was required in order to get everything done and not miscalculate anywhere.

There were a number of difficulties with the subtleties of configuring integrated services. In particular, at the level of the services' technical support (the eternal problem)

The difficulties of integrating maps have already been written about above, but it can be summarized that maps were a significant technical headache in this project, especially in light of the fact that any actions with them are paid, and users perform a great many actions. Therefore, many architectural calculations were performed in an optimization-oriented way, specifically for the purpose of saving money by caching data in various ways and developing non-resource-intensive algorithms.

A separate story is passing the guidelines. In other words, passing verification when registering the application in stores. For Android, these guidelines were met quite simply. But for iOS there were many problems. Starting with the fact that the platform did not want to accept our funds for paying for the developer account (without it, it is impossible to upload the application). And ending with a huge list of requirements that had to be added to the application in order for it to be approved. This dragged on for a long time and required consultation and help from an iOS specialist.

This project shows that tasks of any complexity can be entrusted to us without fear, even if it is a very atypical project. Although Garage was not our most technically complex project, it contained a huge number of nuances both from the point of view of design and development, and from the point of view of managing people on the project.