On 1 August, Matt Webb did not announce a new clock. He asked Poem/1 owners to take a computer, follow a procedure and install firmware manually.1 The update was meant to fix cases where Wi-Fi or the backend could leave a device stuck; it also added automatic updates and a third font, Shantell.
That is not the kind of announcement that makes a beautiful product sheet. It is exactly why it deserves attention. A connected clock is not finished when it arrives in a box. It keeps revealing its architecture through unpredictable routers, changed servers, ageing displays and owners who did not buy a decorative object in order to flash it.
A clock that depends on several places
Poem/1 displays a new poem every minute. Its manual explains that poems are composed on poem.town and fetched over Wi-Fi, so the clock needs an internet connection to behave as intended.2 The visible hardware is deliberately simple: a 4.7-inch e-paper display, one top button, a USB-C cable, 2.4 GHz Wi-Fi and no Bluetooth.2
That visual simplicity hides a distributed chain. Power arrives through the cable. The network passes through the owner’s router. The clock gets time, contacts a service, receives content and displays it. A failure can come from radio, authentication, an API change, server availability or local recovery logic.
Webb’s post describes a rare bug that could affect some clocks for a week before disappearing.1 That detail is more useful than the word “bug.” On a prototype, the maker can restart the object, inspect logs or change code immediately. In a home, the same state becomes a support relationship: someone must know it exists, understand what the device can still do and provide a repair path without opening the case.
The first firmware is a conversation
The current manual formalises that conversation. The first update must be installed manually from a browser on a computer; future updates can then arrive automatically over Wi-Fi.2 The tool walks owners through the process, validates the file and warns them not to unplug the clock while it writes. A recovery route also exists through Wi-Fi configuration mode and the local address 192.168.4.1.2
This is not an App Store, and it is better not to pretend otherwise. The owner has to understand that the object has a software version. They put the clock into setup mode, join its temporary network, open a page and wait for a reboot. For a maker, the procedure is reasonable. For someone who wanted to hang a clock on a wall, it is already a design debt.
OTA reduces that debt for future fixes. It cannot erase the initial debt: the first automatic mechanism has to be delivered through a manual path or installed at the factory. Automatic updates are not an isolated feature. They are the last link in a recovery chain that must account for failed writes, lost networks and power being removed too early.
The manual is explicit about one physical risk: never unplug during an e-paper display update, because permanent damage may result.2 A detail like this changes the interface tone. Software cannot merely display “update available.” It has to protect the physical action around the device.
Making an object means making its second version
A year before the update, Webb wrote from Shenzhen about manufacturing Poem/1.3 The post does not describe an abstract supply chain. It describes enclosure iterations, first pieces from a pilot assembly line, ageing tests and a display-damage risk that needed fixing. A 100-unit pilot was intended for certification and end-to-end warehouse tests.
That material story gives the update context. Firmware is not a file floating independently from the product. It has to match a board, power supply, assembly procedure and recovery situation. A code change can make a factory step more reliable; a factory defect can require a firmware change. Software and plastic learn together.
Webb’s Kickstarter launch shows the other side.4 He describes a prototype becoming a funded project, then the work of finding a manufacturing route and moving into real production. He also describes a server that composes poems and a no-subscription product funded by setting aside part of the initial price for generation and server costs for several years.4
That economic promise is not a guarantee forever. It is a design choice. The maker has to estimate the cost of a service after sale, then decide what the device does if costs change. Firmware support belongs to the same invisible economy: every fix needs diagnosis, a tool, a tested release and an explanation an owner can follow.
Seven hundred clocks become a fleet
In the August request, Webb says more than 700 clocks have shipped and that only 26% of active clocks were on the latest firmware at the time.1 Those figures do not measure product quality by themselves. They do reveal something unavailable in a purely offline object: once sold, the hardware becomes a fleet with a version distribution.
Twenty-six percent does not mean that other owners neglected their device. The process was manual. For a clock that works most of the time, the incentive to interrupt daily life is weak. Not updating may be the rational result of friction designed by the maker.
Telemetry changes that relationship but raises other questions. Knowing which version is installed can help prioritise a fix without collecting poem content or a person’s identity. The manual explains that each clock has a four-character code and a page for claiming and personalising it.2 The link between device and account is useful; it deserves the same careful documentation as the firmware.
The product is therefore a small administrative system: versions, identifiers, claimed device, network, backend and recovery procedure. A poetic object does not escape infrastructure. It makes infrastructure visible when it stops.
Can the service outlive its maker?
The developer documentation exposes a rarer idea: a Device API for creating other clocks or replacing the poem.town backend.5 It also describes posting notes from scripts or third-party applications. A closed object could keep content, identity and server in one silo. An API opens a small door to another architecture.
Jay Goldman has already explored that possibility with Home/1, an MIT-licensed open-source compatible server.6 He describes a local service that lets owners configure their device without depending entirely on the original backend. This is a community project, not a promise of support from Webb; it would be wrong to call Poem/1 “decentralised.” It is concrete evidence that a documented protocol can extend an object beyond its first service.
An API does not solve everything. The expected format, configuration process, update procedure and licence still matter. Replacing the backend also changes the experience: poems, timing and data may no longer match the maker’s intention. Interoperability preserves possibility, not intention.
Fixing an object you cannot see
The central problem of independent hardware is distance. During prototyping, the maker has the object on a desk. After shipping, it exists in hundreds of homes behind different routers and habits. A rare bug may be impossible to reproduce locally. Support becomes investigation: ask for a version, displayed message, network state and reboot; translate those observations into code and instructions.
OTA is a logistical answer as much as a technical one. It does not make the software smarter. It shortens the distance between diagnosis and correction, letting the maker ship a fix without asking every owner to become an installer.
It also imposes discipline. Firmware needs validation, versioning, recovery, write protection and a decision about what happens when the backend is down. An automatically updated device receives authority from a distance. Trust does not come from the word “automatic”; it comes from the procedure surrounding that authority.
Maintenance is a creative feature
It would be easy to summarise Poem/1 as a new font, Shantell, offered to owners who update.1 That misses the creative work. The difficult part is maintaining a relationship between a small display, intermittent connectivity, a remote service, economic expectations and people who did not buy a development kit.
Webb’s manufacturing post insists on making things, understanding iterations and showing the steps instead of presenting production as a miracle.3 The update extends that lesson to owners: the object is not merely delivered; it can be revisited, corrected and documented.
Poem/1 does not prove that every connected object should use open services, or that automatic updates create durability. It shows a narrower case. Someone making a small-run object has to design the afterlife as soon as a network is added. Server choice, recovery mode, update format and API become design decisions alongside the case and the typeface.
The real product begins after the first clock ships. It begins when a machine stops behaving like the prototype and becomes a collection of real situations. A maker’s quality is visible not only in the initial idea but in the way they return to the object, listen to what happened and give the next correction a chance to arrive.