A second entry point for the same operator
Elite Ride Mugoša runs premium transfers in Montenegro. Their main website sells the chauffeur service: limousines, weddings, business travel, discretion.
The problem is that a passenger landing at Podgorica Airport is not looking for a limousine. They want an answer to three questions: how much to Budva, is that the final price, and can I pay now. That is a different guest, a different intent and a different search.
So we built a separate transfer website, with the same vehicles and the same dispatch system behind it, but with a message tailored to someone who is looking for a ride from the airport right now.
Price before the enquiry, not after
The key decision was to make the price visible immediately.
The guest enters pickup and drop-off through Google Places search, picks a date, a time and a passenger count, and gets a price for every vehicle class. The price does not come from a table of ours but live from the operator's dispatch system, for exact coordinates and an exact pickup time, so it already includes every surcharge the operator applies: night driving, rush hour, airport fee, child seat, meet and greet.
The advantage is that there are never two price lists drifting apart. The operator changes prices in one place and the site picks that up immediately.
Programmatic route pages
People do not search for "airport transfer". They search for "taxi Podgorica airport Budva". So every common route gets its own page.
The pages are not written by hand. An admin adds a route with a pickup and a drop-off point, and the system generates the page, calculates the road distance and pulls prices per vehicle class.
The admin can override the heading and the intro copy where it matters, so the page is not an empty template. Routes are also grouped by city, giving an entry point such as "all transfers to Kotor".
A few things mattered here:
- Road distance, not straight-line. Distance is calculated through a routing service and cached for a month, with a fallback estimate if the service is unavailable, so the kilometre figure is never blank.
- Prices are cached, vehicles are not. Prices are held for six hours, and only five minutes on failure, so an outage does not trigger a retry storm. Vehicle records are never cached, so editing a name or an image in the admin shows up instantly.
- The displayed price is a daytime price. The "from" price is calculated for a representative midday slot, because a night surcharge would otherwise advertise an incomparably higher figure. The real price is recalculated as soon as the guest picks their own time.
- Prices are warmed in the background. A scheduled job keeps the cache warm, so listing pages never wait on an external service.
We describe our general approach to websites for transport operators in our guide to building a car rental website.
Fleet and trust
Vehicle classes sync from the dispatch system, but the display order and visibility are controlled by the admin through drag and drop. The operator decides what the guest sees first, regardless of how the vehicles are filed in the back end.
The rating and reviews are pulled live from the Google profile, filtered to those with real written text, cached per language, with a fallback so the badge never disappears if Google does not respond.
The site runs in two languages, English for travellers and Montenegrin for local guests, with a language prefix in the URL and hreflang tags.
Payments and booking rules
Card payments were introduced carefully, because real money is involved and a bank has to approve the integration.
- Card payments go through 3-D Secure, with Visa and Mastercard identity verification
- The card payment switch is enforced on the server, not only in the interface, so until the bank approves, that path simply does not exist
- The "order and pay later" option always works, so a booking never depends on the state of the gateway
Advance booking rules are configurable in the admin by distance band. Rides over a hundred kilometres from Podgorica require twenty-four hours' notice, because the operator has to schedule a driver.
A dashboard that watches margin
The admin panel is more than a list of bookings. The dashboard shows the count and value of bookings for today, this month and overall, paid versus unpaid, invested versus revenue per ride, a thirty-day trend and twelve months of revenue.
The interesting part is the calendar with ride chaining: the system spots consecutive rides where one drop-off is close to the next pickup, so the dispatcher can see where two rides can be joined instead of sending a vehicle back empty.
Under the hood
Backend: PHP 8.2, Laravel 13, Spatie packages (permission, translatable, sitemap, honeypot), Sentry, reCAPTCHA Enterprise alongside a honeypot on every form.
Public site: Blade with Tailwind CSS v4, Alpine.js, Flatpickr. The site was written from scratch for this purpose rather than inheriting the theme from the main website.
Admin: Inertia.js with Vue 3 and Vuetify, sixteen screens.
Integrations: the operator's dispatch system for pricing and pushing bookings back, Google Places for address search (proxied and cached server-side), Google Places Details for reviews, a routing service for road distance.
SEO: a sitemap with hreflang alternates per locale, seven JSON-LD schemas including LocalBusiness with geo data and an aggregate rating, plus a news module.
Scope: 13 models, 29 migrations, two languages (English and Montenegrin).
More on integrations like this on our System integrations page.
Visit the website
If you run transfers or a transport business and need a website that quotes a price before the enquiry, get in touch. Have a look at the other projects in our portfolio.