Slyyd

I spent two decades inside the problem and all along I was building the tool. As a gaffer on major film and television productions, I stood at the center of the lighting workflow on every project I touched. I knew the gap between the project’s vision and what the tools could deliver. The instruments around me had transformed in those years. LED color engines, wireless control, and advanced optics on every fixture worth using. But this is an industry of storytellers. Lighting control technology was still solving the problems of fixtures and circuits while storytellers simply wanted to create using lighting, not lights.

In 2014 I co-founded Lighticians. The work we started there eventually became Slyyd. Creamsource acquired the project in 2022 and tasked me with building and leading a team to take Slyyd to a wider audience. The Hollywood Professional Association gave Slyyd its Innovation in Production and Capture Award in 2026. What follows explores what we built, the diverse team of innovators who met the challenge, how we collaboratively made decisions together — including how we leveraged respectful disagreement as strength, and the aspects of the project that never shipped. Slyyd is a product. The team is the achievement.

App-based Lighting

Professional lighting on a film or television set is controlled by specialists — directors of photography, gaffers, chief lighting technicians, lighting directors — who speak a trusted and efficient vocabulary as old as filmmaking. The craft endures, and as new types of creators practice it, the vocabulary keeps growing with them. What has changed is the tools, techniques, and workflows that enable these craftspeople to create. The instruments themselves had undergone a revolution. LED fixtures with multi-emitter color engines capable of millions of colors are now standard issue on productions of every scale.

An early attempt at new tools was to smash a full-size lighting console complete with its command-line interface onto a tablet. This proved as difficult to learn and use as the console itself while not offering any new abilities. Some fixtures shipped with vendor-specific apps that knew only their own hardware. Some production crews (my crew included) pressed theatrical consoles into service but that only worked for the top tier of productions and never would benefit creators. Those consoles were built for the linear cadence of live performance, not the non-linear storymaking workflows of filmmaking. They forced a way of thinking that filmmaking, at its finest, does not need.

The goal is simple: every user, on every set, with whatever equipment a production has at hand, should feel as empowered in their craft as the diversity of stories they want to tell.

The next generation of storytellers needed a tool built by a team that had stood inside the lighting conversation themselves. The choice to build a product with an app-first design mandate was a direct expression of the team’s knowledge both in the problem and in app development. We built Slyyd as a universal tool, equally capable across every fixture in the market. The work that makes that possible lives behind a second face of the app, called The Vault, where the team compiles, curates, tests, and calibrates every fixture profile by hand. The goal is simple: every user, on every set, with whatever equipment a production has at hand, should feel as empowered in their craft as the diversity of stories they want to tell.

Speaking Color

Slyyd addresses two distinct problems in color. Every other tool in the category had ignored both.

The first is the interface problem. Professional lighting is about communicating intent — “late afternoon tungsten, but cooler” — and translating that intent into precise fixture output. Previous tools required the operator to work in the fixture’s native parameter space: RGB sliders, or CCT, or hue/saturation. Slyyd removes that constraint. A user can pick a color from a gel swatchbook, adjust its color temperature, then zoom into the CIE xy diagram to remove a small amount of pink. The system holds all of that together without loss of fidelity and without breaking the ability to manipulate the result further. Every color input method is a window into the same underlying representation: the color wheel, RGB sliders, color temperature, CIE xy coordinates, the gel swatchbook. Nothing is discarded when you switch between them.

The second is the fixture problem. Every professional LED fixture presents a different control surface to the network: some in RGBW or RGBACL mode, some in CIE xy, some in a hybrid hue-saturation-plus-color-temperature mode. The mode is the fixture-side agreement that determines how the fixture reads incoming DMX slot values. Historically, the operator had to understand each fixture’s mode and manage the conversion math manually. Slyyd holds the other side of that agreement: a profile for every fixture in the library. The app converts the user’s intent into the slot values that the fixture’s mode reads back as that intent, with high fidelity. The user does not need to know the fixture’s mode. They need to know what they want the light to do.

I wrote the original color science myself, drawing on decades of CIE xy and gamut work I had carried with me from the set. The breakthrough that turned those algorithms into the industry’s best color engine came from collaborating with Markus Winkler, our chief software architect. Markus had twenty-five years in software development and zero years in lighting. I hooked him with the problem. He printed gamut diagrams and drew on them by hand until he could explain why a single-triangle gamut model is insufficient for a multi-emitter LED fixture. Then he implemented the brute-force solution that the math required. The result is what ships in Slyyd today.

Measuring Light

I wrote the apps and tooling that calibrate, test, and score fixture profiles as they are built for curation and publication. I designed them to automate the process and chose Python, with the Rich and Textual modules for an easy-to-use UI. Why should our tools be any less friendly than what we ship to customers? I have been migrating this to a web app, complete with enhanced automation features and a fully visual UI.

