Why I Built Island Watch

I built Island Watch because Vancouver Island status information is useful, but it is scattered.

If you live here, travel here, or try to plan around the Island, the question is rarely limited to one source. A road closure matters differently if the ferry is already delayed. A weather warning matters differently if power outages are spreading. A wildfire update matters differently if it affects a highway, a community, or an evacuation boundary. The information exists, but it usually lives in separate places with separate formats and separate assumptions about what the user already knows.

That fragmentation became the starting point.

The question I kept coming back to was simple: what on the Island needs attention right now?

Not "which agency has a feed." Not "how many alerts can I put on a map." The useful product question was more practical: can someone quickly understand whether the Island is mostly clear, whether a region needs attention, whether a route is affected, and where the information came from?

The original product idea

Island Watch started as a civic-status dashboard for Vancouver Island.

I wanted it to feel more like a regional public utility than a tech demo. That meant the interface could not just be a pile of incidents or a decorative map. It had to answer a few plain questions quickly:

• What is happening?
• Where is it?
• Does it affect movement or public awareness?
• What should someone check next?

That shaped the product more than any single feature did. The dashboard leads with a status brief, then gives people a map, active updates, region filters, route views, source links, and detail drawers. The goal is not to make the data look impressive. The goal is to make the situation legible.

That distinction matters. A map can be visually convincing while still being unhelpful. A long alert list can bury the one update someone needs. For Island Watch, I cared more about trust and usefulness than volume.

What made it hard

The hard part was not showing data. The hard part was making different kinds of public data behave like one product.

Road events, ferry notices, power outages, transit alerts, weather warnings, wildfire layers, and evacuation boundaries do not arrive in the same shape. Some are RSS feeds. Some are geospatial services. Some have coordinates. Some only have text. Some become stale quietly. Some are broad public-awareness signals, while others affect a specific route or community.

So the backend became a normalization problem.

Island Watch uses Supabase for storage and scheduled Edge Functions to ingest public/provider feeds. Each source has its own adapter, but the frontend reads a normalized alert model: status, severity, source, timestamps, affected regions, route context, public impact, freshness, and source links.

That model is what lets the interface treat a road closure, ferry disruption, outage, weather alert, wildfire, evacuation boundary, or transit alert as part of the same operating picture without pretending they are the same kind of event.

Trust became a feature

The more I worked on Island Watch, the more I realized the trust layer was not secondary. It was the product.

For a civic-status tool, being unclear is worse than being sparse. If the app cannot tell whether a source is fresh, it should say that. If an update is broad context rather than direct instruction, it should not be framed like an emergency order. If a notice comes from an original source, that trail should stay visible.

That is why source names, source timestamps, stale labels, source-health status, confidence, public-impact text, and original links became first-class parts of the interface. They are how the product earns permission to be useful.

It also pushed me to filter more aggressively. A public dashboard does not get better just because it shows everything. Planned construction that is weeks away can make the page feel like a calendar instead of an operating picture. Low-impact transit notices can drown out higher-signal regional updates. The product had to decide what belonged in the main view.

That judgment is easy to underestimate. It is also where the actual product work lives.

Why it matters to me

Island Watch is not an emergency service and it does not replace official sources. That boundary is important. The point is not to become the authority. The point is to make public information easier to understand, then keep the path back to the source clear.

That is the kind of software I like building: tools that sit close to a real situation and reduce the amount of effort it takes to make sense of it.

In this case, the real situation is regional awareness on an island where movement depends on highways, ferries, weather, power, and local geography. The work is partly technical: ingestion, normalization, scheduling, geospatial data, stale-state handling, and source-health systems. But the deeper product challenge is simpler: can the interface help someone understand what is going on without making them decode several public systems first?

That is why I kept building it.

Useful software often starts with a small act of translation. Take something messy, fragmented, and exhausting, then make it clearer without pretending it is simpler than it really is. Island Watch is my attempt to do that for Vancouver Island public status: one calm operating picture, built from many imperfect public signals, with the source trail still intact.