Case study · Website · Car hire · Live
Building a multi-location booking website for Car Hire Hebrides
The live, 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 live homepage, captured 11 September 2026: 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.
What was built?
Car Hire Hebrides needed a website that could publish accurately about five collection points that each work differently, present thirteen vehicle groups as genuinely distinct choices, and send every booking into a hosted system the site does not control. Porthline Digital designed and built the website: its structure, content, location pages, vehicle catalogue, enquiry form, search foundations and the staff editor behind it. It went live in September 2026 at carhire-hebrides.co.uk.
The booking search, quotes and payment run inside ProHire’s hosted booking system, not on the site. Porthline built the website around that hand-off; the booking system itself is ProHire’s.
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 five 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
Five collection points, each told truthfully
The site is organised around five 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. That sort of accuracy has to be built in, not bolted on.
The locations overview on the live site. Each of the five 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. It is 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”. Prices are set by the business and served from its database, so the live site is the current source for any figure.
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 in the 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. It delivers by email to the business and was checked with a real submission at launch. Delivery sits behind a provider interface, so if the email service were ever unconfigured the form would say so rather than pretend 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: during the build, a small number of desktop hero headings sat just below the contrast target and were recorded as open items rather than presented as solved. They were resolved before launch with treatments to the text, not the photographs. Measuring honestly includes saying where the measurement has not passed yet, and then saying when it has.
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 more than two hundred automated tests and a set of purpose-built browser checks covering 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. They are a measure of the build, not a claim about its results.
57
public pages in the live sitemap
13
vehicle groups in four categories
5
collection points, each with its own model
200+
automated tests behind every build
These are counts of what exists in the live build, checked on 11 September 2026. They are not traffic, ranking or booking figures. Those require post-launch data, which is covered in “Live, and what comes next”.
Live, and what comes next
Launched, and honest about the roadmap
The website went live in September 2026. Launch closed out the items that had been deliberately held until then: the enquiry form delivers by email, the published prices were confirmed by the business, and the addresses from the previous website redirect to their new homes so old links and search listings still land somewhere useful.
Some things remain on the roadmap and are worth naming rather than glossing over: a real photography commission to replace the generated imagery, and switching on analytics reporting once the business has an analytics property to send it to (the consent-gated measurement layer is built and waiting). 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 a reporting period and named sources. When they exist, they can be added from those 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.