The Python app and its web successor drive one or more fixtures and a calibrated colorimeter through a structured measurement sequence, running unattended from first value to last, collecting SPD data, XYZ tristimulus values, correlated color temperature, and Δuv for thousands of samples per fixture. Some fixtures produce over ten thousand measurements.

The colorimeter communicates over a custom USB driver I also wrote. It speaks directly to the hardware without depending on the manufacturer’s software stack. The fixtures connect over sACN E1.31, so the measurement environment mirrors a real production network.

Both apps process the data automatically. They parse, validate, and build the output into a fixture-specific color model: a gamut hull, a transfer function, and a LUT. Slyyd receives these when a library is published. The libraries are fully versioned, with rollback and Git-style commit histories.

Every fixture that goes through calibration carries a scorecard. The scorecard records what the fixture actually achieves, scored against perceptual criteria, and does not soften where that falls short of what the manufacturer claims. The scorecards are the quality gate for internal review and QA.

The Vault

The Vault is a Ruby on Rails app. Łukasz Pająk and Rafał Camlet built it initially. When budget constraints required development to come in-house, I assumed ownership of the codebase. I now self-author, maintain, and enhance it without engineering assistance, leaning first on early code-writing on-prem LLMs and now on an agentic harness.

Chi (Chuan Chi Chan) owns the library inside The Vault. She had been a lighting programmer both theatrically and on my crew for years, including running wireless control with us on Monsterland alongside Jesse Skogh, who became Slyyd’s manager of usability. I asked Chi to join the product team when Slyyd was ready for a profile curator. She drives every profile from measurement through curation through publication.

We tuned the backend specifically for the query patterns of fixture lookup: by manufacturer, by mode, by DMX E1.11 slot count, by colorimetry model, by capability flag. It currently holds 1,000+ profiles covering 200+ distinct fixtures, organized around more than 1,170 named capabilities and 991 gel swatches.

The Vault carries everything the team needs internally: gamut quality, calibration provenance, capability flags, and more. Almost none of that surfaces to users. What does surface, on each fixture in the Slyyd app, is a single recommended badge: the go-to profile for that fixture, hand-picked by the team. The badge saves users from searching through lists of profiles to find the best choice to get working quickly. The complexity belongs to the tool, not the creative.

The Vault is what closes the universal-tool promise. Every profile encodes a calibrated mapping between user intent and emitter output. Chi and the team built that mapping by hand across years of measurement, field findings, and tooling improvements. It is the kind of multi-year feedback loop that is easy to describe and hard to build.

Conducting

I was a conductor. A conductor plays no instrument during the performance. The orchestra plays. The musicians own their parts, listen to each other, and respond to each other in real time. The conductor holds the score in mind: tempo, dynamics, where the dissonance is supposed to land, and where it has to be folded into the sonority of the whole.

That is what I implemented for the Slyyd product team. The music making belonged to the people playing the instruments. My job was to hold the vision, set the tempo, listen, adapt. The moments of strongest disagreement often produced the line we needed. Note that we describe music-making using the word playing. We also had lots of fun.

I had been refining this approach since my early gaffer days, when I tried to know and own every task on every project. I burnt out. The back half of that film career, I changed the approach. I built a team of passionate learners first and foremost. I set a tone. I knew every detail but I transferred ownership of outcome. The team set the goals. I led the team, not the tasks.

I built multiple multi-national, diverse, multi-cultural, cross-functional teams over eight years, first partnering with the boutique at Nomtek in Wrocław and recruiting directly in New York and New Jersey. At full build, the Slyyd team ran two levels deep. My direct reports were five: a UX/UI lead, a project PM, a project PO (the product proxy in the agile model), a manager of usability, and a chief software architect. Beneath them sat the rest of the team: a product expert, QA, QAA, a small group of developers, and specialists including mathematicians. Six direct reports is my cap on any single project. Across the three teams I led (the Slyyd app, the hardware, and the OS for the hardware) I had eight at peak. I carried strategy, product-market fit, overall product direction, and design supervision.

The team was composed from both ends: domain experts without a software background, and software geniuses with no domain experience. Jesse Skogh emerged directly from my crew. He had spent years on set managing on-set data, teaching the lighting team, and communicating clearly under pressure. He had no traditional UX training, nor QA experience. He earned the manager-of-usability role inside the product team the same way he had earned trust on set: by accepting challenges, finding the people who knew more than he did, and self-educating his way to fluency. He created his own video tutorial system from script to finished video or written article. Within months he was the most challenging member of every UX review, and our senior UX designer respected him so much he sought Jesse out for review independently.

