From one hotel to a distributed hospitality system.

There is no multi-tenant abstraction yet. No hardware appliance. No subscription engine. There is a hotel workflow that needs to work in the real world.

The first retained Le Pommier repository begins on 18 January. Admin is added immediately. Receiver follows the same day. Within a week the data model already contains Areas, Menus, MenuItems and Orders; shortly afterwards it learns about Locations, URLs and QR entry points.

That is a clue to the product from the beginning: the unit of work is not “a web page”. It is a physical place — a room, table, area or location — mapped into software. Hospitality is full of state that looks trivial until service begins. A menu can exist but not be available now. An item can belong to several menus. A guest can be at one table while the available menu is controlled by an area schedule.

The first architectural breakthrough is not QR generation. It is the moment an order becomes a live event instead of a database row waiting to be noticed.

In early February, Receiver becomes the place where timing starts to matter. A customer can place an order correctly and the database can persist it correctly, yet the operational system still fails if staff do not see it quickly enough. On 5 February SignalR enters the codebase. Two days later real-time updates reach Admin too.

The venue teaches the data model

February becomes a sequence of domain lessons. Modifiers become groups, options, descriptions, active state and relationships. Availability becomes time-aware. Wine needs distinct handling. Cancelled orders affect totals. Sales telemetry needs both sold count and last-sold time. Bestsellers need date ranges. Revenue makes more sense by area than as one number.

The abstractions are earned rather than invented in advance. By 20 February the dashboard is live, SignalR is stable enough to be infrastructure, and the system is reporting operational performance rather than merely accepting orders.

A live hospitality product quickly learns that the simple version of almost every rule is wrong.

Modifier groups are the clearest example. Production needs required groups, minimum and maximum selections, single versus multiple choice, descriptions, active state and visual control. On 5 April the migration history records the shift to production multi-select modifiers and the change then propagates across Admin, Customer and ordering logic.

Availability follows the same path. One slot per day is enough until a venue needs breakfast, closes, then reopens for dinner. In late April the model expands to multiple availability windows.

Then the system begins to explain itself

On 24 April audit data appears. It starts with who, when, type and action; within hours it gains platform, tenant/context and full-name metadata. By 30 April it also carries a message plus previous and new state. Auditing is what happens when a tool becomes an operational system whose changes need provenance.

The most important chronological fact is easy to miss: QRelia SaaS starts on 1 March while the standalone hotel system is still evolving in production.

This creates two simultaneous problems. The first codebase must keep working for a real venue. The second must remove the assumption that there is only one venue. Features continue to be invented in standalone through spring and early summer, then synchronised into SaaS. It is a fork-and-absorb transformation, not a clean rewrite weekend.

Once tenant isolation exists, the next questions are no longer about ordering alone. Who can create a tenant? How does it pay? How is it branded? How does support see it? How does hardware belong to it?

Stripe arrives in April alongside Receiver and super-admin work. Subscription recovery and lifecycle work continue through the month. Two-factor authentication lands in May. Device ordering gains its own schema, status and pricing. Activity audit becomes a SaaS concern. Last-login telemetry appears. By the end of May, QReliaAdmin has a tenant dashboard.

On 28 April the SaaS repository re-baselines its EF migration history. The new baseline does not mean menus, orders or modifiers were invented that day; the standalone history proves they existed months earlier. It marks a platform consolidation point — a new database history for the multi-tenant product.

Branding stops being hard-coded

June pushes QRelia further from its single-venue origin. Venue-controlled themes arrive. Ambient device profiles appear. QReliaAdmin gains tenant operations. QR Print Studio becomes a production tool. Device provisioning becomes a cloud loop: a physical unit can be claimed, identified and controlled as an object belonging to a tenant.

Eleven days after the SaaS repository begins, another experiment starts: what if an order could change the room itself?

The first qreliadevice repository starts on 11 March. Early hardware work contains backup scripts, LED tests, competing animation files and hardware experiments. The original runtime uses an SSD1306 OLED for local status; by late March animation has become its own subsystem.

The device immediately inherits Receiver’s operational problem: it cannot merely know that an order exists eventually. It has to react now. A dense SignalR stabilisation sprint in May gives the edge device live order events while keeping REST reconciliation as the recovery path.

