Inspiration
Seasonal allergies are easy to underestimate, but they affect a huge number of people and can seriously disrupt daily life. In the United States, about 25.2% of adults and 20.6% of children had a seasonal allergy in 2024. Allergic rhinitis affects up to 60 million people each year, leads to roughly 4.1 million physician office visits, and contributes to more than $3 billion in pollen related medical costs annually.
What stood out to us was how generic most allergy tools still are. Most people only get a broad warning like “pollen is high today,” but that does not really help them make a decision. Allergy risk depends on the type of pollen, the user’s location, the weather, and even the time of day. Someone may react strongly to oak but not grass, or feel fine in one part of the city and miserable in another.
We wanted to build something that helps people act before symptoms begin, not after. That became the starting point for Allerion.
What it does
Allerion is a personalized allergy prevention platform that helps people understand what pollen risk looks like around them and what they can do about it.
Instead of giving a vague citywide warning, Allerion creates species specific, neighborhood level forecasts. It combines pollen data, location, weather, and bloom timing to tell users what may be affecting them, where the risk is highest, and when they should be more careful.
A user can check a 14 day forecast, view a local heatmap, and get clear prevention advice in plain language. If they upload a plant photo, Allerion can also identify whether it is a likely allergen and estimate its bloom stage.
The main idea is simple: make allergy risk visible early enough that people can plan around it.
How we built it
We built Allerion as a full stack project with a FastAPI backend in Python and a frontend designed around maps, forecasts, and user friendly explanations.
At the core is a phenology engine that estimates bloom stages for different allergen species across time. We used a six stage seasonal model to track how a species moves from dormancy to peak bloom and then declines.
To make the forecast more realistic, we combined three main sources. First, we used a base phenology table that gives us expected bloom timing by species and latitude. Second, we pulled recent flowering and budding observations from iNaturalist so the system could adjust to what is actually happening on the ground. Third, we used the Google Pollen API to calibrate the short range forecast.
We also used H3 spatial indexing to generate local map cells and build a heatmap that shows how severity changes across nearby areas. For explanation and guidance, we used Gemini to turn technical forecast outputs into summaries, advisories, and species explanations that a user can understand quickly.
Challenges we ran into
One of the biggest challenges was that local pollen forecasting is not straightforward at all. Public pollen data is often broad, incomplete, or limited to short time windows. Observation data is useful, but it can be uneven depending on place and season. Bloom timing also changes from year to year, so a static table is never enough on its own.
That meant we had to build a system that could still produce a useful result even when one of the inputs was weak or missing. We spent a lot of time making sure the pipeline could fall back gracefully instead of breaking.
Another challenge was turning scientific signals into something actually useful for a person making a real choice. A technically correct number is not enough. The user needs to understand what is happening and what to do next. We had to keep asking ourselves whether the output would genuinely help someone decide when to go outside, which route to take, or how to prepare.
Accomplishments that we're proud of
We are proud that Allerion goes beyond the usual “high pollen” label and gives a much more meaningful picture of allergy risk.
One thing we are especially proud of is the way we brought different kinds of data together into one system. We connected live observations, pollen forecasts, seasonal bloom timing, spatial mapping, and natural language explanation into a product that feels cohesive. That made the output much more useful than any single source on its own.
We are also proud that the project focuses on prevention. That matters because poorly controlled allergy symptoms can affect sleep, concentration, work, school, and general quality of life. Research has shown that productivity loss can rise sharply when allergic rhinitis is poorly controlled. So even small improvements in awareness and timing can make a real difference.
The heatmap, the species level forecast, and the plant photo feature all helped make the project feel practical rather than just technical. It does not only say that risk exists. It helps show where it is, what may be causing it, and what a user should do next.
What we learned
The biggest thing we learned is that allergy prevention is much more useful than allergy reporting.
People do not just need a number. They need context. They need to know what is triggering them, when the risk is highest, and how they can avoid it. Once we started building around those questions, the project became much clearer.
We also learned how important location really is. Even within the same city, risk can look very different depending on nearby vegetation, weather, and current bloom activity. That made local forecasting and map based guidance feel much more valuable than a general daily alert.
Finally, we learned that explainability matters just as much as prediction. A forecast only helps if the user can trust it and act on it.
What's next for Allerion - Ahead of every trigger.
The next step for Allerion is to make it part of the tools people already use to move through daily life.
A direction we are excited about is treating Allerion as an optional layer or extension inside map based platforms like Google Maps. A user could choose to turn on an allergy layer the same way they might turn on traffic or transit. Someone with pollen allergies could enable Allerion when planning a walk, run, or commute. Another person could enable a different need based layer that matters more to them, such as air quality, heat safety, asthma risk, or something built for their own health or lifestyle needs.
That kind of extension based model feels powerful because it gives people choice. Not everyone needs the same information, but everyone benefits when maps become more personal and more relevant to real life.
For Allerion, that would mean helping users pick safer routes, better times to go out, and lower risk areas near home, school, or work. Over time, we also want to improve personalization by learning from symptom history, adding more species and more regions, and building stronger forecasting with weather, vegetation, and user feedback.
The long term vision is to make allergy risk something people can plan around with confidence instead of dealing with after the fact. Allerion should help users stay one step ahead of every trigger.
Built With
- cloud-run
- docker
- fastapi
- firestore
- gemini-2.5-flash
- gemini-vision
- google-maps
- google-pollen-api
- h3
- inaturalist-api
- pydantic
- python
- react
- uvicorn
- vite
Log in or sign up for Devpost to join the conversation.