GridGuard

Helping utility teams identify nearby projects, reduce conflicts, and coordinate crews and equipment more efficiently.

Inspiration

Utilities often plan large construction projects years in advance, but those plans are not always coordinated across companies. That can lead to situations where multiple utilities perform construction in the same area at different times, creating repeated road work, duplicated costs, and missed opportunities to share crews, equipment, or other resources.

We built GridGuard for the Sperry Tech challenge to help identify those overlaps earlier and make utility project coordination easier.

What it does

GridGuard compares utility construction projects based on location, project type, and schedule.

When projects are near each other, GridGuard helps identify whether they may have an opportunity to coordinate. Projects can be categorized visually so users can quickly see whether nearby work is similar, different, or not overlapping.

The application also includes an interactive map that automatically zooms to selected project locations, making it easier to understand where projects are happening geographically.

How we built it

We started by building the project-matching logic, since that is the core of GridGuard.

The system compares project information such as location, project type, start month, and start year. From there, we built the backend using Python and Flask and connected it to a PostgreSQL database through Supabase.

The frontend was built using HTML, CSS, and JavaScript. It allows users to enter project information, view existing projects, and see project locations on an interactive map.

We also created a color-coded project legend:

Green Nearby project with the same type of work
Red Nearby project with a different type of work
Grey No nearby project During development, we used both public utility-related data and a mock dataset so we could continue building and testing consistently.

Challenges we ran into

Every ISO reports data a little differently, and interconnection queues skew toward big transmission projects, not routine utility work so we had to be honest about scope.
Network access during dev was unreliable, so we leaned hard on a mock dataset to keep testing (and demoing) possible.

-Another challenge was unreliable network access during development. To make sure we could continue testing and demonstrate the application reliably, we created a mock dataset that followed the structure of the real project data.

We also had to determine how to compare location, work type, and timing in a way that was simple enough for a hackathon prototype while still demonstrating the larger concept.

Accomplishments that we're proud of

-Built a working prototype that combines frontend, backend, database, and mapping functionality

-Worked with real public utility-related data instead of relying completely on synthetic examples

-Built an interactive map that automatically zooms to selected project locations

-Created project matching logic to identify nearby work

-Added a color-coded legend that makes project relationships easy to understand

-Connected project data to PostgreSQL through Supabase

-Gained a better understanding of the real coordination challenges utility companies face

What we learned

Public utility planning data is scattered across formats — some real-time-ish, some annual filings, some state-specific reports

-Learned more about how to handle data and use it for postgreSQL to be used in the backend

-We also learned more about structuring data for PostgreSQL, connecting a Flask backend to a database, and designing a frontend around geographic project information.

-Most importantly, we learned that the technical challenge is not only detecting projects that are close together, but also making that information understandable enough for companies to act on it.