⟵ work ⟶ now · Client work

I built the website, customer app and dispatch tools for a cooperative of thirteen taxi drivers. The system keeps their shared Google Calendar at the centre and connects bookings, driver assignments and flight updates around it.

I have been Taxi Haarlem Service’s sole developer since 2021. The cooperative mainly takes people between Haarlem and Schiphol. Over five years, the work grew from a website into the software customers use to book and the planner uses to organise the day.

The dispatch board on a tablet: the day as a list on the left with a coloured dot and a driver name per ride, a map of Haarlem and Schiphol on the right with cars on their routes, and the day’s counts and two donut charts underneath.
The board on a tablet: list, replay map and the day’s numbers.
The dispatch board on a phone: a list of rides for a Thursday, each with a time, a coloured status dot, a driver name and the pickup address.
The list on a phone.
The replay map on a phone: cars and a van on the roads between Haarlem, Heemstede and Schiphol, with a scrubber and a play button underneath.
Replaying a day on the map.
The statistics tab on a phone: counts of rides by kind and source, a total in euros, and two donut charts.
The day counted.

4 images — swipe or scroll sideways

Keep the tool everyone knows

The company already ran on a shared Google Calendar. The planner used it to manage reservations, and drivers checked it on their phones. Keeping it was a requirement.

I built around that workflow. Assigning a driver means inviting their account to the calendar event; accepting the invitation acknowledges the ride. The dispatch board combines that information with reservations and shift schedules, helping the planner see who is available and distribute several rides at once.

The board offers a list, map and timeline. Its map can replay a day so the planner can inspect gaps between rides. Cached data keeps the last known schedule available without a connection, although live position sharing on iOS requires the app to stay open.

Let flight changes reach the driver

A background service checks Schiphol’s flight information and updates airport pickups when arrival times change. It adds details such as the gate and baggage belt to the event. A cancelled flight is flagged for attention; the reservation remains for the planner to follow up.

An early version rewrote every event on each check, sending drivers repeated notifications. I changed it to write only when the relevant flight details change.

Show the price while someone books

The website, customer app and partner versions share one booking form. It calculates the fare as the route is entered, applies the cooperative’s town and vehicle tariffs, and accounts for luggage that requires a larger car. Customers can manage their reservations through the app.

The booking form on a phone: pickup Grote Markt 2 Haarlem, destination Schiphol Airport, fields for date, passengers and luggage, and a footer showing the price €39,00 next to a green reserve button.
The form, with the price already known.
The website’s front page: three numbered steps on the left, the booking form on the right, a phone number, and a rating of 4.5 stars.
The same form on the website.
The app’s opening screen: a yellow taxi on a canal in front of Haarlem gables, and a single button reading Stap in.
The app’s front door.

3 images — swipe or scroll sideways

In daily use

On the February day shown in the screenshots, the cooperative handled 65 rides: 28 booked through the app and 37 through the website. Those figures describe that particular day.

Keeping Calendar has a cost. Some information also lives in the booking database, and edits can disagree. There are explicit rules for which system wins, but the flight updater can still overwrite a manually adjusted pickup time. That remains an unresolved edge of the workflow.