James Devonport's e-paper train board: build it small first

The essay's starting point is a reader's reaction to James Devonport's project: rather than immediately buying gear, the first thought was how to build it so it doesn't become a hassle later. That leads to a division of labour in which the small device is only responsible for display, while data fetching, business logic and layout all live in the cloud.

Two cautions follow from that architecture. One is about privacy: if personal data is involved, an image URL matters too, because putting a login on the page is pointless if anyone who knows the image link can view it. The other is about staleness — e-paper can keep showing a screen after power is lost, so a "site OK" message may simply be text that hasn't updated since yesterday. The essay therefore insists on always showing the update time and passing the data's own timestamp through to the final image, and on not relying on this one device for critical alerts.

The recommended build order runs from dummy data and on-screen layout on a PC, to real data with defined displays for normal, timeout and empty results, then stable fixed-image display on the device, and only last scheduled runs and retries. The writer's advice is to hold back the usual scope creep — weather, calendar, visitor counts, a voice assistant — and start with one screen and one data source, used on a desk for a few days, adding more only if it proves useful.