QRelia / engineering history / Jan—Aug 2026
From one hotel to a distributed hospitality system.
This is the engineering story behind the flagship project: how a single-venue ordering workflow grew into multi-tenant SaaS, real-time operational state and a physical Raspberry Pi edge appliance.
The chronology is reconstructed from six Git histories, retained EF migrations, service/configuration files and the current source — not from a retrospective feature list.
The story in one sentence
Every expansion introduced a new failure domain. Each one forced a clearer architecture.
A menu bug is local. A real-time bug costs operational time. An unscoped tenant query can cross a customer boundary. A provisioning bug can strand hardware in a venue. A renderer can look beautiful while starving the order process behind it. QRelia grew by learning those boundaries in production.
It starts with a table, not a platform.
The first system is not built around a SaaS abstraction. It is built around the physical place where hospitality service happens.
The retained Le Pommier history begins with Admin and Receiver, then quickly adds Areas, Menus, MenuItems, Orders, Locations, URLs and QR entry points. That shape matters: a QR code is not merely a shortcut to a webpage. It maps a real room, table or service area into software context.
By the end of January the three surfaces that survive every later rewrite already exist: guest-facing ordering, an operational Receiver and an administrative control plane.
The order becomes a live event.
Persisting an order correctly is not enough if staff do not see it at the right moment. SignalR enters the codebase on 5 February and shortly afterwards live updates reach Admin as well.
SignalR makes the room react immediately. Database/API state remains authoritative. The same design later survives the jump into hardware: subscribe for immediacy, reconcile after startup or reconnect.
The venue teaches the data model.
Modifiers stop being a string and become groups, options, min/max selection semantics, descriptions and active state. Availability stops being a boolean and becomes time-aware, then gains multiple windows. Wine needs distinct rules. Cancelled orders change totals. Bestsellers need date ranges. Audit data gains provenance.
The useful part is that the abstractions are earned. There is no speculative service architecture invented before the problem. The schema changes because production requires the concept.
A fossil record of the product learning hospitality one constraint at a time.
Build SaaS without stopping the live venue.
QRelia SaaS does not begin after the standalone system ends. It begins while the live venue product is still changing. One codebase has to keep serving real guests; the other has to remove the assumption that there is only one venue.
That turns correctness into a boundary problem. Registration, onboarding, tenant resolution, venue identity, devices and a QRelia super-admin appear while the standalone application continues to gain operational features.
An unscoped query in one venue is a data defect. In SaaS it can become a boundary violation.
Ordering becomes a platform.
Stripe, subscription lifecycle, two-factor authentication, device ordering, tenant operations, platform audit and QReliaAdmin move the boundary outward. The 28 April EF re-baseline becomes a platform consolidation point rather than the birth of the domain.
By June, branding is venue-controlled, QR Print Studio is a production tool and physical devices can be provisioned and owned as tenant objects. Ordering remains the centre of gravity, but no longer defines the system.
The software leaves the browser.
The first device repository begins eleven days after SaaS. Early OLED status, LED experiments and animation code evolve into a system that consumes the same operational events as Receiver.
The hardware reveals a different class of correctness problem: a stale webpage is wrong on one screen; a stale ambient light is wrong to everyone who can see the room.
The display explains state. The strip communicates state and atmosphere. The cloud remains authoritative.
A prototype learns to survive without a developer beside it.
The dedicated ambient-device history shifts the problem from “can the LEDs work?” to “can this become an appliance?”. It cannot assume SSH, valid Wi-Fi, a reachable cloud or a clean previous shutdown.
Live and setup responsibilities are explicit.
Venue Wi-Fi, setup code and pairing live on the device.
Connectivity failure has an independent recovery path.
A physical control works even without cloud access.
Identity, heartbeat, SignalR, reconciliation and strip state.
Rendering can fail or evolve without owning order truth.
Performance also becomes a scheduling problem. LEDs, display refresh, heartbeat, SignalR and animation all compete for a small Raspberry Pi. Visual smoothness has to be cooperative with operational work.
The migration cannot break the printed world.
When production moves into SaaS, the old QR codes are already on tables and in rooms. That means the physical artefact is part of the compatibility contract.
Legacy routes carrying AreaId and LocationId are translated into the new QRelia context so printed codes continue to resolve correctly. The best cutover is the one the guest never notices.
A 480×320 screen becomes a transfer problem.
Replacing a 128×64 OLED with a 480×320 SPI LCD changes the physics. The production history becomes a performance investigation across SPI frequency, framebuffer strategies, damage refresh, boot presentation and renderer isolation.
A small visual change can force the full RGB565 framebuffer across SPI.
Dirty horizontal bands reduce transfer volume where the bus is the constraint.
Truth becomes a rendering requirement.
The screen can be smooth and still be operationally wrong. If Wi-Fi is down, the footer cannot imply cloud readiness. If the unit is resetting, normal live-service status is misleading. If startup is complete, “runtime starting” is false state.
The cloud/order process owns identity, heartbeat, real-time events, reconciliation and active orders. The LCD process owns high-frequency presentation.
Urgency becomes part of the interface contract too: stale orders outrank Pending; Pending outranks lower-urgency state; multiple active orders scroll rather than disappear; a new SignalR event invalidates the visible selection immediately.

What survived every generation
The architecture is easier to understand through its invariants.
Physical context is first-class.
Areas, locations and QR codes are part of the domain, not decoration around an ecommerce cart.
Events accelerate; they do not own truth.
SignalR creates immediacy. Reconciliation restores authority after reconnect, restart or missed delivery.
Growth creates stricter ownership boundaries.
One venue becomes TenantId-scoped SaaS. One device loop becomes separate cloud/order and display processes.
Interface correctness is operational correctness.
Once staff act on a dashboard, Receiver card, LED colour or LCD footer, presentation is part of system truth.
Compatibility extends into physical space.
Printed QR codes, wiring and deployed devices cannot be versioned with the same assumptions as a browser bundle.
The real transformation
The product learned where its boundaries really are.
In January the question was whether a guest could place an order and staff could see it. By August the question was whether a high-frequency renderer could remain fast, beautiful and truthful without stealing resources from the distributed system it represents.
The most important thing QRelia built was not a menu, a dashboard or a device. It built a chain of trustworthy state from a physical table to the cloud and back into the room.
That is why QRelia no longer reads as a QR-ordering project with extra features. It reads as a hospitality system.