By 8 May the addressable-light work has moved far beyond status LEDs. The animation engine targets a 144-pixel WS281x/WS2815-compatible strip with a large catalogue of effects. The conceptual split becomes clear: the display explains the device; the strip communicates state and atmosphere to the room; the cloud remains the source of operational truth.

The dedicated qrelia-ambient-device repository begins on 7 June. The change is less about more animation and more about turning a Raspberry Pi project into an appliance that can live at a venue.

A production edge device cannot assume SSH. It cannot assume the correct Wi-Fi remains configured. It cannot assume the cloud is reachable at boot. It cannot assume the last process exited cleanly. It needs local identity, a recovery path and enough observability to explain whether it is alive.

Performance becomes a scheduling problem

The OLED generation discovers a less obvious constraint: visual work can starve operational work. A 144-pixel strip, display refresh, SignalR, heartbeat and showroom animation all compete for CPU time on a small Raspberry Pi. Cooperative rendering and controlled frame rates become correctness tools, not cosmetic polish.

By July the SaaS platform is ready to absorb Le Pommier. But a web migration has a physical constraint: QR codes have already been printed and placed in a hotel.

The standalone system therefore becomes a compatibility layer. Customer, Admin and Receiver traffic can redirect into QRelia. More importantly, legacy PlaceOrder URLs carrying AreaId and LocationId are translated into a QRelia legacy route so existing printed QR codes continue to resolve to the correct physical context.

The handover happens while the domain is still getting richer. Waiting estimates land in standalone on 20 July and in SaaS the next day. Area availability and booking/social actions follow. Preparation stations arrive. QR ordering gets a grace period. Course-aware service is released at the end of the month.

Hospitality state becomes coordination state

Courses show how far the model has moved from “submit basket”. The system now reasons about guests, starters, mains, when each course is served and how the Receiver changes the order lifecycle as service progresses. Waiting time is first-class operational state. Kitchen analytics distinguish what was actually prepared. Weather data is matched against orders for analysis and forecasting.

The first LCD repository lasts one day and five commits. Replacing a 128×64 OLED with a 480×320 SPI display changes the physics of the runtime.

The prototype preserves the cloud contract — setup AP, venue Wi-Fi, setup code/PIN, persistent identity, heartbeat, SignalR and REST reconciliation — but rewrites the local presentation contract. It also enforces single-renderer ownership so setup and live mode cannot fight over the screen.

From 28 August the production LCD history becomes a concentrated performance investigation: 28 MHz, 31 MHz and 32 MHz SPI variants; Raspberry Pi 3 tuning; direct-framebuffer experiments; damage refresh; strip-mirror generations; custom boot presentation; showroom persistence and reboot fixes.

By the final August iteration, performance is no longer the only LCD problem. The display can be smooth and still be wrong.

A Wi-Fi failure screen that says the setup portal is ready when setup is not actually active is false system state. A reset screen that continues to show normal live-service footer badges is misleading. A device that has finished starting but still says “runtime starting” erodes operator trust. The 31 August truthful-status work treats wording as part of state-machine correctness.

Urgency becomes part of the UI contract

Active-order presentation is rebuilt around operational priority. Stale orders outrank Pending; Pending outranks lower-urgency states. If several active orders exist, the list scrolls rather than silently hiding work. When a new order arrives over SignalR, the renderer must invalidate its current selection immediately.

At the end of August, the easiest way to misunderstand QRelia is to name only one of its interfaces.

It is not just the guest menu because the same order flows through Receiver, analytics, preparation logic and a device. It is not just Admin because tenant identity, subscriptions and provisioning sit above it. It is not just the Raspberry Pi because the hardware is an edge projection of cloud state. It is not just a SaaS database because printed QR codes and physical locations are part of the routing model.

Technically the system now spans Razor Pages applications, EF Core and SQL Server, ASP.NET Identity, SignalR, Stripe, PDF/QR generation, multi-tenant middleware, analytics and reporting, device provisioning, Python edge runtimes, systemd supervision, Wi-Fi captive setup, addressable LEDs and a custom 480×320 framebuffer renderer.