WordPress taxi booking plugin
Booking, fare calculation and payment — replacing a rented SaaS the client couldn't control.
Cut a recurring $30–40/month subscription to zero, and gave the operator fare rules and booking data the paid tool never exposed.
What it is
A custom WordPress plugin that runs the whole booking end to end — the customer enters their journey, the plugin prices it from real distance, takes payment through Mollie, and both sides get a confirmation. The operator manages everything from wp-admin.
The problem it solves
The client was renting a third-party booking tool for $30–40 a month and still couldn't change how it worked. Fields they didn't need, fields they did need that weren't there, no control over pricing rules, and no access to their own booking data. They were paying a subscription for something they didn't own.
How it works
- Booking form built into their existing WordPress theme — no external embed or iframe.
- Google Maps API for address autocomplete and real route distance, so pickup and drop-off are validated as real locations rather than free text.
- Fare calculated per kilometre, with fixed postcode-based rates overriding it where the operator wants a set price.
- Fixed-rate table is importable as CSV, so the operator updates pricing in a spreadsheet instead of asking me.
- Payment taken through Mollie — the standard Dutch gateway, and the one their customers already expect.
- Server-side validation on every field: required fields, valid email, no past dates, and sanitised input before anything reaches the database.
- Bookings stored in the site's own database, with a wp-admin panel to view, edit, delete and export to CSV.
- Confirmation emails to both the operator and the customer, sent over SMTP rather than WordPress's default mail.
The interesting problem
Two things, and neither was the booking logic. WordPress's default mail is unreliable — confirmations regularly land in spam or never send at all — so I moved to SMTP with the mail port and DNS records configured properly from the start rather than discovering the problem after go-live. The second was the front end: the booking form had to sit inside the client's existing theme without looking bolted on, and the theme's own styles fought every layout decision. Scoping the plugin's CSS so it inherits the theme's typography but controls its own layout took longer than the booking flow itself.
What I would do differently
I started building before the client had confirmed the design, and reworked parts of it once he saw the first version. Now I get sign-off on a mockup first — the changes he wanted were reasonable, but they cost time that a five-minute approval at the start would have saved.