Skip to main content
Back to case studies Zonehaven

Zonehaven — Public Alerts & Evacuation App

We built AWARE, Zonehaven's citizen-facing app: real-time evacuation zones, push alerts and an offline-first map. Acquired by Genasys.

Next.js React Mobile App Push Notifications GIS GovTech SaaS
155M+
People protected
100+
Countries
50
US States
Zonehaven - Project overview

Soamee built AWARE, the community-facing application for Zonehaven — an evacuation management platform later acquired by Genasys Inc. (NASDAQ: GNSS), a global leader in critical communications and mass notification. Today that technology is part of a system protecting more than 155 million people across over 100 countries and all 50 US states.

Our brief was the part that reaches the person: the piece that turns a decision made in an emergency operations center into a clear instruction in the pocket of someone about to leave their home.

The challenge

An emergency app is unlike any other digital product. It breaks almost every product rule we take for granted:

  • There is no onboarding. Nobody downloads it “to try it out”. They open it for the first time when there is already smoke on the horizon, hands shaking, with no patience for a tutorial.
  • There is no average traffic. It sits idle for weeks and then takes a flood of simultaneous opens in the same geographic area — exactly when the mobile network is most congested.
  • There is no room for ambiguity. A sentence that can be read two ways isn’t a UX problem: it’s a person leaving when they should have sheltered in place.
  • It cannot depend on the network. In wildfires, floods or earthquakes, communications infrastructure is often the first thing to go.
  • It cannot ask for data. A public safety tool that demands sign-up, accounts and consent forms loses exactly the people it needs to reach.

On top of that there is the nature of the sender. Alerts aren’t written by a marketing team: they are issued by firefighters, civil protection, sheriffs and emergency managers, each with their own vocabulary, protocols and regulations. The app had to be the common denominator for all of them without betraying any of them.

Our solution

We worked with Zonehaven to build AWARE using Next.js and React, with one very specific goal: answer three questions in under five seconds — what is happening, does it affect me, and what do I do right now.

Real-time zone map

The heart of the app is an evacuation zone map. Each zone is a polygon defined by the responsible agency, and carries a status that changes live during an incident:

  • Evacuation order — leave now, via the indicated route
  • Evacuation warning — get ready: documents, medication and pets
  • Shelter in place — stay indoors, seal doors and ventilation
  • Safe zone — no active restrictions

Users find their zone by geolocation or by searching an address, and see its status with the matching instruction — nothing to interpret. The map layers in what actually matters during an evacuation: recommended routes, road closures, shelters and reception centers, and assembly points.

Geo-targeted push alerts

The app resolves the user’s location against active polygons and only notifies when they are genuinely affected. That filter is what separates a useful tool from a source of noise:

  • Current-location alerts that follow the user if they move during the incident
  • Followed locations (home, work, the kids’ school) that keep alerting even when the user is far away
  • Immediate notifications whenever a followed zone changes status
  • Preparedness resources: guides and checklists so people are ready before an emergency strikes

We prioritised native push over any in-app live channel for one simple reason: it arrives with the app closed and the phone in a pocket, which is the real-world situation 99% of the time.

Designed to be read under stress

Every interface decision optimised for the worst-case scenario, not the demo:

  • One visible action per screen. The primary instruction always above the fold, no scrolling.
  • Colour never travels alone. Every status combines colour, a text label and its own icon, so it works with colour blindness, in direct sunlight, or as a black-and-white screenshot forwarded over WhatsApp.
  • Contrast verified against WCAG 2.1 AA, with large type and generous touch targets: this app gets used in a hurry, with gloves on, or with the phone in the wrong hand.
  • Literal language. “Leave now via Route 1 northbound” instead of “evacuation should be considered”.
  • Hierarchy by criticality, not chronology: an evacuation order never sits below a roadworks notice.

Offline-first architecture