Markus Winkler arrived from the opposite end: twenty-five years in software, zero in lighting. I did not give him a separate education tract. I paired him with Jesse, Chi, and Dan Walters. These three came from the film and lighting world and would tell him plainly when an idea did not work from a practical perspective. Markus pushed back on feasibility and on good software practice. The tension was generative. After our third workshop, the team owned this and was setting its own agenda for me to approve. I led the team, not the tasks. I did not force process. I created structure. I coached. The team optimized the process then carried ownership of deliverables, quality, and deadlines.

I led the team, not the tasks. I did not force process. I created structure.

Olek, our product proxy, came up with the page-stack metaphor that became Lookstacks. He had never set foot on a film set. The idea came from using the app and noticing what the workflow was really asking to be. This is the kind of contribution that only happens when an environment encourages use, instead of only delivery.

Disagree Forwards

Every project, every feature, every UI choice started in the same place: the user. Before we drew a single wireframe, the team learned the user we did not have yet, not only the user already in our midst. That meant time in the field, time in conversation, and time teaching the domain. Cinema lighting, network protocols, colorimetry. Every team member learned each well enough to explain it to someone who had zero experience on a set. When a team can teach the domain to others, they are ready to build tools for it.

From there the cycle ran: user stories, UX prototyping, review, iteration. We established a two-week Agile sprint cadence and a four-week in-person workshop cycle. Workshops were where the team would argue and wrestle, sometimes strongly, over priorities, personas, and edge cases.

Building a team that could disagree like respectful professionals was more important than the product.

Building a team that could disagree like respectful professionals was more important than the product. I had the opportunity to combine introverts and extroverts with a wide range of experience and views. After three sessions of structured workshops and deliberate team-building exercises, they could make purposeful points toward each other, move from strong positions with sound arguments, and change each other’s minds with a collective satisfaction and zero resentment. The discipline was building time for feedback into every cycle and respectful reflection as a practice.

The new pace required adjustment. On a set, every second counts. In product, the better pace is efficient, not fast. “Go slow to go fast.” Move efficiently and what looks slow is decisive.

Nine Personas

The roadmap ran on a structured scoring model I built with the team. We identified nine user segments. Each had an assigned advocate, a team member who took ownership of that persona’s perspective. The advocates met monthly to force-rank their segment’s feature wishes. That force-ranked table fed the scoring model, which produced the dashboard.

Every slot on the board carried a point value, and those values were uneven by design. A scarce, high slot was worth far more than a permissive one, so where a brick landed mattered as much as the rank it earned. The algorithm read the board on those terms and folded in segment size, growth, competition, and other weights, turning the advocates’ force-ranked judgments into a scored, defensible output. The dashboards are what fell out: a straight ranking and an impact-versus-effort view, each tunable to the factor the team needed to interrogate. Both boards here are invented stand-ins, not the real thing.

The rules were deliberate. Only the segment advocate could move priorities within their segment. The advocates listened to each other, argued from evidence, moved from positions, and arrived at consensus.

Risk-Zero

An agentic harness transformed our ability to build and ship. The cost of trying a new feature, exploring a new idea, or spiking a piece of technical discovery dropped from months to afternoons. Cost and risk vanished.

With well-honed agents, a single developer working alone could run a SPIKE, do the technical discovery, or build an entire new feature. We could test an idea directly in the real codebase instead of building parallel sandboxes.

The cost of trying a new feature, exploring a new idea, or spiking a piece of technical discovery dropped from months to afternoons.

Agents are not a panacea. They fail at UI and at architecture. Left alone, they over-write themselves. The structure was not human-in-the-loop but human-as-designer. I stayed in the frontend lane, prompt-to-prompt with the work. Past the View layer, carefully crafted skills kept architectural consistency and repo hygiene. Math, agents handled well, given the right starting example.

Figma prototyping was the other de-risk. Our UX/UI designer would prototype each feature in Figma, preparing the design system tokens and layouts so that human and agent could implement quickly in code. Ideation often continued once a feature was partly implemented, but starting from prototype meant the design system stayed rigorous from the first line of code.

There were four harnesses: one for the Slyyd app (Rust, Swift, SwiftUI, UIKit, and some ruby for repo automation), one for The Vault (Ruby on Rails, TypeScript, and some bash), and one for the website, and one for our colorimetric tools (Python mostly). All four followed the same structure: human-as-designer at the front, skills enforcing architectural discipline behind, and highly optimized usage of context. Four agentic harnesses supported a single engineer working at the velocity of a small team.

