Home Screen
Map View
Help Needed
Neighbors Support System
Damage Report

Porchlight: Help should never get lost in translation

The idea behind Porchlight started with a simple situation. Imagine a family sitting in a house after a hurricane. There is no electricity, phone signals are unreliable, and someone in the family needs urgent medical attention. A neighbor a few streets away might have exactly what they need, but they don't know about each other. Even if they somehow connect, they might not speak the same language.

That last part is something I kept thinking about.

After hurricanes like Ian and Milton affected Central Florida, many people had to depend on the people living around them. Neighbors often became the first source of help. But most of that coordination happened through scattered group chats, and language could easily leave some families out of the conversation. I wanted to build something that could make asking for help and finding someone nearby much easier.

That's how Porchlight came to life.

What inspired me

I wanted to approach disaster response from the perspective of an ordinary person who needs help, rather than someone managing an emergency response team.

Think about María, a Spanish-speaking woman whose father needs insulin kept cold. Her neighborhood has been without power for hours. Somewhere nearby, another person has a generator and a spare refrigerator. The problem is that they don't know about each other, and they don't even speak the same language.

Porchlight is built around connecting these two people.

Someone can tap the SOS button and explain their situation by speaking naturally. The app understands the request, figures out how urgent it is, and looks for neighbors who can actually help. They can then communicate through automatically translated messages.

I wanted the experience to feel simple enough that someone could use it while stressed, without having to fill out long forms or figure out complicated menus.

How I built it

I built Porchlight around three main steps: asking for help, understanding the request, and connecting people.

The first part is voice-based. A person can speak in their preferred language, and the app turns that into a structured request. Gemini helps identify what they need, how urgent the situation is, and whether someone vulnerable is involved. If something is missing, it asks a short follow-up question instead of making the user go through a long form.

The matching system was another part I spent a lot of thought on. A person asking for a refrigerator to store medicine shouldn't have to search through a list of random offers. Porchlight uses Gemini embeddings and Firestore vector search to compare the meaning of requests and offers. It considers distance and urgency too, then explains why a particular neighbor is a good match.

I also wanted language to stop being a barrier after people were connected. Messages are automatically translated, so two neighbors can have a conversation even if neither understands the other's language.

There are a few other parts that make the app useful during an actual disaster:

Offline support: Requests can be understood and saved on supported devices using Gemini Nano, then sent when connectivity returns.
Neighborhood map: People can see nearby requests and offers without needing a constant internet connection.
Damage reports: Users can upload a photo of damaged property and receive an itemized report with visible damage, possible hazards, next steps, and a claim-ready statement.
Block captain dashboard: Organizers can see open requests, urgent cases, supply shortages, and neighborhood activity. Gemini can also prepare situation reports using live data and official information found through Google Search.

Privacy was something I considered throughout the development. A person's exact address is only shared with the neighbor they are matched with. The AI doesn't receive their GPS position.

What I learned

One thing this project taught me is that using AI in an application is quite different from simply connecting an API and displaying its response.

The output has to make sense in the situation where someone is using it. For example, misunderstanding a normal request might be inconvenient, but misunderstanding a medical emergency could have much more serious consequences. That made me think carefully about urgency classification, vulnerable people, follow-up questions, and allowing users to review their requests before sending them.

I also learned a lot about semantic search. Matching two people based on what they actually mean, rather than looking for identical keywords, opened up some interesting possibilities. Someone asking to keep medicine cold and someone offering a generator might have completely different words in their messages, but their needs and abilities are closely related.

Another thing I learned was how much the user experience matters when building for stressful situations. Large buttons, readable text, fewer steps, language selection, and offline access aren't small design details here. They can determine whether someone can use the app at all.

Challenges I faced

One of the biggest challenges came during testing when our primary Gemini model became overloaded. I didn't want the entire experience to depend on a single model being available. To handle this, I added automatic switching between models with fast timeouts, so the app could try another model when the primary one wasn't responding.

Connectivity was another problem I had to account for. Disaster situations are exactly when internet access becomes unreliable. This pushed me to work on on-device request understanding with Gemini Nano, offline storage, automatic syncing, and an offline-capable map.

Privacy also affected how the matching system was designed. Sharing someone's exact location too early would create unnecessary risks. So I made sure that approximate locations are shown to everyone else, while exact addresses are only shared after a match.

Getting voice-based interactions to work across different languages while keeping the experience simple was another part that required careful attention.

What I'm proud of

I'm particularly happy with the idea that two people who don't speak the same language can still coordinate help without needing someone else to translate for them.

I'm also proud that Porchlight brings several parts of disaster assistance into one place, from finding a neighbor with the right supplies to documenting property damage and helping local organizers understand what's happening around them.

We built 84 automated tests covering the app, server, and shared logic. That was important because an application dealing with emergency requests needs more than a good-looking demo.

There is still plenty I would like to add, including SMS and phone-call support for people without smartphones, more language options, and connections with local community organizations and emergency services.

At its core, Porchlight comes from a fairly simple thought: during a disaster, someone who can help might be living just two streets away. They just need a way to find each other.

That's what I wanted to build.