Climatescope
A travel-planning prototype that turns decades of climate records into clear regional comparisons for the month you want to visit.
Product: I'm going to Morocco in December 2026 and wanted to know whether it would rain. On my last trip, I booked a once-in-a-lifetime night in a luxury tent in the Sahara—and that was the night it rained. I could not find a clear answer online, so I started exploring weather data on weekends.
That experiment became Climatescope, a prototype that turns historical weather into region-by-region guidance for travelers. I am building it one country at a time because most people choose a country first and a region second.
What the prototype does today
Explore a country
Choose a country, compare its regions side by side, and see where the weather feels most comfortable or rain is most likely.
Search any city
Search for any major city without first choosing a country or region.
Design system
The visual system is earthy and quiet, matching the subject without competing with the data. Forest green leads the brand. Stone, Sage, Earth, Slate, Rain, and Ink each have a specific job, so the same color always carries the same weather meaning.
Data source
Early on, I chose to build around historical climate records rather than short-term forecasts. A forecast can answer whether it may rain next week. My question was different: once a traveler has chosen a country and month, which regions have usually been wetter, hotter, colder, or more comfortable? That distinction set the product's scope and its data needs.
The challenge
Climate data is plentiful but hard to turn into a travel decision. Weather stations are trustworthy and local, yet some countries have much better coverage than others. Forecast services are easy to use, but they are designed for the next few days, not a trip months away. I chose reanalysis data: a scientific reconstruction of past weather that combines observations with models to create one consistent global record. The trade-off is scale. The source files cover a grid across the land and must be matched to regional boundaries, combined, and translated into a few facts a traveler can use.
Where it is today
Climatescope now uses ERA5-Land, a global record of past land weather. I retrieve it in Zarr, a format designed for large data sets, and use the xarray Python library to calculate each region's monthly summary before a visitor opens the app. The product serves those smaller summaries rather than the enormous source files. Each fact keeps its country, region, month, measurement, source, and historical period, so pages stay fast and the number can still be traced to its origin.
Next experiment: ask questions with SQL
xarray-sql would let me write climate questions in SQL: show December rainfall by region, compare nearby areas, or combine climate summaries with destination information. Those questions are clearer in SQL than in a new piece of Python written for each one.
I left it out of the first version because the main risk was trust, not query language. First I had to prove that the source files opened correctly, matched believable region boundaries, produced accurate summaries, and became a small data set suitable for a fast product. Adding SQL earlier would have made mistakes harder to diagnose: was the climate calculation wrong, or was the question wrong? Now that the core processing works, xarray-sql can help me explore and double-check the data before I decide whether the product should depend on it.
How I define a region
Climatescope's regions are a product decision, not a copy of a single data source. I begin with country administrative boundaries from geoBoundaries, usually using the smallest dependable unit that remains practical to maintain. Then I combine neighboring units into regions that make sense to a traveler. I ask four questions: Are the areas connected? Is their climate similar? Does the group contain a recognizable city? Would someone naturally describe a trip this way? The outline shown on the map joins those smaller boundaries into one shape. Cities help name and double-check a region; they do not set its border.
How I direct AI collaborators
Claude and Impeccable help me shape how people move through the product, organize each screen, and turn rough intent into a usable interface. Codex handles climate-data processing, source checks, local development issues, and the code that connects everything. I remain responsible for the product decisions and final review.
Git records every change, separate branches show who owns each piece of work, and STATUS.md gives each collaborator the same handoff: what changed, what is blocked, and what should happen next. The hard part is not getting an AI tool to produce work. It is keeping people and tools aligned on the same facts and decisions.
Next I want to give those collaborators a shared channel built on Model Context Protocol (MCP), a standard for passing context between AI tools. It would let them share the current task, ownership, sources, and open questions without relying on my memory, old commits, or chat history.