SignOnGlass: distributed order display and signing

A simple experience with a complex path underneath

I designed and built the first version of SignOnGlass during my first fortnight at Saint-Gobain Building Distribution, then remained its Technical Lead through expansion and large-scale rollout.

The aim was straightforward for branch staff and customers: show an order on a dedicated tablet, capture a natural handwritten signature, and return it to the point-of-sale system. Delivering that experience meant coordinating a constrained PoS application, web and desktop software, specialist hardware, real-time messaging, a multi-brand estate, and traditional enterprise infrastructure.

Designing around fixed constraints

Several major choices had already been made before I joined. Thousands of Wacom tablets had been purchased; each appeared to Windows as both an additional monitor and a pen/touch input device. The existing PoS software could make only basic REST calls and had no direct real-time integration path.

I wanted to build the application on the then-new .NET Core platform, but it was considered too new for this estate. I delivered SignOnGlass on the approved .NET Framework and ASP.NET MVC stack instead. Later at Saint-Gobain, I was able to make .NET Core the foundation of the wider application platform used to replace legacy systems.

I designed the system around those constraints:

1. The PoS application sent order lines to a REST endpoint, which stored the order centrally.
2. SignalR notified the correct tablet client that a new order was ready.
3. A full-screen web interface displayed the order on the Wacom device.
4. The customer signed on a touch-sensitive canvas designed to feel close to pen and paper.
5. Because the PoS could not receive a callback, it polled for completion and retrieved the captured signature.

The result hid the integration compromises from the person using it. Staff could continue working inside the familiar PoS flow while the web, messaging, database, and device components coordinated behind it.

Making specialist hardware feel automatic

To remove manual setup from day-to-day branch use, I built a C#/WinForms tray application that watched for display changes on each PoS workstation.

When a supported Wacom device was connected, the application identified it, launched the browser in full-screen kiosk mode on the correct display, and associated that client with the backend. When the tablet was disconnected, it closed the kiosk session. Implementing that apparently simple behaviour required substantial Win32 interoperability because the necessary monitor and device lifecycle information was not exposed cleanly by the higher-level framework.

This was an important part of the product: the hardware needed to behave like an integrated PoS peripheral, not a second monitor that branch staff had to configure and troubleshoot.

One platform across multiple brands

The platform was rolled out across more than 5,000 locations belonging to over ten Saint-Gobain brands. I built administration tooling to associate installations with the correct brand and control the experience centrally.

When a tablet was not being used to sign an order, it became a centrally managed advertising display showing brand-specific promotional content. This gave the already-deployed hardware a useful second role as a customer-facing communications channel rather than leaving thousands of screens idle. The platform therefore supported different identities and content while keeping one application architecture and operational model.

Real-time scale and load balancing

Thousands of locations could contain multiple active terminals, producing a large population of long-lived SignalR connections. I optimised the platform to remain responsive at that scale and worked through the infrastructure consequences of real-time state.

The application ran across load-balanced Windows servers behind F5 infrastructure. SignalR made server affinity an important part of the design, so application behaviour and load-balancer configuration had to be considered together rather than treated as separate concerns.

Owning rollout as well as implementation

My ownership extended from the original technical design and application code through packaging, infrastructure, deployment, and production rollout.

The tray application was packaged for distribution across the workstation estate through Group Policy. On the server side, the established environment did not provide infrastructure-as-code or automated application deployment. I therefore personally installed the application on every load-balanced server across two redundant failover sites.

The process was manual rather than automated, but it was the real delivery constraint. Successful ownership meant understanding every layer, applying the deployment consistently, and getting the system operating across both sites—not stopping when the code compiled.

The result

SignOnGlass grew from a rapid initial delivery into a distributed production platform spanning thousands of physical locations, multiple brands, specialist devices, desktop integration, real-time web communication, load-balanced infrastructure, and enterprise rollout processes.

After rollout, it ran reliably for years across that heavily used estate. Subsequent development was dominated by adding capabilities rather than stabilising the platform or resolving recurring production problems.

It remained a significant piece of work throughout my time at Saint-Gobain because I owned the complete path from an operational problem to software running in branches at scale.

Why I include this work

• End-to-end technical ownership from design through physical rollout.
• Pragmatic architecture around fixed hardware and legacy-system constraints.
• Real-time SignalR engineering across a large distributed estate.
• C# desktop and Win32 integration alongside web and database development.
• Multi-brand platform design without duplicating the underlying system.
• Product thinking that expanded single-purpose signing hardware into a customer-facing advertising channel.
• Production reliability that allowed post-rollout work to focus on product evolution rather than remediation.
• Operational responsibility across Group Policy packaging, Windows Server, F5 load balancing, and two-site failover.