Climatescope
Product: I'm going to Morocco in December 2026 and wanted to know if it'd rain. Last time I went, I'd booked a once-in-a-lifetime night at a Sahara luxury tent, and of course that's the night it rained. I couldn't find a clear answer online, so I started poking around weather data on weekends. That turned into Climatescope, still rough, growing one country at a time, organized by region. I figured most people pick the country first, the region after.
I'm having fun with it, picking up new design tools like Impeccable along the way.
Today's prototype
Explore a country
Pick a country, check comfort and precipitation by region, and compare side by side.
Search any city
Free-form search for any major city.
Design system
Earthy and grounded. Honest, but not loud. Forest leads as the primary brand color, with Stone, Sage, Earth, Slate, Rain, and Ink each mapped to a weather meaning.
Data source
Early on, I decided Climatescope should be about historical climate, not forecasts. A forecast API can tell you whether it'll rain next week, but that's not the question I had. The question was: for a country I already want to visit, which regions are historically wetter, hotter, colder, or more comfortable in the month I'm going?
The challenge
Climate data is everywhere, but most of it isn't immediately useful. Weather station data is trusted and local, but coverage is uneven country to country. Forecast APIs are easy to call, but they're tuned for next week, not for a trip months out. The thing I kept coming back to was reanalysis data: consistent, scientific, and global, but it arrives as huge gridded datasets that have to be clipped, aggregated, and turned into something a person planning a trip could actually use.
Where it is today
Right now Climatescope runs on ERA5-Land, pulled as Zarr data and processed with xarray into precomputed region-month summaries. The app doesn't serve raw climate files; it boils them down into compact facts by country, region, month, variable, source, and normal period. That keeps it fast, transparent, and easy to extend as new countries come in.
Next: SQL queries
The next experiment is xarray-sql, which lets you query xarray datasets with SQL. A lot of the questions I want to ask are really filters and aggregations: show December rainfall by region, compare comfort across nearby regions, join climate summaries with destination data. SQL fits that shape better than custom Python.
I didn't add it in v0 because the first risk wasn't query syntax, it was trust. I needed to prove the raw climate files could be opened, clipped to believable region polygons, aggregated correctly, and reduced to a small product-friendly dataset. Putting a new SQL layer on top too early would have mixed two debugging questions: is the climate model right, and is the query layer right? Now that the pipeline is solid, xarray-sql becomes useful as an exploration and validation layer before I decide whether it belongs in production.
Region and polygon model
Climatescope regions aren't copied wholesale from any single source; they're a product decision. I start with country-level administrative polygons from geoBoundaries, usually at the smallest reliable level that's still practical to maintain. Then I group those units into traveler-facing regions, checking each grouping against a few things: do they touch geographically, do they behave similarly climate-wise, do they include a recognizable city or two, and does the grouping match how someone would naturally describe a trip? The final polygon for a region is the dissolved shape of those grouped units. Cities aren't the polygon source; they're labels and sanity checks that make the region explainable.
Splitting work between Claude and Codex
Claude and Impeccable handle the interface side: flows, layout, visual system, turning rough product intent into something usable. Codex handles the engineering plumbing: data processing, region aggregation, dev-server fixes, source validation, the connective code that keeps the prototype reliable.
The coordination is simple right now. Git carries the change history, branches and diffs make ownership visible, and STATUS.md acts as the shared handoff note for what changed, what's blocked, and what the next agent should pick up. The hard part isn't whether either agent can help; it's keeping state synchronized across people, agents, and tools.
Next step is to give the agents a shared channel, probably through a small MCP server, so they can pass project state, task ownership, citations, and unresolved questions to each other without depending entirely on my memory, Git archaeology, or the chat transcript.