By v1.5.1, what had been a multi-person team (peaking around five simultaneous engineers) was effectively a single engineer working with an agentic harness. Per-person throughput rose, not fell, through the team shrinkage. At v1.5.0 in the iOS codebase, I shipped 5.52 commits per active day. The senior iOS developer on the same team shipped 3.84 in the same window. The agentic harness was primitive at the time but its value was validated. Swift was my weakest language at that time and my job function is far from daily software development.

Nevertheless on the same days, I also shipped in Rails at 6.21 commits per active day. The senior dev was on one stack. I was on two. By v1.6, the aggregate rate held at 7.3 commits per active day across a fifty-seven-day window. Cross-stack, we achieved 1.5 to 2× productivity of a senior-iOS-without-agentic baseline, in stacks where I was not senior. In Python and our website, I was able to achieve a similar productivity rate.

Three stacks, one person, well-engineered agents: the work of three or four senior engineers, each native to a different stack. Quality did not slip. Bug share stayed flat across releases.

From Beta to Award

Five versions of Slyyd have shipped to the App Store: 1.1, 1.5, 1.5.1, 1.5.2, and 1.6. The release cycles are shortening. That is the team operating with more fluency, agentic harnesses, tooling automation, and a mature roadmap process.

The Interface

Lighting software typically looks and feels like the database and spreadsheet under its hood. Slyyd is the exception. The interface is designed to the same discipline as the apps storytellers use every day, easy at first reach and powerful with use.

Visual Patching & Project Setup

The operator patches each fixture by dragging it onto a layout, not by typing slot ranges. The patch lives where the rig lives, in the place it occupies on set.

Universal Fixture Support

Slyyd controls every modern fixture that is popular on film sets and that content creators use today: Aputure, ARRI, Creamsource, Nanlux, ETC, Fiilex, GLP, and thirty+ others. No additional plug-in or vendor app is required and all of the calibrated profiles are included even at the free tier. The Vault handles the mode-side translation work behind the scenes while providing updates from the cloud.

Lookstacks

A pages-based way to compose, name, organize, and share the lighting story for a scene or sequence. Familiar to anyone who has used Pages or Keynote. The feature that first made Slyyd useful as a production design tool, not just a control tool.

The Relative Encoder Wheel

A touch-based control surface that shifts any parameter dynamically while preserving relative value relationships across all selected fixtures. The first feature I built with the agentic harness, complete with dynamic weighting, velocity controls, and haptic feedback.

Even by v1.1, we earned The Hollywood Professional Association’s Innovation in Production and Capture Award (in 2026). The recognition was not of a product, but of a thesis carried through and an engaged team able to deliver.

Hardware Ambitions

There was a hardware chapter: a purpose-built fleet of network infrastructure devices for modern networks on film/tv sets with a custom operating system to run it.

I built two new teams. The hardware team covered industrial design, mechanical and electrical engineering, and UX/UI for a controller with on-board displays, encoders, buttons, and indicator LEDs. The hardware met IP65, EU RED, and UK PSTI compliance, and it stacked tool-free for fast set deployment. The OS team handled the operating system itself plus its web interface.

We built the OS around a common management interface with a single pane of glass experience: one session, all device updates and configuration. The OS has a user interface of which I am genuinely proud.

The Talents of the Many

Though I cannot describe the future plans or work-in-progress in detail, the direction is toward lighting as a time-based medium rather than a static configuration.

Slyyd contains real technical achievements: best-in-class color science, the universal-control thesis, an award-winning UI, clever use of Apple SDKs. None of them is the real achievement.

The real achievement was building teams within and against the problems. Doing this work meant finding and coordinating diverse individuals then coaching them to collaborate efficiently and effectively. One person could not have done it. One type of person could not have done it.

All problems are solvable with the right group.

Credits

App Team

Chief Software Architect

Markus Winkler

Manager of Usability

Jesse Skogh

Product Expert

Chuan Chi Chan

Dan Walters

Product Owner

Aleksander Kobylak

Development

Seweryn Załupka

Michał Miedlarz

Jakub Jankowski

Bartłomiej Łupiński

Wojciech Trzasko

Paweł Leszkiewicz

Jacek Grygiel

Backend

Łukasz Pająk

Rafał Camlet

QA & QA Automation

Piotr Walczak

Adam Bochenek

Daniel Piwek

Rafał Kubik

UX/UI

Tomasz Koszyk

Wojciech Wasilewski

Project Management

Katarzyna Stachowiak

Sławomir Kortas

OS Team

OS & Embedded Development

William Ferreira

Luigi Tosin

Ignacio Barreto

Front End

Gonzalo Piria

QA

Manuel Pigatto

Adriana Limonta

UX/UI

Manuel di Rago

David Cabrera

Project Management

Ofelia Freire

Alfonso Pintos