We assume the network will fail, because in a real emergency it does:

  • Service Workers pre-cache base maps, zone geometries, routes and preparedness guides when the app is installed
  • Cache-first for all static content, with background revalidation as soon as connectivity returns
  • Local persistence of the last known status for followed zones, always visible without coverage and with an explicit timestamp so users know how fresh it is
  • Automatic sync when the signal comes back, with nothing for the user to refresh
  • Minimal payloads and compressed assets, built for congested or degraded networks mid-incident

Built for the peak, not the average

An emergency app’s load pattern is a brutal, geographically concentrated spike. The architecture answers that: static content served from a CDN with edge caching, small cacheable API responses, notification delivery through fan-out queues, and graceful degradation — if something has to fail, it’s the accessory features, never the zone status and the safety instruction.

The digital channel of a bigger system

AWARE didn’t live alone: it was the digital channel of an alerting system that also reaches people through SMS, voice calls, sirens, radio and television. Part of our job was making sure the digital channel spoke exactly the same language as the rest — same statuses, same zone names, same instruction — so nobody received two different versions of the same order.

Technical architecture

AWARE technical architecture

Life cycle of an alert

Life cycle of an alert, from the emergency dashboard to the citizen

Results

The Zonehaven platform was acquired by Genasys Inc., validating the technical quality and value of the product. Today Genasys technology — Zonehaven included — protects over 155 million people across more than 100 countries and all 50 US states. The platform has been featured in outlets such as Fox News, NPR, Inc. Magazine and SF Gate.

  • 155M+ people protected globally through the platform
  • Coverage in 100+ countries and all 50 US states
  • Guaranteed offline availability of critical evacuation data
  • Zero access friction: no sign-up, no barriers exactly when it matters most
  • A single visual language for zone statuses, reusable by any issuing agency without adaptation
  • Successful acquisition by Genasys Inc.

Key technical decisions

  • Next.js with SSR: chosen for the combination of first-render performance (critical for emergency access) and static generation for preparedness content.
  • Offline-first, non-negotiable. We’d rather show the last known status with its timestamp than an error screen: in an emergency, ten-minute-old information beats none by an infinite margin.
  • Native push as the primary channel, over WebSockets: it’s the only one that arrives with the app closed, which is the app’s normal state.
  • Geometry on the client where possible. Answering “am I inside this zone?” on-device cuts latency and works with no network at all.
  • CDN with edge caching, essential for a product operating in 100+ countries with geographically concentrated spikes.
  • A universal status colour code, accessible and language-independent, verified against WCAG 2.1 AA.

Tech stack

  • Next.js (core framework, SSR)
  • React (user interface)
  • Service Workers and local storage (offline-first strategy)
  • Push notifications (emergency alerts)
  • Geolocation and interactive maps (GIS layers: zone polygons, routes, shelters)
  • CDN with edge caching
  • Google Analytics (analytics)

What we took away from this project

Working on emergency technology changes how you design product. The usual metrics — time on screen, sessions, retention — mean nothing here: the best possible outcome is that someone opens the app, understands what to do in three seconds, and closes it. It’s a product measured by how quickly it gets you to stop using it.

It also left us with a rule we’ve applied to everything we’ve built since: design for the worst day, not for the demo. If it works on a bad network, in a hurry, under stress and on an old phone, it will work the rest of the time.

Need an app that works when everything else fails? Explore our mobile app development service →

Methodology

How we work

Every project follows our artisan process, adapted to each client's specific needs.

01

Discovery & Requirements

Deep dive into business, users and objectives. Ideation workshops, market research and MVP scope definition.

02

Design & Architecture

Wireframes, interactive prototypes and technical architecture. Client validation before writing code.

03

Development & Testing

2-week sprints with demos. CI/CD, code review and continuous testing. Feedback every iteration.

04

Delivery & Evolution

Production deploy, monitoring and support. Post-launch metrics and continuous improvement roadmap.

Ready to build something amazing?

Let's talk about how we can help your company achieve results like these.

Book a free call →