Digital display network · 2023
Drag-and-drop content management for a large-format display network
A React application that let non-technical staff design and schedule content across a network of large displays. No ticket to engineering required.
- Web App
- Product
- React
- Node.js
- MongoDB
- Express
- 3 months
- Concept to launch
- Self-serve
- Publishing
- 0
- Engineering tickets for content
Challenge
Updating content across a network of large-format displays meant filing a request and waiting for an engineer. Campaigns that should have gone live the same morning took days, and the engineering team spent its time on content changes rather than the product.
Approach
Engaged by Leapwind on a fixed three-month contract, we built a drag-and-drop composition tool in React that lets marketing staff lay out, preview, and schedule content themselves, backed by a set of independently deployable microservices so the rendering pipeline could scale separately from the editor.
Outcome
Content publishing moved out of the engineering queue entirely. Staff who had never filed a ticket in their lives could build a layout, preview it exactly as it would appear on the display, and schedule it, with the whole platform designed, built, and shipped inside a three-month engagement.
Large-format displays have an unforgiving failure mode: content that looks fine in a mockup can be unreadable at ten metres. That was the real reason content changes went through engineering, not because the deployment was hard, but because nobody else could tell whether a layout would work until it was already on the wall.
Making the preview the product
The editor is a drag-and-drop canvas, but the feature that changed the workflow was the preview: a faithful rendering of exactly what the display will show, at the display’s own aspect ratio and scale. Once a marketer could see the result before publishing, the engineering review step stopped being necessary, and the queue it created disappeared with it.
Architecture that matches the load
Composing content and rendering it to a display network have completely different performance profiles: one is bursty and interactive, the other is steady and continuous. Splitting them into independently deployable services meant the editor could stay responsive under editing load while the rendering pipeline scaled on its own schedule, without either one being sized for the other’s worst case.
The whole platform went from concept to running in production within a three-month Leapwind engagement.