Brolly’s plain-text weather page is an AI product lesson
Brolly is not an AI app, but its plain-text weather interface shows what many AI tools still miss: dense information, shareable state, low friction, and enough restraint to make the product useful before it tries to feel impressive.
TL;DR: Brolly’s boring, text-first weather interface is a useful reminder for AI builders: clarity, shareable state, and low-latency pages often matter more than clever interaction.
What does a plain-text weather site have to do with AI?
The primary source here is the Hacker News post, “Show HN: Brolly, a plain-text weather forecast site.” Brolly is not pitched as AI. That is partly why it is useful.
The creator built it after the UK Met Office redesigned its site with more whitespace, scrolling, and animations. The complaint was not that the old product lacked visual polish. The complaint was that a practical tool became harder to read at a glance.
That should feel familiar to anyone using AI products right now.
A lot of AI interfaces still behave like demos. Big empty chat boxes. Animated states. Soft gradients. Vague “ask anything” prompts. They often hide the actual work: inputs, assumptions, intermediate state, history, what changed, what can be shared, what can be trusted.
Brolly goes the other way. It shows a 7-day forecast, previous day log, hourly rain, wind, temperature, conditions, UV, air quality, and pollen. It uses a single long scrollable column, designed for phones. It keeps visualizations, but makes them out of characters. The creator specifically called out hourly heat maps for pollen count as a favorite.
That is the interesting bit. Plain text does not mean no design. It means the design budget goes into density, contrast, scanability, and persistence.
AI tools need more of that.
Why is shareable state underrated?
One of Brolly’s best decisions is that all page state lives in the URL: location, selected day, expanded and collapsed sections. You can send someone a link and they see the same thing. You can bookmark it and return later.
This sounds small. It is not.
In applied AI workflows, shareability is still a mess. A model answer may depend on hidden context, a chat history, a temporary file, a tool call, a retrieval index, or a setting buried in the UI. Screenshots become the fallback because links are not faithful.
That breaks collaboration. It also breaks auditability.
Brolly’s URL-state pattern is a simple standard worth copying. If an AI product produces a useful view, that view should be addressable. Not just the app. The state. The prompt. The selected model if relevant. The source set. The filters. The tool outputs. The collapsed sections. The version where practical.
There are limits, of course. Some AI state includes private data or large artifacts. You cannot shove everything into a URL. But the product principle holds: if the user can see it, the user should be able to return to it or share it with the right permissions.
That is how tools become part of work instead of one-off magic tricks.
What should builders copy from Brolly?
Brolly’s implementation is also a good reminder that “boring” stacks still ship useful software. The creator says it uses PocketBase, Go, plain HTML, JavaScript, and CSS. Pages are backend rendered, with light JavaScript for interactions like next and previous day navigation without page jumps. Forecasts come from Open-Meteo, with a custom LRU cache on top of PocketBase’s SQLite database to cache forecasts for 5 minutes and avoid unnecessary API pressure.
None of that is fashionable. All of it maps to a real user need.
For AI builders, the parallel is obvious. Before adding agents, memory, voice, multi-modal flourishes, or autonomous workflows, ask whether the product has the basics right. Can users scan the output quickly? Can they tell what changed? Can they share the exact state? Does the page load without drama? Does the system avoid hammering upstream APIs? Does the interface degrade well when JavaScript, network, or model calls get weird?
The catch is that restraint does not demo as well as animation. A stable URL does not look like innovation on a stage. A 5-minute cache does not trend. But these choices are often what make a product feel trustworthy after the first week.
If you are building an AI tool, try a Brolly pass on one core screen: remove decorative chrome, make the important state visible, make the view shareable, cache the expensive calls, and design for a narrow mobile column before you design for a widescreen dashboard. The missed catch is that “plain” is not the same as lazy. It takes real product taste to decide what stays on the page.