← All work
Project

Alp Roads Booking System

Web developmentLaravelCustom platformTravelStripe
Alp Roads Booking System

Alp Roads runs private airport transfers into the Alps - Munich, Innsbruck, Zurich and Salzburg out to St. Anton, Lech, Ischgl, Sölden and the rest. They were running the whole operation on a booking form, a spreadsheet and a lot of memory. We built them the system that replaced all three: one Laravel application that prices a trip, takes the money, dispatches the driver and tells the owner how the year is going.

Passenger names and addresses in these screenshots are pixelated. Everything else is the live product.

One trip, two legs, one charge

Most transfers to a ski resort are return trips, and that is where booking software usually falls apart - either the return is a second booking nobody connects to the first, or it is one booking so rigid that a changed flight means cancelling both halves. Here a trip carries both legs. Each leg has its own pickup, its own status, its own driver, and can be moved or cancelled on its own. The money stays with the trip: one price, one balance, one refund position, however many times the legs change underneath it.

A return trip - both legs, each with its own status, under a single price and a single outstanding balance

The price is worked out, not looked up

Nobody at Alp Roads sets a price by hand. A route runs through distance tiers that get cheaper per kilometre the further you go, a multiplier for the vehicle, fixed prices where a route is common enough to be worth pinning, then night, holiday and season surcharges on top. Change a tier and every quote from that second onward reflects it - including the ones the website is handing out at three in the morning.

Distance tiers, priced per kilometre - the pricing engine behind every quote

The day, then the year

Dispatch works off a calendar: every pickup for the week, colour-coded by status, one click into the booking to assign a driver and a car - and from there the driver’s own schedule fills in by the quarter hour. That is the operational half. The other half is the owner’s - the dashboard puts this year against the same point last year on bookings, revenue, and money already committed for trips that have not happened yet, so a slow February is visible in February rather than in the accounts the following spring.

The week, by status

This year against last year, including revenue already booked ahead

The customer-facing side is a WordPress site that embeds the booking widgets and talks to this API - a separate project, and one we will write up on its own.

Stack: Laravel 11 with Filament for the admin, MySQL, Stripe and PayPal, Google Maps for routing and distance, queued mail and notifications, and a token-authenticated API serving the WordPress front end.

Tell us what’s broken.
We’ll tell you the truth.

Book a free call →
Reply within one business day · EN / LV