Architectural Lighting · Dubai
LUX GEAR
one record, four artifacts
Desktop & mobileLUX GEAR · 2026
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.
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.
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.


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.
A quiet showroom.


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.


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