By this point the limo plugin had its booking flow, its payments, its driver side, and an app like feel. But a real ride service is more than getting from a booking to a driver. It is the human touches around that core, choosing your vehicle, reaching your driver, feeling safe. This post is those three features as they were actually built, with the honesty this series owes.
Vehicles first. The elb_cars table existed from day one, and this is where it earns its place, each vehicle class is a row with its own rate, and the fare flexes with the choice:
public function calculate_fare($car_id, $distance_km) {
global $wpdb;
$car = $wpdb->get_row($wpdb->prepare(
'SELECT base_rate, per_km_rate FROM ' . $this->table_cars . ' WHERE id = %d',
$car_id
));
if (!$car) { return false; }
return round($car->base_rate + ($car->per_km_rate * $distance_km), 2);
}
The design point is what is absent, no hardcoded prices anywhere. A sedan row carries sedan rates, a stretch limo row carries its own, and the admin adds vehicle classes without touching code, pricing lives in data. The booking form renders the classes from the same table, so the customer picking luxury sees the luxury fare compute before they pay.
Chat next, customer and driver coordinating, where are you, I am at the side entrance. Architecturally it is the humblest thing in the plugin, a messages table, booking id, sender, message, timestamp, an AJAX action that inserts after the nonce check, and the same five-second polling as the dashboards fetching new rows for that booking. No websockets, no presence indicators, and honestly none needed, two people coordinating a pickup exchange a handful of short messages, and a polling chat carries that completely. Its absence is what users would feel, a ride service where you cannot reach your driver reads as broken even when everything else works.
Safety last, an emergency button on the tracking and driver pages, prominent, always visible, firing an AJAX alert that flags the booking and surfaces immediately on the admin dashboard with the ride’s details. And the honest frame, in a solo build, this is an alert pipeline to the operator, not a connection to emergency services, its value is that a rider in a stranger’s car sees a visible way to raise a hand and knows the operator will see it. On trust, the visible presence of that button changes how people feel about using the service at all, and I will not dress it up as more than it is. Some of these touches were more polished than others, that is the truth of a platform this size built by one person, but each was designed, built, and wired to the same secured AJAX spine as everything else.
A few things people ask me about this
How should a booking plugin handle multiple prices? A table row per option carrying its own rates, with fares computed from the row. Hardcoded prices mean code edits for every business change.
Does a simple chat really not need websockets? For two parties coordinating a pickup, polling every few seconds is entirely adequate and vastly simpler. Reach for push transport when message volume or latency genuinely demands it.
Next
That completes the platform as far as I took it, the most ambitious and most humbling thing I had built. The final post is the honest accounting, what truly worked, what stayed aspirational, and what the whole build taught me.
