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.

QRelia Ambient LCD device showing live operational state and diffused light
Current edge layerCloud state, rendered into the room.

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.

247standalone hotel commits
305SaaS checkpoints
295OLED-era device commits
36LCD-era device commits
Six histories overlap into one product.The SaaS platform was built beside the live standalone system before the July handover.
JanFebMarAprMayJunJulAug
Le Pommier standalone
QRelia SaaS
OLED device era
Ambient appliance
LCD
18 January 2026

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.

Durable product skeletonGuest → shared domain → Receiver + Admin
February

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.

Pattern 01Events for speed. Reconciliation for truth.

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.

GuestLocation-aware order
ASP.NET Core domainRazor Pages · EF Core · SignalR
ReceiverLive service
AdminControl + analytics
February—April

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.

48 retained standalone EF migrations

A fossil record of the product learning hospitality one constraint at a time.

1 March onward

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.

TENANT RESOLUTION / TenantId
CustomerVenue AdminReceiverQReliaAdmin
Shared multi-tenant domain + SQLEvery path must agree on tenant context.
Pattern 02TenantId changes what a bug is allowed to touch.

An unscoped query in one venue is a data defect. In SaaS it can become a boundary violation.

April—June

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.

QRelia live analytics dashboard
By August, one shared domain is projected through guest ordering, live service, management analytics and external devices.
11 March—May

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.

Edge constraintA physical signal makes stale state public.

The display explains state. The strip communicates state and atmosphere. The cloud remains authoritative.

June—August

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.

01Boot decision

Live and setup responsibilities are explicit.

02Captive setup

Venue Wi-Fi, setup code and pairing live on the device.

03Network watchdog

Connectivity failure has an independent recovery path.

04Hard reset

A physical control works even without cloud access.

05Tenant runtime

Identity, heartbeat, SignalR, reconciliation and strip state.

06Display runtime

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.

July

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.

Compatibility lessonOnce software emits a physical artefact, backwards compatibility includes the room.
23—31 August

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.

Full-plane transfer

A small visual change can force the full RGB565 framebuffer across SPI.

Damage-band transfer

Dirty horizontal bands reduce transfer volume where the bus is the constraint.

Embedded lessonOptimise the constrained bus, not the most visible line of application code.
31 August

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.

Pattern 03The tenant runtime decides what is true. The renderer decides how to draw it.

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.

QRelia Ambient device in connected and ready state
The current device exposes service state, cloud/network state and local identity as one operator-readable surface.

What survived every generation

The architecture is easier to understand through its invariants.

01

Physical context is first-class.

Areas, locations and QR codes are part of the domain, not decoration around an ecommerce cart.

02

Events accelerate; they do not own truth.

SignalR creates immediacy. Reconciliation restores authority after reconnect, restart or missed delivery.

03

Growth creates stricter ownership boundaries.

One venue becomes TenantId-scoped SaaS. One device loop becomes separate cloud/order and display processes.

04

Interface correctness is operational correctness.

Once staff act on a dashboard, Receiver card, LED colour or LCD footer, presentation is part of system truth.

05

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.

Evidence baseluxasscze/LePommier · LePommierSaaS · qreliadevice · qrelia-ambient-device · qrelia-lcd · qrelia-device-lcd48 retained standalone EF migrations · 26 retained SaaS migrations after re-baseline · reconstructed through 31 Aug 2026