Trigger SMARTS

A hotel-signage problem that grew into three working versions of the same idea.

Trigger SMARTS began in a very particular environment: hotels and conference venues where room bookings, event information and physical signage all have to agree.

A guest sees a room name, an event and an arrow.

Behind that simple display is a more complicated system of hotels, rooms, clients, bookings, screens, directions, branding, permissions and staff who need to change information quickly.

SMARTS grew by learning that environment from the inside, through three successive working versions rather than one single build.

Current position

Version 1 and version 2 are both currently deployed and configured in real hotel operations. SMARTS v3 was published live and working on 1 September 2026. Wider rollout across the estate and broader commercial adoption remain a separate, ongoing question.

01 / Version 1: learning the operational problem

Trigger SMARTS began as a direct response to a hospitality operations problem: keeping room bookings, event information and digital signage aligned across hotels and conference venues.

By 24 October 2024, the basic system was ready for a proposed Leicester rollout once hosting and WordPress arrangements were in place.

By March 2025, it was in controlled real-world rollout in Leicester hotels, with further rooms held back while route and arrow decisions were resolved.

By 25 April 2025, two Leicester display variants were live, while the wider installation continued to develop.

This was not a prototype waiting for validation. It was a working operational product, shaped directly by real hotel bookings, real events and real signage decisions.

Different hotels acquired their own dashboards, event structures, branding and display behaviour. Room screens could show the event taking place there; shared signage could point guests towards the right spaces across more than one property.

That closeness to real operations mattered. The relationships the product would later need to represent — hotels, rooms, clients, bookings, screens and directions — emerged from watching what actually recurred in use, not from designing a generic signage system in the abstract.

02 / Version 2: building the shared multi-hotel model

By spring 2025, the limits of building each hotel separately had become clear. Adding another property could mean adding another set of event structures, pages, templates or screen-specific logic — the product was proving useful while becoming progressively harder to maintain.

The question changed. It was no longer how to make the next hotel work, but how to keep what had already been learned without rebuilding the same machinery for every hotel.

Version 2 answered that by generalising the recurring structure into shared entities: hotels, rooms, clients, bookings, screens, directions and signage assignments, alongside hotel-scoped operational interfaces so each property’s staff worked within their own view of a shared system.

Grosvenor Square is the concrete version 2 rollout. It was configured and tested through May 2025, scheduled to go online on 19 May 2025, and was live by 20 May 2025.

The months that followed involved the ordinary work of running a live system: display adjustments, booking questions, staff training and signage changes, alongside continuing support. A further round of testing in August 2025 validated the platform against real use rather than marking its beginning. By September 2025, this mature version 2 codebase had been preserved as its own baseline, SMARTS-DEV.

This was the point at which Trigger SMARTS stopped being a set of venue-shaped installations and became a genuine multi-hotel product.

03 / Version 3: rebuilding for maintainability and extension

By early November 2025, versions 1 and 2 were established, deployed generations, while version 3 was the next architecture already under development and testing. On 10 November 2025, the version 3 source lineage was re-baselined into TriggerEdition, the foundation the rest of this generation was built on.

That rebuild did not happen as one clean release. The development history includes overlapping branches, experiments, regressions and restoration work: a signage optimisation broke static content and had to be repaired; a large implementation was split into smaller modules, then followed by a deliberate parity-restoration pass to recover behaviour lost during refactoring.

Later work added stronger source-controlled architecture documentation, migration tooling and historical replay/testing, so changes could be made against known states rather than relying on memory.

The August–September 2026 work consolidated this further, bringing together the platform’s estate overview, hotel and property views, rooms and screens, bookings and analytics, messaging and display controls into one coherent operating environment. SMARTS v3 was project-owner-confirmed as published live and working on 1 September 2026.

The project became easier to change partly because its own development history became more explicit, not despite it.

04 / The 2026 operating surface

Version 3 is what versions 1 and 2 made possible: a single, coherent operating surface across the estate, rather than a set of separate hotel installations.

Today that surface includes:

• estate-wide hotel overview;
• network and property views;
• room and screen management;
• active-screen visibility;
• booking and analytics views;
• hotel messaging;
• editable footer content;
• recurring bookings;
• multi-room bookings;
• duration-calculated end times;
• client booking history;
• guided room setup;
• stronger room-status visibility;
• finer control of displays.

05 / What I did

My role has spanned all three generations of the product: operational discovery in the field, product and information modelling, WordPress/Pods implementation, and the platform generalisation and refactoring that followed.

It has included:

• modelling the relationships between hotels, rooms, clients, bookings, screens and directions, starting from real venue operations;
• shaping staff-facing dashboards and update routes for individual hotels, then hotel-scoped operation across the shared platform;
• developing the WordPress/Pods implementation across all three versions;
• moving repeated hotel-specific behaviour into the shared version 2 structures;
• supporting version 1 and version 2 through deployment, configuration and ongoing operational change;
• refactoring and restoring behaviour as the version 3 architecture changed;
• designing the admin and UX surfaces used to operate the platform day to day;
• documenting the system for continued development and AI-assisted implementation;
• developing migration, replay and validation tooling around the current architecture.

The important part is longitudinal.

This is not a clean-room redesign based on a requirements document. Version 3 carries knowledge accumulated through two earlier working versions, not just its own build.

06 / What the project demonstrates

Trigger SMARTS demonstrates a particular kind of product development: start close to the operational problem, learn from what real deployments reveal, and generalise only once the repeated structure is clear.

It also demonstrates the discipline of preserving domain knowledge while the architecture around it changes — version 3 did not discard what versions 1 and 2 had already taught the product.

And it demonstrates the difference between:

• a bespoke working installation;
• a reusable platform;
• a developed successor version;
• a live publication;
• wider commercial adoption.

Those are related states, but they are not interchangeable.