Relay

• 

Inspiration

The inspiration for Relay came from something I see almost every day on my way to school.

At my bus stop, there is a large broken tree branch that has remained there for a long time. Although it may seem like a relatively small problem, seeing it every morning made me curious about how communities handle infrastructure damage. Who is responsible for reporting it? How does that information reach the correct department? How do municipalities decide which problems to address first?

I began thinking about how these challenges become much more complicated during severe storms. A single storm can cause dozens of fallen trees, flooded roads, blocked intersections, damaged utility lines, and other hazards simultaneously. Residents may submit multiple reports about the same incident, while municipal response teams must determine which situations are most urgent and how to distribute limited personnel and equipment.

To better understand these challenges, I contacted Mr. Costa, the head of the Edison Department of Public Works in New Jersey, and asked him about how the municipality handles storm-related incidents.

He explained how storm reports arrive from residents, municipal employees, police, and fire departments. He also described how incidents are prioritized according to public safety, transportation impact, and infrastructure concerns, while crew assignments depend on available personnel, equipment, and the type of damage.

One statement particularly stood out to me:

"One of the greatest challenges is the volume of incidents that can occur simultaneously."

That observation became the foundation of Relay.

I realized that collecting reports was only one part of the problem. The greater challenge was transforming large amounts of scattered, sometimes overlapping information into organized, actionable response decisions.

Rather than creating another basic reporting form or damage map, I wanted to build a system that could support the entire coordination process, from receiving resident reports to prioritizing incidents, recommending capable crews, and documenting their resolution.

That idea became Relay.

What it does

Relay is a full-stack storm-response coordination platform that helps communities organize incoming damage reports, prioritize incidents, and coordinate response crews.

The application connects two sides of storm response: residents who observe damage and dispatchers who must decide what happens next.

1. Resident reporting and location verification

Residents can submit reports about fallen trees, flooding, blocked roads, utility hazards, and other storm-related problems.

Each report includes information such as the incident location, hazard type, description, and potential safety or transportation concerns.

Relay uses location search and interactive mapping to help users identify the correct location. It also validates locations against the supported service area before accepting them.

After submitting a report, residents receive a private tracking code that allows them to check its progress without creating an account.

2. Intelligent duplicate identification

During a major storm, multiple residents may report the same fallen tree or flooded intersection.

Relay identifies possible duplicates using deterministic comparisons involving geographic proximity, report timing, hazard type, and resident-provided evidence.

However, Relay does not automatically combine reports.

Instead, it presents possible matches for human review, allowing dispatchers to determine whether reports describe the same incident while preserving the original evidence.

This helps prevent duplicated work without allowing automated decisions to erase important information.

3. Explainable incident prioritization

Not every storm-related incident requires the same urgency.

Relay evaluates incidents using factors including:

• Immediate safety risk
• Transportation disruption
• Infrastructure impact
• Number of people affected

Rather than providing an unexplained priority score, the application displays the factors contributing to the recommendation.

Dispatchers retain control over the final decisions.

4. Capability-aware crew recommendations

Assigning the geographically closest crew is not always the best decision.

For example, a crew specializing in drainage work may be nearby but lack the equipment necessary to remove a fallen tree.

Relay evaluates crew availability and required capabilities before generating recommendations.

Crews that cannot perform the necessary work are excluded, and eligible crews can be compared using actual road-travel routes.

5. Response tracking and incident history

Once a dispatcher assigns a crew, Relay supports the progression of the incident through assignment, active response, and resolution.

Important actions are recorded in an incident history, including verification, duplicate decisions, crew assignments, location corrections, and status changes.

This creates a traceable record of how each incident was handled.

Relay's central purpose is not simply to show where storm damage occurred, but to help coordinate what happens afterward.

How we built it

I developed Relay as a full-stack web application, combining interactive frontend development, backend APIs, database management, geospatial services, and automated testing.

Frontend: TypeScript, React, and CSS

I used TypeScript and React to build the application's interactive frontend.

The interface includes resident reporting forms, location selection, incident queues, interactive maps, dispatcher controls, response histories, and a guided demonstration of the coordination workflow.

I used CSS to create a responsive interface with a visual style appropriate for a municipal operations platform.

One of my design priorities was making complex operational information understandable without overwhelming users with unnecessary controls.

Backend: Cloudflare Workers

I used Cloudflare Workers to implement backend application logic and process requests from the frontend.

The backend handles tasks such as validating incoming reports, managing incidents, calculating priority recommendations, evaluating crew eligibility, and controlling workflow transitions.

I designed server-side checks so important decisions would not depend solely on data submitted by the user's browser.

Database: Cloudflare D1 and SQL

I integrated Cloudflare D1, a SQL-based database, to store and manage the application's operational information.

This includes resident reports, incidents, response crews, assignments, and event histories.

