Work · Case Study · Data Platform

ExoVzn

A storm-intelligence platform: 600 million weather records, a multi-source correlation engine, and an automated report factory — built from a peer-reviewed forensic methodology that previously existed only on paper.

Platform design, build & ongoing engineering Visit the live platform →

The ExoVzn homepage on a dark background, headlined “Storm Intelligence Meets Expert Training”, with three product cards: Weather Check Reports, Expert Training, and Expert Network.

The brief

ExoVzn's co-owner is a licensed Professional Engineer and Diplomate Forensic Engineer who had spent five years publishing a weather-verification methodology in the Journal of the National Academy of Forensic Engineers. The method was sound, peer-reviewed, and — as software — did not exist.

Verifying whether hail actually struck a specific roof on a specific date is genuinely hard. The authoritative data is scattered across federal databases, radar-derived products, warning archives, and volunteer observer networks. Each source disagrees with the others in predictable ways. Doing it properly meant a trained expert spending hours per property, which does not scale to an industry that needs thousands of these.

The brief: turn a published methodology into a system that produces the same rigor automatically, at a price a contractor or public adjuster would actually pay, without ever overstating what the data supports.

What we built

An ExoMaps hail swath map showing MESH-calibrated severity contours in blue through red across southern Wisconsin, with a legend for maximum hail size from 0.5 to 2.75 inches.

Radar data people can actually read

The maps render seven severity tiers from pea to baseball, plus a duration overlay showing how long hail fell above each threshold — because sustained hail does more roof damage than a brief pass of larger stones, and no consumer product was showing that.

Sparse-detection zones are flagged separately so a user can tell a real swath from radar noise. That distinction is the difference between a defensible claim and a guess.

The Denver, Colorado hail history page showing summary tiles: last hail event June 26 2026, 207 total hail days since 2014, largest ever 4 inches, and June as the peak month with 68 events.

A content surface generated from the database

229 location pages — 198 cities and 31 state overviews — are rendered directly from the record base and refresh on a schedule. Every figure on them is queried, not written: hail-day counts, largest recorded stone, peak months, per-source freshness.

Nothing is generated prose. If the data changes, the page changes; if the data does not support a number, the page does not print one.

The ExoVzn methodology page, headlined “How we verify severe weather — and what it means for your work”, with a highlighted principle stating that ExoVzn does not advocate for one side of a claim.

Honesty as an architectural constraint

The hardest engineering requirement on this project was not throughput — it was restraint. Radar-estimated hail and ground-confirmed hail are fundamentally different classes of evidence, and the system is built so they can never be conflated.

Every accepted event carries a confidence tier and its sourcing. Events that were considered and rejected are listed too, so a reader can see what the engine looked at and chose not to claim. The published principle is that if a finding cannot be independently audited, it does not get asserted.

Engineering notes

Not one application

ExoVzn runs as several cooperating services rather than a monolith, because the workloads are genuinely different: a user-facing web application, a Python API for the meteorological analysis, an asynchronous worker for report generation, and scheduled data-pipeline jobs. Report generation is queue-backed so a slow or failed job degrades one order rather than the site.

The methodology is the spec

Most projects derive requirements from stakeholder interviews. Here the requirements were three published papers, and the correctness bar was whether a credentialed forensic engineer would sign their name to the output. That changes how you build: confidence scoring, source precedence, and the handling of timezone boundaries across storm dates are all implementations of documented method, not product decisions we were free to make.

Built for AI answers, not just search

The platform ships structured data throughout — including Dataset markup that makes its storm data citable and ScholarlyArticle markup tying findings to the underlying papers — alongside an agent-readable layer of llms.txt, a full content export, and an agent.json capability manifest. Deploys announce changed URLs via IndexNow rather than waiting to be recrawled.

The stack

Web
Next.js (App Router), TypeScript, Tailwind
Analysis services
Python / FastAPI, plus an asynchronous report worker and scheduled pipeline jobs
Data
PostgreSQL via Prisma; NOAA/NWS federal archives, radar-derived products, and observer networks
Infrastructure
AWS — containerised services on ECS Fargate, managed Postgres, object storage, queueing, and scheduled tasks
Commerce
Stripe, with retail checkout plus metered and prepaid partner billing

Where it stands

ExoVzn is live and in active development. The map pipeline runs daily, the location pages refresh themselves, and the platform now carries three product lines — verification reports, professional training, and an expert network — on shared infrastructure.

App0110 Labs designed the platform, builds it, and runs it end to end.

Have a hard data problem?

This one started as three academic papers and a spreadsheet. Tell us what you are working with.

Start a project