Case study · Website · Car hire
Building a multi-location booking website for Car Hire Hebrides
A multi-location car-hire website for the Outer Hebrides and Inverness, built around accurate per-location content, a genuinely distinct vehicle catalogue and a booking journey handed off to a hosted booking system.
The homepage: a clear proposition beside the booking search, which is supplied by the hosted booking system.
Selected project imagery was created using AI-assisted production and then reviewed and implemented as part of the website’s visual system.
Business and customer context
An uneven operational reality to publish accurately
Car Hire Hebrides is a retail car-hire business covering the Outer Hebrides and Inverness — a trading name of Adventra Ltd. It operates across islands connected by ferries and single-track roads, from six collection points that work in genuinely different ways: a staffed desk at one, a pre-arranged meet-and-greet at another, and delivered, unmanned collection at a third.
Getting that wrong on a web page is an operational problem, not a copy problem. A customer who turns up expecting a staffed desk where there is none has been misled. So the central challenge was to publish accurately about a business whose reality is uneven — confirming each operational detail with the business rather than copying it across from an older site — while routing every booking into a system the website does not control.
Project objectives
What the site set out to do
These were the goals for the build, not measured results.
Say the right thing about each place
Every collection point explains where and how collection works in its first few sentences, without claiming continuous staffing.
A catalogue that is genuinely distinct
Thirteen vehicle groups built from one template, written so they are not thirteen near-identical pages.
A clean booking hand-off
Send visitors into the hosted booking system reliably from everywhere, without pretending the site owns that step.
Foundations for search and access
Server-rendered content, canonical metadata, structured data, and accessibility and performance measured rather than assumed.
Porthline’s role
What Porthline built
The architecture and routing, the data layer, the design-system implementation, the content structure and CMS, the accessibility work, and the testing and QA tooling. In short, the website and the systems that keep it accurate.
Owned by external suppliers
Not Porthline’s work
- The booking engine and the quote-to-booking journey are ProHire’s hosted system. The site embeds it and hands off.
- Any analytics inside the booking widget belongs to ProHire.
- Real photography is a separate commission and is not part of this build.
Location and route architecture
Six collection points, each told truthfully
The site is organised around six collection points and five service areas. Location and service-area pages share a template but each supplies its own purpose and content, so a page that differed only by place name would be treated as a failure. Tarbert, delivered for unmanned collection, carries no “local business” structured data, because it is not a staffed location — the sort of accuracy that has to be built in, not bolted on.
The locations overview. Each of the six points is labelled with how collection actually works, from staffed desk to delivered and unmanned. The route line is presented as illustrative, not a to-scale map.
A worked example: Inverness
The Inverness page leads with its collection model — agreed with the customer beforehand — and instructs the visitor to select Inverness in the booking search rather than pretending the search is pre-filled. Inverness is one of the places Car Hire Hebrides serves, which is why the site matters to mainland customers as much as island ones — the same reason Porthline builds for businesses in Inverness and across the wider UK.
A per-location page. It states the collection model up front and instructs rather than asserts, because the booking search takes no location parameter.
Vehicle catalogue
Thirteen groups from one template, kept distinct
The catalogue holds thirteen vehicle groups in four categories — cars, 4x4s and pickups, people carriers and vans — with seventeen catalogue routes generated from a single template. Because template pages drift towards saying the same thing, the copy overlap between them was measured, and the answer was not more boilerplate but a sentence derived from each group’s own position among its siblings, so it cannot disagree with the data. Every example model carries “or similar”, enforced in the code and the database so a later edit cannot quietly drop it. Specifications appear only where the business publishes them; a blank is left blank rather than guessed.
The catalogue. Every example model reads “or similar”, and the figures shown are provisional and illustrative rather than final prices.
Booking and enquiry journeys
Built around a hosted booking system
The booking search and the whole quote-to-booking journey are ProHire’s hosted system, embedded in a reserved space so the page does not jump as it loads, and reached from a single shared “Book now” link used everywhere — header, vehicle cards, footer and closing bands — so every route into booking is consistent. Where the environment is not configured, a clearly labelled placeholder shows instead of a silently broken frame. Because the booking search takes no location parameter, location pages instruct the visitor which pick-up point to choose rather than claiming the field is already set.
For requests the search cannot satisfy — different dates, another location, another group — there is a server-validated enquiry form with proper spam controls, validated on the server regardless of the browser. Its email delivery is built behind a provider interface but is not yet switched on, so the form is honest about its state rather than pretending to send.
Responsive design and accessibility
Measured, not assumed
The site was reviewed at eleven screen widths from 320px up, each chosen for a reason rather than picked at random, with no sideways scrolling introduced across the set, and again at 200% text zoom. Interactive targets were measured across every route and every width against WCAG 2.2 AA target-size guidance; motion stands down under a reduced-motion preference; and text contrast over photography was measured glyph by glyph rather than averaged, which is a stricter test than most.
In the interest of accuracy: a small number of desktop hero headings still sit just below the contrast target and are recorded as open items rather than presented as solved. Measuring honestly includes saying where the measurement has not passed yet.
A location page at phone width.
The catalogue at phone width.
Under the hood
Accuracy built into the code
A data layer designed before the screens
Pages were built against a typed data interface with local seed data, then a database was swapped in behind it through a single line, without changing a public component.
Rules the content cannot break
The “or similar” rule, image alt text and the set of categories are enforced by database constraints and tests, so an edit made in a hurry cannot publish something inaccurate.
A staff editor with real safeguards
Staff can add and reorder vehicle groups and upload an image with mandatory alt text. Access passes three independent checks, enforced again in the database.
Static-first for speed
The public site is server-rendered and static by default, with client-side code kept to the few places that genuinely need it.
All of it is held up by 226 automated tests and a set of purpose-built browser checks — for layout widths, keyboard use, motion, contrast and the enquiry form — plus a visual-regression step that flags real changes to the rendered pages. Content integrity here is a build gate, not a style guide.
Project scope
The scale behind the build
The operational and architectural complexity described above is what these numbers stand for — a measure of the build, not a claim about its results.
58
public pages, built and prerendered
13
vehicle groups in four categories
6
collection points, each with its own model
226
automated tests (225 passing, 1 skipped)
These are counts of what exists in the build. They are not traffic, ranking or booking figures — those require post-launch data, which is covered in “What comes next”.
What comes next
Delivered, and honest about the roadmap
The website is designed and built. Some things sit deliberately ahead of launch and are worth naming rather than glossing over: a real photography commission to replace the placeholder imagery, switching on analytics and enquiry email, confirming the final prices and copy, and a legacy-URL redirect plan. Framing these as a roadmap is the honest position, and it is the kind of ongoing relationship Porthline is built for.
There is no results section, and there will not be one until there is measured data behind it. Traffic, rankings, booking volume and conversion all need post-launch analytics and reporting that do not exist yet. When they do, they can be added from named sources rather than estimated.
Case study FAQs
Need a website that has to get the details right?
If your business runs across locations, a catalogue or a booking journey, tell me what it needs to do and we will work out the most proportionate build.