I connected frontend actions to backend database operations so reports submitted through the website are stored persistently and can later be retrieved, reviewed, updated, and tracked.

I also implemented database constraints and consistency protections to reduce the risk of conflicting or repeated operations.

Mapping and routing

Relay integrates MapLibre GL JS and OpenFreeMap to display geographic information through an interactive map.

For road-based travel calculations, I integrated the OpenRouteService API.

Rather than simply calculating straight-line distances between crews and incidents, the application can compare routes using actual road networks.

I combined these services with capability-based crew filtering so routing recommendations consider whether a crew can perform the job.

Testing and reliability

As Relay grew, I created automated unit, end-to-end, and browser tests to check important workflows.

These tests helped verify behaviors such as report submission, location validation, duplicate review, incident assignment, response progression, and tracking.

I also used ChatGPT and OpenAI Codex during development for brainstorming, code assistance, debugging, and reviewing possible improvements. I made the project decisions, developed and revised the interface, integrated the database and external services, and tested and finalized the application's workflows.

Challenges we ran into

Building a connected system rather than separate features

One of my greatest challenges was ensuring that every part of Relay worked together.

Submitting a resident report affects the incident database. That incident may trigger duplicate review, receive a priority recommendation, require a particular type of crew, and eventually become part of an assignment and response history.

I had to carefully connect these processes so that an update in one part of the application did not create incorrect information elsewhere.

Reliable location verification

Location handling proved more complicated than I initially expected.

A typed address may return multiple possible results, map coordinates may not match the selected address, and residents may need to correct a location after initially selecting it.

I implemented verification and correction workflows to ensure incidents remain associated with valid locations.

Identifying duplicate reports

Two people may describe the same incident differently.

One resident might report a "fallen tree blocking the road," while another reports "large branches preventing cars from passing."

At the same time, two nearby fallen trees should not automatically be treated as one incident.

I had to balance identifying likely duplicates with avoiding incorrect combinations. I addressed this by developing comparison rules and keeping the final decision with a human dispatcher.

Preventing conflicting database updates

As the application became more sophisticated, I encountered problems involving repeated requests and conflicting actions.

For example, two simultaneous operations should not assign the same available crew to separate incidents, and a request made using outdated incident information should not overwrite a newer decision.

I addressed these issues using database constraints, guarded workflow transitions, version checks, and idempotent operations.

Making routing operationally meaningful

Initially, choosing a crew based on distance seems simple.

In reality, the closest crew may be unavailable, lack the necessary equipment, or already be responding to another incident.

I had to combine crew eligibility, incident requirements, availability, and road routing into a single recommendation process.

This became one of Relay's most important technical features.

Balancing functionality and usability

A dispatcher interface needs to present substantial information while remaining easy to understand.

I repeatedly revised the layout, typography, visual hierarchy, and map interactions to make incident details and available actions easier to find.

This taught me that building a technically sophisticated application is only useful if people can understand and operate it.

Accomplishments that we're proud of

My biggest accomplishment is developing Relay into an end-to-end application rather than stopping at a concept or a collection of disconnected features.

Some of the achievements I am most proud of include:

Building a complete resident-to-dispatch workflow. Reports can move from submission and verification through duplicate review, prioritization, crew assignment, active response, and resolution.

Integrating persistent SQL storage. Instead of simply displaying information in the browser, Relay stores reports and operational information in a database and connects that data to the application's workflows.

Developing explainable, human-controlled decisions. Relay supports duplicate identification, incident prioritization, and crew recommendations without removing human oversight.

Implementing capability-aware routing. The application considers which crews are equipped to respond before comparing road-travel routes.

Creating an incident audit history. Important decisions and status changes can be reviewed after they occur, helping make the response process more transparent.

Building automated tests. I developed tests covering important features and edge cases, improving my confidence that changes would not unintentionally break existing functionality.

I am also proud that I reached out to the Edison Department of Public Works before finalizing my approach. Learning directly from someone involved in municipal response helped me design features around real operational considerations rather than assumptions.

Perhaps most importantly, Relay began with an ordinary problem I noticed at my bus stop and grew into a technically challenging project that connects software engineering with a problem affecting entire communities.

What we learned

Developing Relay changed how I think about software engineering.

Before beginning the project, I often focused on whether I could successfully implement a particular feature. Through Relay, I learned that building a useful system requires understanding how people will interact with it, what can go wrong, and how different components affect one another.

One of my most important lessons was that understanding a problem should come before designing its solution.

My conversation with the Edison Department of Public Works showed me that response coordination involves far more than collecting damage reports. Different crews have different responsibilities, safety concerns can change priorities, and outside dependencies—such as waiting for a utility company to make an area safe—can affect when

Built With

• css
• git
• github
• html5
• javascript
• node.js
• react
• restapi
• sql
• typescript
• vinext