An online platform that matches gig economy workers with temporary jobs
Our сlient from Saudi Arabia was inspired by Uber. They wanted to create a platform for on-demand services that would automatically match clients’ requests to corresponding service providers. The application would allow job seekers to apply for part-time jobs posted by individuals, organizations, or small and medium-sized enterprises. To implement this idea, our client got in touch with us and asked us to create two apps — one for clients and one for service providers — for both Android and iOS.
Saudi Arabia is a fast growing country that wants to create profitable business models that resemble Uber, TaskRabbit, and Sittercity in order to boost the gig economy in the region. Private entrepreneurs are starting businesses and offering new employment opportunities to Saudi residents.
A lot of people need a service provider to babysit their child, clean their house, or cater an event. They hire service providers for one day, a couple of days, or only a few hours. Since this is temporary employment, university students, the unemployed, job seekers, social activity lovers, or employees wishing to increase their incomes may be interested in taking up these part-time jobs. All these people have a common goal: they want to earn extra money through temporary work. A digital solution such as Casual can bring employers and part-time employees together and to some extent decrease the unemployment rate in Saudi Arabia, which was around 6 percent in the second quarter of 2018.
Requesters can create profiles and register as businesses or individuals. They can create one-time or periodic jobs. They can also approve or ban providers for work slots after providers have applied for a job. Requesters can reschedule, update, or moderate their own requests at any time before the service delivery starts. Requesters can also create periodic jobs with multiple work slots. They can send complaints if there’s a conflict or if providers don’t perform as expected.
Service providers can create profiles and indicate their availability (hours and days). They can receive job offers that fit their skills and availability and apply for them. Service providers can also send complaints if there’s a conflict or if the working conditions are violated.
The admin can see who registers with the service, solve disputes, and track how transactions are executed.
Casual unites people who want to earn extra money with those who are looking for part-time workers. The app resembles Uber but lets users not only find a driver but also a waiter, a photographer, a babysitter, and other service providers.
We created wireframes and went on with UI development. The app was designed for iOS and Android. We developed two different apps: one for those looking for part-time work and another for clients who are looking for workers. Сasual lets users hire staff for a couple of hours or one day and lets users make one-time requests or recurring ones. Users can hire one worker or a few workers at a time.
The app is available in Arabic with a right-to-left design. To accomodate this design, the entire interface is built from right to left. Each element on the screen is placed according to this rule.
We paid special attention to typography. Our task was to choose a font that would be aesthetically pleasing and read well. We also took into consideration Middle Eastern culture when choosing the icons for the app.
As a result, we created a convenient platform to post and find part-time jobs. The app will be distributed in Saudi Arabia with the prospect for future growth.
To create an online presence for the business, receive data about contacts, and provide links to the Google Play Store and App Store, we built a landing page.
We used HTML for markup. To describe the presentation of the web page, including colors, layout, and fonts, we used CSS. Gulp.jsis the streaming build system we used to automate the development workflow.
Stylus worked well as a CSS preprocessor, adding functionality to our CSS files and saving developer time and effort.
To simplify our work with the DOM and speed up our interactions with JavaScript, we used the third-party JQuery library. This library also allowed us to solve cross-browser problems.
We also created the logo for the platform to reinforce the brand identity. Since Casual is an app for posting and finding jobs, we considered a few metaphors and settled on the logo that resembled letter “C”. The intricate part of creating the logo was that it needed to be interpreted in two different languages: Arabic and English.
The Casual iOS apps are written in Swift. For their architecture, we decided to go with Model-View-Controller (MVC) and a Service-Oriented Architecture (SOA), which fits the product’s needs perfectly.
To power the network, we used Alamofire and the new native Codable feature for model mapping.
As the applications are designed for the Saudi market, we integrated the HyperPay OPPWA payment system so users can pay for on-demand services.
SDWebImage is a third-party library that helped us load and cache images and graphical content by URL. SDWebImage allowed us to download content asynchronously and update the UI of the apps. This library let us decrease the scope of work in code and simplify image management logic.
Google Maps SDK and the Google Places API let us display places of work within a certain distance of a user’s current location. Using these methods, we clearly displayed available jobs for service providers.
The Android apps are written in Kotlin. There are three modules: thepromoter module, the requester module, and the core module. The core module handles important things like project configuration and communication with the REST API. Using this module approach allowed us to speed up development for both apps.
To enhance code usability and readability, we used Kotlin Extensions. They simplified our work with views for the user interface and allowed us to improve code support during development.
RxAndroid bindings served as an addition to RxJava to handle user interactions with the application.
To implement a payment gateway for Saudi users, we chose the HyperPay SDK.
Displaying images is easiest using a third-party library such as Picasso. So we chose it for this project to cache images.
To log crashes and provide detailed reports about crashes, we chose Crashlytics.
We powered push notifications with Firebase Cloud Messaging.
The Google Maps API allowed us to display a map and show job locations. Google Maps Picker let us receive job coordinates. We used aesthetically pleasing and easy to read fonts available in Google Fonts.
We built an individual app for each user role. The apps work with the same API server. The backend handles the main part of the logic in the apps and provides all APIs for the mobile applications. The backend also provides admin configuration and interface management.
We chose PostgreSQL as the main data store for the application. All information is stored in this relational database and queried when required. Most filtering operations for job requests are made with PostgreSQL.
Celery allowed us to work with job status changes and notifications. It also helped us switch jobs to the scheduled, in progress, and done states, initiate payments, and notify users about upcoming jobs and new requests.
We used the Google Maps Geocoding API to fetch and display addresses of jobs.
To deliver email messages to users, we went with AWS SES. For push notifications, we settled on Firebase.
We did research and contacted a few payment gateways including PayPal and Checkout. We couldn’t use either PayPal or Checkout. PayPal doesn’t support Saudi bank accounts. As far as Checkout goes, there were restrictions because our client’s company didn’t meet the acceptable total income mark. So we switched to HyperPay, a Saudi payment gateway.
The HyperPay API wasn’t that easy to integrate, however, since it has a more complex structure of queries and webhook processing. We double-checked everything regarding restrictions and implemented all required endpoints and calls.
Initially, we decided to use the Twilio gateway to deliver SMS messages. It was vital to use a trusted service because we were running one-time password authorization through SMS. Twilio was to provide a stable delivery rate. But after we went live, we saw that a lot of messages weren’t delivered to some numbers and even to some telecom providers. We tried to solve this problem and stay faithful to Twilio for its reliability. We added alphanumeric sender IDs, which are required for SMS messages, but nothing helped. We then switched to another SMS gateway. We chose SMSAla based on reviews and pricing.
To make sure that each component of the final product works smoothly and properly, we performed a number of testing activities throughout all phases of the project.
At the phase of gathering requirements and preparing documentation, our QA engineers were involved in analysing those requirements and identifying the weaknesses and bottlenecks in the app flow. We had a team brainstorming session to improve the proposed logic and build a reliable system architecture.
Our QA engineers performed functional and non-functional testing, acceptance testing, ad hoc testing, component integration testing, GUI testing, and more. They created checklists that described scenarios for app testing in detail. All types of tests were performed separately for all four applications (two apps for Android and two for iOS). We also performed regression testing that checked the correctness of implemented logic in the whole app and re-tested it to detect bugs.
The admin panel lets the admin manage users, handle disputes, and see transactions.
The app sends push notifications to users if something important happens — for example, when a request is approved, a new event is created, or a payment is released.
The app lets requesters and service providers contact each other via voice call after a job is accepted.
Requesters can create requests indicating the job type, location, payment type, duration, start and end times, and rate.
Users can create accounts and register as requesters or service providers, providing their details. Both user groups can track the status of requests.
Requesters can pay with cash or top up their balances in the app by sending money to their accounts. When service is completed, this money is released to the service provider. The statistics show all transaction history.
SteelKiwi is amazing to work with. They are very responsive to what we need. They are amazing listeners and work with us through perfecting the design process and giving their feedback on the best technical solutions. Even though we are in two different countries and speak two different languages, we have never had any issues. Their support people speak and interact in fluent English. We have never had any trust issues. They have never overcharged us for the work. We feel we are very fortunate to have developed a relationship with such a developer. We contract a lot of services and SteelKiwi gets top rankings from us.
