Skip to content
Let's talk

Case study · in progress

SonarMap

Three pieces being built at once: an iOS and Android app, the server that feeds it data and the website that presents it. The website is live; the app and the server are still being built. There are no results to report yet, so this case study explains what each piece is and where it stands.

What it is

An app that shows what's happening in the places each user picks and in the rest of the world and alerts them when something happens there. Every data point says which agency published it, at what time and with which link. From the data it archives, it also works out what the source doesn't say: whether today is normal for that place, how long it usually lasts and how often it comes back. It isn't a headline aggregator.

What's being built

All three pieces at once: the server that collects and sorts the data, the iOS and Android app, and the marketing site. There's a fourth that isn't for sale: the internal dashboard used to run everything else.

Status

The website is live; the app is being built. The server is already archiving data from more than ninety public sources, and the app can be navigated end to end. It isn't in the stores yet and there's no published launch date.

Visit the site

How it fits together

From the agency that publishes the data to the phone.

Between the source and the app sits a server that makes three decisions about every data point: whether it's a fact or noise, which place on the map it belongs to, and which users need an alert. That's the biggest part of the project. The app is the part you see and the smallest.

The app can only show what the server has sorted first. The biggest job is the server's and it's the one you don't see.

Where it stands

The three pieces, one by one.

They're built at the same time because they depend on each other. Each one is at a different stage, and this section says which.

  • 8languages, in the app and on the site
  • +90public sources, each with its license
  • 3areas in the app: nature, transport and health
  • 2platforms, iOS and Android from the same code
  • The server It collects data from the sources, archives it without duplicates and assigns every event to its municipality. It's built with Java and Spring Boot on PostgreSQL with a geospatial extension. Database changes are versioned and the tests run against a real database.
  • The app Built with Expo and React Native: the same code for iOS and Android, in eight languages. It has three areas (nature, transport and health), and each one shows the places the user has saved: the map, active alerts with their level and source, public traffic cameras where there are any, and the history of every figure. There are also two general views. World shows the active events around the planet. Pulse compares what's happening on the planet with what's usual (earthquakes, the sun, the seasons) and has no alerts. Alert delivery is coded on the server and in the app; it still has to be tested on real phones.
  • The marketing site It's static and live in the same eight languages as the app. It shows the source catalog, generated from the same data the system uses, with each source's license verbatim. It also shows the plans and the editorial rules. The download reads "coming soon" until the app is in the stores. The site still describes the previous six areas: it will be rewritten once the app is final, so the work isn't done twice.

The app today

Four screens from the app.

World, an earthquake with its affected municipalities, Transport and Pulse. These are real screenshots, with the data from the day they were taken and every figure with its source and time. The app is shown in Spanish.

SonarMap app screenshot: the globe with active events worldwide and, below it, the card for an aviation volcanic ash alert in Indonesia The same World screen in dark mode, with the globe and the active events World
SonarMap app screenshot: the card for an earthquake in Mexico, level 2 of 5 according to EMSC, with its date, the 25 affected municipalities, magnitude 4, depth 10 km and the map of the epicentre The Mexico earthquake card in dark mode, with the level, magnitude, depth and the epicentre map An earthquake
SonarMap app screenshot: the lower part of the earthquake card, with the affected zone of 80 km, what an earthquake is and the list of affected municipalities: San Pedro Huamelula, Santiago Astata, Santo Domingo Tehuantepec and others The list of municipalities affected by the earthquake in dark mode, with San Pedro Huamelula, Santiago Astata and Santo Domingo Tehuantepec Affected municipalities
SonarMap app screenshot: the Barcelona area under Transport, with live traffic on the map, fifteen alerts, forty-six cameras, the fuel price and the list of cut train lines. The row of saved zones sits at the top The Barcelona area under Transport, in dark mode, with live traffic and its train alerts Transport
SonarMap app screenshot: the week's earthquakes of magnitude 4.5 or higher, 77 against 111 to 190 in a typical week, with the world map, the largest ones and a day-by-day chart by energy released The same week of earthquakes in dark mode, with the world map and the day-by-day chart Pulse

What changed along the way

Two changes of course and what each one cost.

Neither was in the plan. Both were decided with the product already built, which is when change costs the most. That's why they're here, each with its cost.

  • From six areas to three The app had six areas and was cut to three. The decision came from counting what had actually been published: the twenty conflict events worldwide were all below the alert threshold, and more than a third of the series catalog was economics, an area without a single event. The cost: thirty-seven sources were switched off, and their screens, icons and color rules were removed. Nothing was deleted: the archive is still stored and each source can be switched back on by changing one line, so the decision can be undone.
  • A visual redesign that left the structure alone The whole look of the app changed: a cream background by day and gray by night, the system font instead of bundled typefaces, fixed-width figures and a custom icon set. It was cheap because the rule was written down before starting: the look changes and the elements stay. Every screen keeps the same pieces in the same order, and color is reserved for the severity scale. If a screen gained or lost an element in the change, it had been done wrong. With that rule, the redesign took two phases of well-bounded work and nothing had to be rewritten.

Starting decisions

Three decisions made before writing code.

They were written down before the first line of code, because changing them later means a rewrite. They're the ones that have shaped the rest of the work the most.

  • Every data point shows its source Every data point says which agency published it, the time and the link. A category isn't shown until there's a source behind it with authority on the subject. It's slower to build, but without that rule this would be a news aggregator.
  • Machine learning models trained on the archive itself Anomaly detection models are trained on the archived data. They detect whether what just happened is out of the ordinary for that place, or whether a source has started sending odd data. They're interpretable models: every result shows where it comes from and can be recomputed. It's data science; no language model summarizes text here.
  • Worldwide coverage from day one It didn't start with one country to expand later. That calls for a catalog of places covering the whole planet and for fast matching of every event to its place from the start, instead of running into the problem when moving into other countries.

Got a product to build?

What was learned building these three pieces at once applies to yours. Half an hour to see which pieces it needs, in what order and where the price starts.

Tell us about your project