REF Reference · case study

⚠ This is only a preview (not available in production).
Draft

Meteopress Radar Kit

A radar for people who understand radars

Frontend development
Project facts
Client
Meteopress
Platforms
Web, 2D and 3D radar visualisation
Cooperation
Frontend ownership, two-week sprints
Since
2024

01 Tech stack · under the hood

SvelteFE frameworkTypeScriptLanguageNxBuild toolsPlaywrightE2E testingStorybookUI workshop

02 Case study · the story

Meteopress is a Czech meteorology company. Besides forecasts for the public, it builds software for professionals. One of its key products is Radar Kit, a web application for experienced meteorologists who need more than a coloured blob of rain on a map. Meteopress deploys it to customers on several continents, from Europe through Africa, Asia and Oceania to the Americas, and ranks it among the most advanced applications of its kind on the market.

In Radar Kit, a meteorologist picks a radar source and a product, such as base reflectivity (DBZH) or differential reflectivity (ZDR). They then set the beam elevation or the altitude and step through a timeline of the last few minutes. Several panes with different products can sit side by side. The map tilts into 3D, where the data takes the real shape of the radar measurement: the cones of beams the radar sent out at different angles.

Radar Kit with two radar panes side by side and a vertical cut through the radar data along a line across the map
Radar Kit with two radar panes side by side and a vertical cut through the radar data along a line across the map

An important product that grew fast

When FlowUp joined the project in July 2024, Radar Kit already had paying customers and was strategically important to Meteopress. The application had been built by another vendor and partly by Meteopress itself. Its team, however, focuses mainly on Python and radar data, and needed reinforcement for the long-term development of a frontend in the JavaScript ecosystem.

The application grew quickly to keep up with the needs of specific customers, and shipping new features came first. With more customers and more features, though, development needed a firmer footing: automated checks, tests and shared rules. On top of that, the application stands on a demanding combination of technologies: Svelte, WebGL, MapLibre GL for the map and Three.js for the 3D scene.

Who does what

FlowUp owns the frontend development and maintenance on the project. Meteopress runs the Python radar API that supplies the data. Meteopress also sets the product vision and develops experimental features of its own, which FlowUp code-reviews on request.

About 2.5 FlowUp developers work on the project at a steady monthly capacity. Development runs in two-week sprints that end with a demo for Meteopress. This is not the first collaboration between the two companies, so the shared code also serves other applications FlowUp builds or maintains for Meteopress.

Solid foundations, step by step

The main task was not just adding features. The application had to be gradually transformed so it could be developed safely for the long term, all while in full operation, without pausing deliveries to Meteopress's customers.

  • Monorepo and shared code. We moved Radar Kit into a monorepo on a pnpm workspace extended with Nx, with unified tooling for all applications and libraries. We extracted the simple map into a shared library, so other Meteopress applications use the same implementation.

  • Dependency security. We used the move from npm to pnpm to set up protections against supply chain attacks.

  • Current technology. We update the framework and the dependencies regularly, so the application does not age or hide security risks.

  • Stricter code. We introduced strict type checking, linting and further static analysis, and refactored the code to a higher standard.

  • Mandatory pull requests. Every change goes through CI on GitHub Actions, code review and a manual test.

  • Tests that see the canvas. Radar Kit's output is mostly visual, so classic tests are not enough. E2E tests in Playwright cover the critical scenarios with screenshot tests against a mocked radar API with deterministic data, so a rendering regression is caught in the pull request.

  • UI kit and Storybook. We are gradually consolidating recurring visual elements into a component library built on Tailwind and Ark UI. Every Storybook story doubles as a component test, accessibility check included.

  • Documentation. We documented the whole codebase, including a domain glossary, so a new developer and an AI agent alike can find their way around it easily.

Today every change goes through a pull request, automated checks and review. Any bug goes back to its author before it is deployed.

Cuts through the radar volume

Among the most demanding features are the vertical and horizontal cuts we added to the 3D visualisation. A radar does not measure in horizontal layers but in cones of beams that climb with distance. For a meteorologist to see a storm in a cut between two points or at a constant altitude, the application has to recompute and interpolate the data from several cones. For the horizontal cut it offers several algorithms, which differ in how they handle places where data above or below is missing.

On screen it looks impressive, but there is a lot of R&D behind the result. Our developer studied the scientific literature and step by step turned the meteorologists' idea into algorithms, an idea that itself evolved during development. They then tuned and optimised the algorithms for smooth rendering in the browser. Truly understanding the use cases means thinking like a meteorologist, so patient communication and iteration were key. Many of the extensions could also be delivered cleanly only thanks to preparatory refactoring, which was possible precisely because the code already had tests and clear rules.

How we work together

So that Meteopress can focus on meteorology and its customers, FlowUp has also taken on the role of technical product owner. We turn Meteopress's requests into user stories a developer can pick up straight away. Technical tasks such as refactoring, tests or tooling we mostly propose ourselves, and Meteopress approves them. Development thus largely runs itself, and at the end of every sprint Meteopress sees the finished work at the demo.

Process does not mean rigidity, though. When Meteopress is preparing a new deal or a critical bug turns up at a customer, we can reshuffle priorities flexibly. The established rules do not slow us down: thanks to tests and review, we can ship a quick fix confident that it breaks nothing else. In the long run, the process saves us time rather than costing it.

What changed

Today we take continuous care of Radar Kit's quality. We keep reducing technical debt and test the application systematically. When Meteopress needs a feature for an upcoming deal, we can prioritise it and fix the bugs we find quickly.

The project is easy to join. The process and the information are transparent and traceable, and test states can be set up deterministically. That lets both FlowUp and Meteopress delegate parts of the development to AI agents, even though the application is mostly visual.

For Meteopress, FlowUp is a reliable technical partner: one that holds the quality, reviews Meteopress's own experiments and step by step moves Radar Kit toward a product ready for long-term growth.

Quote

Placeholder: Jakub Bartel's quote about the collaboration, pending from Meteopress.

Jakub Bartel
Jakub BartelHead of SW and AI Development | Meteopress

03 Product · screens

MeteopressWeb, 2D and 3D radar visualisation
Radar Kit with two radar panes and a vertical cut

04 Continue · more work

Back to all references