Instant booking

Overview

Instant Booking was a new way to get things done that Airtasker introduced in 2019. It was a way to get tasks done faster and by the people who were the most qualified and available to do them.

The problem

Up until the release of Instant Booking, the process of having something done through Airtasker was the following: a user (poster) would post a task and the ballpark price they were willing to pay, then other users (taskers) could bid on the task, by how much they would charge. The poster would then choose the tasker they wanted to work with, and assign the task to them. This back-and-forth took time, and for straightforward tasks, it was unnecessary friction.

What we built

Instant Booking introduced a new way to post a task: the poster would describe what they needed, the system would set a fair price, and the task would be surfaced to eligible taskers based on a predictive algorithm. Once the first tasker claimed it, the task was instantly assigned to them, and the process was complete. Later, we introduced subscriptions, so that the poster could book the same tasker on a recurring schedule.

This project came at a time when different internal projects were starting to build up steam: the Airtasker Design System (ADS) was starting to be adopted by the engineering team, the iOS team had agreed to break the app into smaller frameworks and had agreed to adopt reactive programming, the backend team wanted to start to break away from the Rails monolith and adopt a more functional approach.

It was a great opportunity to experiment with the concept of a Backend-for-Frontend (BFF), where the backend would drive the application flow, rather than the frontend. So instead of having an endpoint providing data to hydrate the UI, the frontend would simply call the backend and it would return the components to be rendered, with only the information necessary to render them, no longer needing to send data to the frontend that would then be discarded.

We started by building Instant Booking for moving tasks, in Sydney. This was a great opportunity to experiment with the BFF concept, and to see how it would impact the development process. Once we were happy with the results, we started building subscriptions, where a poster could book the same tasker on a recurring schedule.

Introducing subscriptions was a much faster process on the frontend side, because the components were already built and we could simply reuse them.

This approach allowed us to introduce new task types much faster and tweak the experience based on feedback and metrics, without having to go through an entirely new development cycle.

My role

At the time, Airtasker had cross-functional teams focused on different parts of the company. We were the Poster/Tasker team, and I was one of two iOS engineers on the team. Being one of the biggest evangelists of the design system, I was heavily involved in the design process and helped define the architecture of the feature. There were two schools of thought: taking a protobuf/RPC approach or a Backend-for-Frontend approach. We ended up going with the latter, because it would allow frontend developers to contribute and help develop the feature. Also being more similar to OpenAPI, it was easier to integrate with the backend and have other teams embrace it as well.

When it came to development, my focus was building the UI components in the iOS app, the flow and coordination necessary to introduce another backend and app flow. At the same time, I took that opportunity to learn Kotlin and implement some BFF endpoints and component factories in the backend.

The stack

Our iOS app was already mostly in Swift, so we decided to build a separate framework that would have its own dependencies and backend provider, the BFF. For the coordination, and given that the BFF would be driving the app flow, we decided to use RxSwift to handle the different states and events.

For the backend, we decided on Kotlin and Spring, because this way both Android and iOS developers could contribute to the backend code. Ktor was the initial choice, but we ended up using Spring Boot because it was more mature and had some necessary features that were not available in Ktor yet.