Brolly launches a weather site built from tables and ASCII charts

Why it matters

Brolly shows how a solo developer can use AI to ship a differentiated consumer utility while keeping the product's defining interface decisions human-designed.

Jacob, a York-based developer who publishes only his first name, released Brolly on July 25th as a weather site for people who would rather scan a table than swipe through cards. In a launch post, he said the UK Met Office redesign had added whitespace, scrolling and animations, leaving him without the at-a-glance forecast he wanted.

Brolly turns a seven-day forecast into a single mobile-width column of text. Its York forecast starts with current temperature, wind, ultraviolet radiation and air quality, then moves through daily conditions, hourly precipitation, pollen and historical comparisons. Bars made from hash marks and dashes replace the charts, icons and maps found in mainstream weather apps.

Jacob says he "mostly made the site for myself." That constraint gave Brolly a sharper product thesis than many consumer weather interfaces: put the maximum useful information within one downward scroll, preserve the ability to compare hours and days, and make every view bookmarkable.

A forecast designed as a document

The unusual part of Brolly is its treatment of a forecast as a document rather than a dashboard. The seven-day table keeps temperature, average wind, gusts and precipitation in fixed columns. Selecting a day changes the hourly sections below without sending the user into a separate screen. Brolly also retains the previous day's weather, addressing the common question of whether today actually feels hotter, colder or wetter than yesterday.

Jacob drew aesthetic inspiration from Plain Text Sports, which compresses live scores and schedules into a similarly spare interface. He spent much of his manual design work on character-based visualizations, according to Brolly's technical and design notes. His preferred example is the pollen heat map, which displays hourly intensity using punctuation and marks the daily peak with an asterisk.

Brolly stores the selected location, day and expanded sections in the URL. A user can therefore send another person the exact forecast view rather than a generic city landing page. The design avoids an increasingly common weakness in interactive web products, where application state disappears when a page is shared or reopened.

The Met Office has acknowledged the tradeoff that prompted Jacob's project. Its FAQ for the refreshed app says the new design displays less information on one screen because the previous layout could feel cluttered, particularly on small devices. The agency says it has since made the layout more compact and is exploring ways to reduce unnecessary scrolling. Brolly makes the opposite interface bet: some users will accept a denser screen when the information remains consistently structured.

Plain-text styling over a small web stack

Brolly's interface looks like terminal output, though it remains a conventional web application. Jacob wrote it in Go with HTML, JavaScript and CSS, using PocketBase for server-side routes and its SQLite database for aggregated statistics and forecast caching. Light JavaScript reloads server-rendered sections when a user moves between days.

Weather and location data come from Open-Meteo, whose service draws from more than 30 weather models. Brolly caches location forecasts for five minutes to reduce calls to the upstream API. Jacob said the full service runs as one container on a 512MB DigitalOcean instance in London.

The implementation also reflects the economics of a solo side project built with current AI coding tools. Jacob says he manually defined Brolly's architecture, structure and interface while using AI to implement significant portions. "I wouldn't have had the time to build this site without it," he wrote, adding that he kept selected visualization and design problems for himself.

That division of labor matters for the finished product. Brolly's value sits in the information hierarchy and the small interaction decisions, rather than the amount of code required to retrieve and render a forecast. AI reduced the implementation burden while Jacob retained the product choices that distinguish the site.

Early traffic tested the minimalist infrastructure

Brolly's public statistics page showed 37,187 page views, 24,064 forecast views and an estimated 12,678 distinct visitors by late July 25th. Those are Brolly's own aggregated figures, and the site does not disclose how it calculates distinct visitors beyond describing them as estimates. Forecast and air-quality cache hit rates were above 90% when checked.

The burst of attention also exposed the limits of the small deployment. Some early users reported multi-second loading times, prompting Jacob to inspect the cache and page-rendering path. Another user traced part of the delay to Brolly's custom font, an awkward dependency for a product whose central promise is speed and visual restraint.

Users also challenged the phrase "plain text." Brolly sends HTML styled to resemble plain text; requesting the forecast with a command-line client still returns markup. Jacob said he would consider a true text-only mode.

That distinction separates Brolly from wttr.in, the established console-oriented weather service. Wttr.in supports terminal text, browser HTML, PNG, JSON and Prometheus output, with human-readable location paths that can be queried directly from a shell. Brolly offers a narrower browser experience, with stronger mobile navigation, previous-day comparisons and detailed character-based views for pollen, ultraviolet radiation and air quality.

The early requests for curl support point to Brolly's clearest expansion path. A real text/plain response would turn the same compact forecast into something developers could place in terminals, scripts and status bars. It would also force Jacob to preserve the product's most distinctive constraint: Brolly works because the forecast remains readable when every decorative element is removed.