Case study

Telgani

Three apps, two dashboards and the landing page in front of them, for the Saudi marketplace that delivers a rental car to your door.

Year
2024
Sector
Mobility, car rental
Scope
Product design, Engineering

One product language across five surfaces: customer, agent, driver, admin, web.

3
apps designed and built: customer, agent, driver
2
dashboards: platform admin and rental agent
300+
rental companies listed on the platform

Telgani was founded in Riyadh in 2019 by Abdulkader Almkinzy and Ali Alfehaid. The pitch is easy to say and hard to run. Instead of queueing at a rental desk, you open an app, pick a car from hundreds of rental companies, and someone drives it to where you are. By the time the platform had raised $8.5 million across three rounds, closing with a $6 million Series A co-led by Hala Auto and Elm, it was listing tens of thousands of cars and promising delivery inside the hour.

That promise is the whole product. Everything on this page exists to keep it.

The two co-founders of Telgani, standing together in the company's office.
Telgani was founded by Abdulkader Almkinzy and Ali Alfehaid.

A marketplace is never one app

Five surfaces, one booking

Five different people touch a single booking, and each of them needs a different tool. A customer is choosing a car. A rental agent is accepting the job and preparing the vehicle. A driver is delivering it and handing over the keys. Someone at Telgani is watching all of it at once. And before any of that, a landing page has to explain the idea to a person who has never heard of it.

We designed all five surfaces, and we built them.

The customer app

The surface that carries the promise

People book a rental car in the situations where they are least able to concentrate: standing outside an airport, mid-journey, minutes after landing. The design gives them the fewest possible decisions in the fewest possible steps, and answers the two questions they actually have at every point. Which car, and when does it get here.

The customer app orders screen: three bookings, each with the car, the city, the dates, the rental company, and a status of accepted, cancelled or pending.
Status is the whole screen. Accepted, pending or cancelled is readable before any of the detail is.
The customer app live tracking screen: a card naming the car and the minutes until arrival with a call driver button, a map showing the route, a three-step progress bar reading on the way, arriving soon and delivered, and the pickup and delivery addresses with times.
Once a car is moving, the app has one job. Nothing competes with the arrival time.
Several customer app screens arranged at an angle. At the centre, a screen asking where you would like to receive the car, with delivery, airport and branch pickup as the three choices. Around it, a profile, an airport list, a location map and the orders list.
The top of the customer app profile screen: an avatar, a name with a gold rating, a wallet balance, and fields for email, phone number and birthday.
The customer app laid out as a grid of angled screens: sign up, a location picker on a map, a profile, the screen asking how you would like to receive the car, an airport list, a car list, and the orders screen.

The agent app

Supply has to want to use it

The rental companies are the supply. If the app they use is worse than the paperwork it replaced, cars stop appearing on the platform. The agent app is built around the moments that decide whether a booking succeeds: accepting the job, getting the car ready, and confirming it has left. It is designed to be usable one-handed, in a yard, by someone who did not ask for a new system.

The agent app's current booking screen: pending and scheduled tabs, a date range, and a booking card showing the car, the customer, and the pickup branch.
A decision, not a form. Everything needed to make it is on one screen.
Several agent app screens arranged at an angle: a booking detail with accept and reject, a dashboard of ratings and booking counts, a ratings screen, and a car list.
The same app carries the rest of the job: the cars, the bookings behind them, and how the branch is rated.

The driver app

The part nobody else sees

Delivery is the part of the experience the customer never watches, which is exactly why it needs its own tool. The driver app covers the run itself: where the car is going, what state it left in, and the handover that closes the loop. Every screen is one job, because it is being read at a kerbside with the engine running.

Driver app screens: a current booking list with the customer, booking number, car and delivery deadline, each with location and call buttons and a delivered the car action; a language picker offering Arabic, English, Urdu, Hindi and Bangladeshi; and an instructions sheet describing the three steps of a delivery.

Two dashboards, two jobs

Same shape, different work

Admin and agent look similar and are not the same product. The platform dashboard is for Telgani: supply across the network, what is moving, what is stuck, and what needs a person. The agent dashboard is the desk-bound half of the agent app, for the rental company managing a fleet rather than a car.

Both are dense by necessity, so the design does the sorting. Structure and hierarchy carry the meaning, and colour is kept for the few things that are genuinely urgent. If everything is highlighted, nothing is.

The platform admin dashboard, showing a driver's record: a deep navigation sidebar, filters for dates, booking status, office and city, four figures for average delivery time, total deliveries and the share on time or late, and a table of that driver's bookings. Other panels sit behind it, with revenue, availability by city and utilisation.
A booking details panel: the car, pickup and drop-off dates, extra services, the rental company and branch, and a payment breakdown listing the daily rate, the service fee and each extra.
Every booking has a history. When something goes wrong, the whole of it is on one page.
A car listing card: a discounted daily price, the rental company and its rating, the model and year, badges for safety, unlimited kilometres, thirty minute delivery and a car with driver, and a book now button.
One card answers the whole decision: what it costs, who is supplying it, what is included, and how soon it arrives.

The landing page

One promise, made believable

The site has one job, and it is not to describe a feature set. It is to make the delivery promise believable in the few seconds before someone decides whether to install anything, and then to get out of the way.

One system underneath

Designed and built by one team

Five surfaces feel like one product because they are built from one set of parts. Type, colour, spacing and components are defined once and shared, so a change made in one place lands everywhere, and the Telgani team extends the set without us.

We were not handing files over a wall either. The same team took this from product design through to shipped software, which is the reason the seams do not show.

A design system board: a colour palette with a gradient ramp, a type scale, a grid of interface icons, buttons, inputs, toggles, checkboxes and sliders, list rows, four alert states, vehicle illustrations, and five template screens.
Palette, type scale, icons, controls and their states, in one place. The apps are assembled from it.
A grid of three-dimensional icons in a single teal palette: a van, a storefront, a car key, a shield with a tick, a person, a checklist, a bell, a gift, a discount tag, a globe, a folded map, a cursor and a toggle.
Drawn as one set rather than collected. Nothing here arrived from a stock library, so nothing looks borrowed.
Next projectEntech

Want results like this?

Start a project