Hospitality platform · 14 public sites · Ongoing operations

Lancaster Hospitality Platform

Fourteen official-domain public websites sharing an engineering foundation while preserving the identity, destinations, content, and operating needs of each Lancaster property.

Visit LancasterTechnical deliverySee selected site screenshots

The engagement

Tayseer Laz and I built and deployed the platform while freelancing under Achour Holding. The work led to both of us joining Achour Holding in the same role: Senior AI Systems & Web Engineer | Technical Lead.

We still operate and maintain the Lancaster deployments. The public case study focuses on visible capabilities and responsibility; administrative interfaces, private data, and implementation details are not shown.

What the public platform includes

  • Property-specific experiencesDistinct branding, destinations, rooms, dining, events, offers, and local property information.
  • Multilingual contentLocalized navigation and hospitality content across the languages required by each audience.
  • Booking and inquiriesProperty booking paths, contact workflows, careers, and structured guest inquiries.
  • AI conciergeAn AI-assisted guest information experience enabled on property deployments with property-specific context.
  • Independent property controlEach property has its own content and data environment rather than sharing unrestricted operational access.
  • Search and discoveryProperty metadata, structured information, multilingual discovery, and links across the Lancaster network.

A fleet change is a controlled port, not a file copy.

Lancaster is operational engineering across independent property websites. Shared behavior has to move through several site variants without overwriting a hotel’s identity, languages, routes, booking behavior, or public-domain signals. The release unit is therefore both the shared rule and its property-specific adaptation.

Incident: the reservation button that only failed where configuration was absent

In August 2026, the configured reference property showed a working reservation control, but the same shared header could render a styled link with no destination on property variants where a booking address was absent. Visual review of the reference site could not reveal the defect because its data exercised only the successful branch.

The fix defined the guest-facing invariant first: a reservation control must have a valid destination or not render as a link. Blank values, placeholder fragments, root-only paths, malformed external addresses, and non-string values now fail closed. A valid external destination retains safe new-tab behavior; a legitimate internal booking route remains internal. Property pages that support their own booking flow keep that behavior rather than inheriting the group site’s fallback.

The regression test proves both halves of the contract. It supplies missing and invalid destinations and expects no link, then supplies valid internal and external destinations and expects usable link properties. A source-level guard also prevents the header from returning to the earlier raw-string pattern. The test was demonstrated against the pre-fix implementation, added to deployment checks, and adapted to the group site, Eden Bay, and the other property variants.

How the same rule moves through different properties

  1. DefineState a guest-visible invariant

    For the reservation incident: every visible control resolves to a valid property destination; absence never becomes a clickable dead end.

  2. MapLocate each implementation family

    The group hub, Eden Bay, and the wider hotel family place equivalent behavior in different components and preserve different booking routes and presentation rules.

  3. AdaptPort the rule, preserve the variant

    The shared validation behavior is carried across repositories without replacing property branding, languages, sections, or booking behavior with a template file.

  4. ProveTest the failure and successful paths

    Regression tests, builds, deployment readiness, and public checks are repeated for the relevant variant instead of assuming one passing property represents the fleet.

Release verification covers different kinds of failure

Guest workflow
A rendered page is insufficient evidence. Reservation, contact, career, and other guest controls must resolve to the destination owned by that property, and missing configuration must remain visible as absence rather than a false success.
Property identity and discovery
The reservation repair on the group site also removed a non-official host from generated canonical and sitemap output. Public checks therefore include the official domain, canonical identity, crawlable entry points, and the absence of placeholder routes.
Deployment readiness
A fixed delay after restart had raced application startup. The deployment check now polls readiness with bounded retries and fails the release if the service never becomes healthy, instead of treating one early response as final.
Independent release evidence
Each property is built and deployed independently. A passing regression test protects the code path; a successful build protects compilation; readiness proves the service started; and public workflow checks cover behavior. None of those alone proves the others.

Shared ownership and operating boundary

Tayseer Laz and I built, deployed, and continue to maintain the Lancaster sites together. The repository history shows both of us contributing to shared and property-specific behavior. I led much of the cross-site architecture, backend and data work, deployment and rollout controls, discovery work, integrations, analytics, and reliability; Tayseer established much of the initial visual and frontend foundation and contributed across responsive behavior, staff workflows, property presentation, and fleet refinements.

The fourteen official domains listed below demonstrate delivery. Tayseer Laz and I continue to operate and maintain the fleet, but we do not use availability alone to claim a conversion increase, search-ranking gain, completed-booking count, uptime percentage, or other unmeasured business result.

This account publishes the operational reasoning and one regression mechanism without naming the CMS or implementation stack, reproducing administration screens, describing private data or content models, or disclosing infrastructure and credentials.

Official-domain public sites