The problem
Cherry blossom season is one of London's most searched-for seasonal events, but existing resources were static, inaccurate or hard to find. The best public option was a crowd-edited Google Map with static pins, with no way to tell whether a park had peaked or not yet bloomed. Climate change shifts bloom timing every year, so forecasts based on historical averages are unreliable. The only accurate source was social media, in real time.
Japan's annual sakura forecast, which combines temperature data with species-specific bloom models, served as a reference for what bloom prediction could look like.
Iterations
Iteration 1 came from a single prompt. It showed location pins and rough timing labels and looked reasonable, which raised the real question: how accurate was it?
Iteration 2 followed manual testing against Instagram. Battersea Park was blooming, and Swiss Cottage, which wasn't on any existing map, was blooming too. I added both with accurate statuses, which raised a new question: how could the map update in real time?
What I learned
Social media was the most accurate real-time source. It beat every static dataset for current bloom status, so a real product needs community submissions or social listening.
Unlisted locations are a significant gap. Swiss Cottage was missing from every map, so user-submitted locations would be essential.
AI coding is fast for prototyping, not for accuracy. A usable map took minutes, but manual validation was still essential.
The interesting problem is forecasting. Showing current status is useful, but predicting next week's peak bloom from temperature data would be new for London.
Next steps
Define the core user task first, whether that's reporting a bloom, saving a park or getting notified at peak. Then explore data sources such as weather APIs, iNaturalist observations or community submissions. Recording bloom dates this season would start a London-specific dataset, which next year's forecasting model would depend on.