Canopy

Canopy protects your home before the storm hits.

Comment

Inspiration

Natural disasters leave communities not only physically and emotionally devastated, but also burdened with a complex process to receive government aid and disaster relief funding. Affected individuals must gather extensive documentation and go through a process that is both time-consuming and overwhelming.

We found it problematic that people who have endured catastrophic events have to navigate government processes all by themselves, and this became the inspiration behind Canopy.

We set out to include features that would:

  • Improve the safety of homes prior to environmental disasters, specifically using eco-mitigation techniques and green infrastructure.
  • Enable users to maintain records of their property and shorten the application process when recovering from a natural disaster.

What it does

The main features of Canopy are:

  • Scoring your home’s safety based on a simple questionnaire and location
  • Recommending eco-mitigation measures that can lower the risk of damages
  • Automatically creating a package of essential documents for disaster relief
  • Estimating how much the user can receive during disaster recovery

The general workflow is:

  1. Account setup
  2. Enter ZIP code
  3. View the Regional Risk Overview page, which shows the relative possibility of each natural disaster happening in that region
  4. Answer a questionnaire about the user’s home
  5. System calculates My Canopy Score
  6. Receive eco-mitigation recommendations to improve the user’s Canopy Score
  7. Answer an additional questionnaire in the Recovery Center page
  8. Estimate eligibility and relief funding based on FEMA disaster assistance data
  9. Upload photos of damages and receipts
  10. Generate the Canopy Preparedness Report, Post-Disaster Damage Summary, and Expense Receipt Packet
  11. Download all reports as PDFs

How we built it

  • We built Canopy as a React 19 + Vite single-page web application.

  • We used Tailwind CSS for styling, React Router for navigation, Supabase for data access, and Recharts / react-globe.gl for data visualization.

  • The core experience begins with location-based disaster preparedness. Users enter a ZIP code, and Canopy connects that location to county-level regional risk data.

  • We processed disaster-risk data across roughly 3,000 U.S. counties to help users understand the environmental and disaster risks most relevant to their area.

  • We combine regional risk information with a home-readiness questionnaire to calculate a 100-point preparedness score.

  • Based on the user’s responses, Canopy generates personalized recommendations for improving household resilience before a disaster happens.

  • For the recovery workflow, we separated pre-disaster preparedness from post-disaster recovery.

  • After experiencing disaster damage, users can create a recovery profile and enter FEMA-relevant details such as ZIP code, ownership status, household income range, household size, home damage, and flood damage.

  • We connected the recovery form to a Supabase table built from FEMA Individuals and Households Program historical data, allowing Canopy to estimate a historical FEMA assistance range based on similar past cases.

  • We also explored a machine learning extension using Python, pandas, scikit-learn, and XGBoost.

  • We trained a two-step baseline model on approximately 1 million de-identified FEMA applicant-level records: one model for eligibility likelihood and another for estimated assistance amount.

  • This ML experiment helped us validate the feasibility of replacing our current rule-based estimator with a more personalized prediction system in the future.

Challenges we ran into

Backend

  • We initially planned to use Supabase authentication, but ran into significant blockers during the authentication setup. After spending a lot of time attempting to resolve the issue, we ultimately had to abandon that approach and pivoted to storing user profiles in localStorage instead.

  • Several questions appeared in different parts of the workflow but needed to be treated as one single source of truth when collecting questionnaire data across multiple sections of the app. Merging the overlapping data into one model was more difficult than anticipated.

Frontend

  • When refining the landing page, we implemented a globe feature using a dependency that required an API token. Because we did not catch this early enough, we committed and pushed the code, and reverting it back to its original state became very time-consuming.

Accomplishments that we're proud of

  • We built a complete disaster preparedness and recovery workflow. Canopy connects pre-disaster user information, regional risk awareness, recovery planning, document preparation, and FEMA assistance estimation into one unified platform.

  • We integrated real public disaster data into the product. We processed regional disaster-risk data across roughly 3,000 U.S. counties and used it to help users understand their local environmental and disaster vulnerabilities.

  • We implemented a FEMA assistance estimator using historical data. Instead of relying only on mock logic, we used FEMA’s Individuals and Households Program data to build a historical assistance estimate based on similar past cases.

  • We successfully connected Supabase with a large aggregated FEMA dataset. We processed the original FEMA dataset, created an aggregated summary table, imported 471,713 rows into Supabase, fixed access issues, and connected it to the frontend.

  • We trained a machine learning baseline for future assistance prediction. We trained a two-step model using approximately 1 million FEMA applicant-level records. Our eligibility classifier achieved an AUC of 0.847, and our assistance amount model reached a mean absolute error of about $1,440.

  • We turned a broad idea into a functioning MVP. During the hackathon, we refined Canopy from a general disaster-recovery concept into a working web application with structured pages, user inputs, risk insights, and recovery support features.

What we learned

  • Vague planning slows down development. We learned that when the initial plan is too broad, implementation becomes slower because page responsibilities, feature boundaries, and data flow are not clearly defined. For future projects, we would design the product structure in much greater detail from the beginning, considering each feature and user interaction before writing code.

  • Disaster-risk data requires more precise statistical methods than simple normalization. While implementing our Regional Risk Dataset, we processed data for roughly 3,000 U.S. counties. Even after normalization, most regions showed very high risk scores. We learned that because the minimum and maximum values for each disaster-risk category vary widely across all U.S. counties, simple normalization is not always effective. This made us realize the need for a more precise statistical approach, such as percentile ranking, weighted scoring, outlier handling, or region-specific baselines.

What's next for Canopy

  • Expand Canopy beyond the U.S. with global disaster assistance datasets
  • Upgrade our current rule-based FEMA estimate into a machine learning model for more personalized assistance predictions
  • Make the questionnaire adaptive so users only answer relevant questions
  • Automate disaster recovery applications and document preparation
  • Add a recovery support chatbot to guide users through next steps
  • Recommend eco-friendly mitigation measures to reduce future disaster risk

Built With

  • fema-individuals-and-households-program-valid-registrations-v2
  • fema-national-risk-index-data
  • github
  • hud-usps-zip-code-crosswalk-files
  • javascript
  • jsx
  • react
  • supabase
  • tailwind-css
  • vercel
  • vite
Share this project:

Updates

Submission history