The Starting Point

A hailstorm can damage cars, homes and plants within minutes. Official meteorological hail warnings, however, cover larger geographical areas and require users to keep checking them. If someone does not look at the weather forecast that day, they may not know whether rain or even hail poses a risk at their home address. The client wanted to solve this problem.

The idea was that users should not have to open or check anything. They subscribe once and only hear from the service when they actually need to take action. We developed the web application's landing page, administration interface, risk assessment algorithm and notification system.

What the Solution Needed to Do

During the discovery phase, we identified four requirements that guided the subsequent decisions:

• Make alerts personal: warnings should apply to the postcode provided by the user rather than an entire county or larger region.

• Send notifications in time: users need enough warning to move their car under cover or protect valuables left outdoors.

• Avoid unnecessary alerts: an alert system loses its value when people become accustomed to notifications that do not matter. False alerts therefore had to be minimised.

• Require no app: much of the target audience would not install an application for a seasonal service, so alerts are delivered via Viber and SMS.

There was another technical consideration: hail is a seasonal phenomenon. For most of the year, the system primarily monitors conditions, while during a summer storm it may need to reach thousands of people within minutes. The architecture was designed to operate reliably under both normal monitoring conditions and seasonal peak loads.

The Hardest Question: When Should an Alert Be Sent?

A key focus of the project was the algorithm as well as the user interface. An external weather data source continuously provides information about hail risk and lightning activity. On their own, however, these signals do not answer the essential question: should subscribers in a particular postcode be notified at that moment? This decision needed to be transparent and adjustable.

We therefore developed a custom risk assessment algorithm. It evaluates and weights incoming signals together, then determines whether an alert is required and, if so, whether it should be yellow or red. The algorithm is configurable, allowing the client to fine-tune its behaviour based on experience during the season without requiring additional software development.

Calibration — and particularly deciding when not to send an alert — was one of the more complex aspects of the project. A severe thunderstorm with intense lightning can generate numerous signals even when there is no hail. The algorithm therefore does not treat every input equally. As a result, a lightning-heavy storm without hail does not automatically trigger a hail alert.

For geographical calculations, we introduced the H3 cell system, which divides the world map into hexagonal cells. Postcode boundaries were covered with these cells to reconcile two different geographical models: continuously moving storm zones and a fixed subscriber base tied to administrative boundaries.

How We Tested It

A hail alert system is triggered unpredictably and relatively infrequently in production, yet it needs to be tested continuously. As part of the development, we therefore built a dedicated simulation module that models storm movement alongside weather data.

This makes it possible to simulate and verify the entire alert chain: which postcodes are at risk, what alert level is generated, and whether the message successfully reaches the recipient.

Results

By the end of summer 2026, the service had more than 61,000 subscribers.

Technologies and integrations: PHP, Vue.js, H3 cell system, external weather data source, Viber and SMS notifications, Hetzner infrastructure with load balancing.