Skip to content
All case studies

Architectural Lighting · Dubai

LUX GEAR

one record, four artifacts

Year
2026
Scope
Operational Software · Digital Experience · Print & Brand Design · Search & Visibility · Security & Trust

Desktop & mobileLUX GEAR · 2026

01The brief

The product is the catalogue

LUX GEAR supply architectural LED lighting across the UAE and the wider Gulf, under their own LUXFLARE brand. Their buyers are specifiers and contractors, and a specifier's question is never "is this nice", it is "what is the lumen output, the CRI, the beam angle, the ingress rating, and can I have it in black".

That makes the catalogue the product. Not a brochure about the product: the catalogue itself is the thing that wins or loses the specification.

Which is exactly why it is the hardest thing to keep honest. It has to exist as a web page, as a datasheet a specifier downloads, as a PDF a salesperson attaches to an email, and as a printed book that sits on a table in a meeting. Four surfaces, one set of facts, and traditionally four separate acts of retyping.

02The challenge

The printed one is always wrong

Every lighting supplier has the same failure. The website gets updated because it is easy. The PDF gets updated when someone remembers. The printed catalogue was correct on the day it went to press and has been quietly drifting ever since.

So the salesperson emails a PDF with last season's wattage, or the specifier reads a printed page that contradicts the website, and the credibility cost lands on the one document that was most expensive to produce.

The fix is not discipline. Asking people to update four documents consistently is asking them to do a job software should be doing.

03Direction

Three directions, then a decision

None of this was only software. LUX GEAR needed a company profile, a product catalogue and a set of specification sheets, and none of them existed in a form anybody wanted to put in front of a client. The website had to be designed too, and it had to look like it belonged to the same company as the printed book.

So instead of presenting a moodboard, each direction was built as a finished artifact. Three complete company profiles, seven pages each, same words, three treatments: Atelier, light and editorial with a gold rule; Nocturne, full-bleed night photography with the type sitting in the dark; Travertine, stone-warm with the facts banded across the foot of the page. The catalogue got the same treatment, eight pages in each of Atelier, Noir and Travertine, rendered to print-ready PDF.

That is more work up front and it is the part worth paying for. A client choosing between three real documents is making a decision they can defend to their own board. A client choosing between three moodboards is guessing, and the guess gets reopened at page forty, when changing it costs a fortnight.

Three spec sheets, and a way to change your mind

The specification sheet is the document that does the selling, so it got three directions of its own: Atelier, Swoosh and Azure. Swoosh was chosen on 23 July 2026 and is what the site serves today.

The choice is a setting rather than a rebuild. Each design is registered against an id, and the site stores which id is live. Switching it moves every datasheet, every downloadable PDF and every page of the printed catalogue to the new design at once, with no data migration and no edits to any page that displays them. If the brand moves in two years, that is an afternoon rather than a project.

Three company profile cover designs side by side, labelled Atelier, Nocturne and Travertine, each carrying identical copy in a different treatment
One company profile, three directions, built as finished documents
Three specification sheet designs side by side, labelled Atelier, Swoosh and Azure, each laying out the same luminaire data differently
Three spec sheet designs. Swoosh is the one in use, and the choice is a setting

04Foundations

Publish once

A product is entered once, in a CMS built for the actual shape of a luminaire: wattages, colour temperatures, ingress ratings, finishes, mounting options, LED chip and driver brands, photometric data. Hitting Publish generates everything downstream.

The web page and the environment variants. The specification datasheet. The A4 PDF. And a page in the catalogue book, laid out with the technical drawing, the polar photometric diagram, the options grid and a generated product code.

The printed page also carries a QR code back to the live product. That is the part that matters most: a printed catalogue is a snapshot the moment it leaves the press, so every page in this one is a route back to data that cannot go stale.

The font bug that broke every PDF

The first real Publish produced a PDF that was blank in one viewer and slow in every other. The cause was not the layout. The framework's own font loader serves variable fonts, and Chromium's print-to-PDF cannot embed those; it silently degrades each glyph into a Type3 font, which is a small vector program rather than a character.

That first PDF contained 27 Type3 fonts and zero real ones. Nothing errored, nothing warned, the file simply did not behave like a document. Fixed by self-hosting static font files, which is the kind of constraint you only learn by generating a real artifact and opening it in more than one viewer.

Fast is a trust signal too

Downloading a datasheet shortly after a Publish used to open a blank tab for eight to twelve seconds while the PDF regenerated synchronously. The file was correct; the wait read as broken.

It now serves the existing PDF instantly and regenerates in the background. Publishing itself fires the same way: on a real Publish, the published and pdf-generated timestamps landed about ten seconds apart, which is the proof the background trigger fires without anyone waiting on it.

The experience

A quiet showroom.

The LUX GEAR catalogue reader open at its cover, a 103-page product catalogue with page-turn navigation and a PDF download
103 pages, generated from the product records
A generated catalogue specification page showing the product code, options grid, specification table and a QR code labelled scan for live details
Every printed page carries a QR back to the live record

05The build

The parts people actually touch

A specifier opens a light and picks what they actually want: ten watts or twenty, 3000K or 4000K, IP44 or IP54, white or black or a custom RAL colour, recessed or surface mounted. The factory ordering code writes itself underneath as they go. LFDLCR-10W-3K-IP44-WH becomes LFDLCS-20W-4K-IP54-CS, and note that the mounting choice rewrites the front of the code, not just the tail. Then one button gives them the spec sheet for that exact configuration rather than the generic one. Before this, somebody who knew the rules assembled that code by hand, and a wrong code is a wrong delivery.

Internally there is Pinpoint: type the name of a light and it tells you who makes it, with the full contact detail, editable in place. It is admin-only and never appears on the public site. It exists because that answer used to live in one person's phone, and reps move on.

And the CMS is two panels. The form is on the left; on the right is the actual A4 datasheet, redrawing as you type, with a toggle to see the website page instead. It is not a preview of the artifact. It is the artifact, rendered by the same code that will render the PDF, which is why what you approve is what gets printed.

Re-filing a product without writing a script

A product carries two separate ideas that look like one. Its TYPE decides the ordering-code mask, the light-distribution background on its sheet, and which section of the printed book it lands in. Its CATEGORY decides only where it is browsed on the website.

Keeping them apart is what lets a Full Moon Bulkhead keep its downlight code and its downlight sheet while appearing under Bulkheads. That is a dropdown now. Before the split existed, every re-filing decision had to be baked into a one-off script and run against live data.

The same product configurator in two states: at ten watts, 3000K, IP44 and white the code reads LFDLCR-10W-3K-IP44-WH, and at twenty watts, 4000K, IP54 and a custom colour it reads LFDLCS-20W-4K-IP54-CS
Change the configuration and the factory ordering code rewrites itself
The product CMS in two panels: the entry form on the left, and the live A4 datasheet redrawing on the right with a toggle between datasheet and website views
The right-hand panel is the artifact itself, not a picture of it

06The outcome

What it costs to add a product now

One entry, one Publish. The web page, the datasheet, the PDF and the catalogue page all follow, and there is no version of the catalogue that can be out of step with another, because there are no other versions.

The public site runs 99, 100, 100 and 100 on desktop Lighthouse, with the catalogue at 83 and 96 on performance and accessibility against a full-screen product film and a scroll-scrubbed assembly sequence.

Access is enforced at the database with row-level security rather than in the interface, so what an account can edit does not depend on which buttons it can see.

Lighthouse, desktop
99 · 100 · 100 · 100
Catalogue
103 pages, generated
Publish to PDF
~10s, in the background

Four artifacts, one source, no retyping.

Start a conversation