Most dashboards end up in a tab you no longer open. You set them up with enthusiasm, connect the sources, pick the charts, and three weeks later they sleep behind fifteen other tabs. The problem is not the data, it is the medium: a number hidden behind a click carries no weight in a day. Taking a KPI out of the computer and showing it in the real world, permanently, changes that. I happen to build this kind of object, so here is what I have learned to do, and not to do.
Which data is worth displaying
A physical display's constraint is also its strength: it shows one number at a time. That forces you to choose. The right data answers a single important question, the one you want to keep under your eyes. For a software founder, that is often MRR, monthly recurring revenue. For a shop, the day's sales count. For a creator, followers or views. For an investor, a portfolio value. The wrong instinct would be a vanity metric that only ever goes up and decides nothing. Choose the number that, if it drops, makes you react.
The technical principle: API, webhook, refresh
Almost every modern tool exposes its data through a programmable interface, an API. A payment service knows your revenue, a store knows its orders, a code repository knows its stars. The display's job is to fetch that number and show it.
Two approaches exist. The first queries the platform's API directly from the device. Simple, but fragile: the day the platform changes its authentication or closes its API, the display stops. The second, which I prefer, goes through a webhook and an automation tool such as N8N. A small workflow queries the source at a regular interval, formats the value, and pushes it to the device. If the platform changes its rules, you edit the workflow, not the device. The refresh is set to need: every sixty seconds suits revenue or followers, a few seconds for a fast-moving price.
Concrete steps to connect a source
Take MRR shown from a payment service. The principle is the same for other sources.
One, create a read-only access key on the source side. You never give a display more rights than needed. Two, in your automation tool, create a workflow triggered every minute that fetches the wanted value, for example monthly recurring revenue. Three, transform the data if needed: round it, convert a currency, keep only the integer. Four, send the result to the device through its webhook. Five, set the frequency and check the displayed value matches the source. Within minutes, your number lives in the room.
The pitfalls to avoid
The first pitfall is depending directly on platforms' public APIs, especially social networks, which change often. The webhook detour is insurance. The second is over-frequency: refreshing every second a value that moves once a day burns API quotas for nothing. The third is the wrong metric, which makes the object decorative instead of useful. The fourth is security: a read-only key, never an admin key.
Tube or flap: showing the value and its label
That leaves legibility. A number alone, out of context, forces you to remember what it represents. That is why, on our devices, the value shows in figures on the Nixie tubes and, in the Signature configuration, the label shows spelled out on a row of flaps: MRR, VISITE, VENTES. The data and its nature are read together. The details are on the Signature option page, and the subscriber counters on the subscriber counter page.
The essentials
Displaying a KPI on a physical screen is only worth it if the data is well chosen and the display reliable over time. Pick a single number that matters, connect it preferably through a webhook rather than depending directly on a fragile API, set a reasonable refresh frequency, and use read-only access only. The best display is not the one that shows the most data, it is the one you actually look at.