Matthias Mesotten

A personal build to answer the question I kept running into: how much of my return is actually being paid for by risk, and where is that risk coming from?

Risk decomposition. Portfolio volatility broken down per position via Euler risk contribution, alongside beta, 1-day VaR/CVaR in euros, the correlation matrix, a diversification ratio, concentration and currency exposure. Positions held through funds are looked through to their underlying sector weights, so exposure is measured on what you actually own rather than on the wrapper.

Scenario and sensitivity modelling. Hypothetical market, rate, currency and sector shocks applied to current weights — market moves through each position’s own estimated beta, rate sensitivity fitted empirically against the US 10-year (FRED), sector shocks ceteris paribus via each holding’s beta to its sector ETF. Plus historical stress tests replaying 2008, COVID and 2022.

Factor screening and ranking. Quant factor and fundamental models rank a universe of ~13,600 listed equities and ETFs, with hierarchical risk parity (HRP) available for allocation. Candidates carry through to deeper single-name analysis and a like-for-like comparison against sector and regional peers.

Performance measurement. A FIFO transaction ledger is the source of truth, from which true time-weighted return is computed and benchmarked against the S&P 500 in EUR — separating what the portfolio earned from what contributions merely added. Sharpe and Sortino are shown against a live risk-free rate.

ESG (Sustainalytics ratings, SFDR article 6/8/9) is carried as a deliberately informative-only layer: visible on every report, never folded into a score.

Stack: Python for the analytics; FRED and market-data feeds; a local web app for the workflow.

House hunting around Antwerp taught me that it is easy to see what is on the market today, and almost impossible to see what any particular house has done over time. So this keeps a running record and does the analysis on top of it.

Same-property matching. The same house reappears over the years under different descriptions, agencies and asking prices. Records are normalised and matched so that one house is one row — which is what makes a history meaningful rather than double-counted.

The history a snapshot can’t show. Because nothing is discarded, it can answer questions a single moment in time can’t: how many separate times a property has been on the market, what it asked on each attempt, and how long it has been sitting — both now and in total. A house on its fourth attempt at a falling price is a very different proposition from a fresh one.

Cost of ownership, not asking price. Each entry carries the real cost of buying — registration duty, notary fees, VAT, disbursements — plus the cost of keeping it: annual heating in kWh and euros derived from the EPC label, rolled into a ten-year figure. Two houses at the same asking price are rarely the same purchase.

Valuation and screening. A comparables-based estimate and an indicative renovation cost sit alongside €/m², EPC label and build year. Saved preference profiles are matched against anything new, with a message the moment something fits — and a dashboard with list and map views for exploring the whole dataset.

Stack: TypeScript across a Node service and web front end, with a local store for the time series.

The project where my day job (data & AI) meets my sport (triathlon). It syncs data from Garmin Connect, Apple Health and Strava, tracks recovery (HRV, resting HR, sleep), and every morning regenerates a training plan that adapts to how you actually slept, recovered, trained and lived — while always steering toward the races you’ve put on the calendar.

The one-paragraph pitch: TrainingPeaks tells you what your coach planned weeks ago; intervals.icu has brilliant analytics but doesn’t plan for you; Garmin’s suggestions adapt but ignore your race calendar and life constraints. This app closes the loop — plan ↔ execution ↔ recovery ↔ replan, every morning, on your own machine, with your own data, for triathlon specifically (swim + bike + run + strength as one interacting system).

It also handles structured workouts and fuelling, FIT export, a compliance tracker, health/sport dashboards from Garmin effort curves, an injury/niggle log with a staged return-to-training, and pre-race briefings with carbohydrate guidance. Stack: local FastAPI + SQLite, Python analytics, JS/HTML front end.

A hot day, no bottle, and no easy way to tell whether the nearest option is a free tap, a vending machine, or a shop that closes at noon on a Sunday. So this combines four things no single map puts together: free drinking water, drink vending machines, shops, and the fuel stations that actually have one — pulled from OpenStreetMap and kept current automatically.

Open now, not just nearby. Every shop and machine is evaluated against its real opening hours — including Sundays and Belgian public holidays — so the map answers “is this actually open right now,” not just “is there a dot here.”

A heuristic worth being proud of. Only about 1% of fuel stations in OpenStreetMap are tagged with whether they have a shop. Rather than showing thousands of unreliable pins, a station only appears if it has an explicit shop tag, or has posted opening hours and isn’t flagged as unmanned or a self-service sub-brand — cutting ~3,000 raw fuel points down to the ~320 that plausibly sell a drink, with a report button for anything wrong.

Community input that upgrades the real map. Anyone can suggest a new spot or report a problem; submissions stay an unverified pin until reviewed. Approving one is one click to open OpenStreetMap’s own editor at that exact location — so a verified addition goes upstream into OpenStreetMap itself, where every map built on that data benefits, not just this one.

Built to stay current with no server to babysit. The whole map is one self-contained static page with ~9,500 points embedded and clustered for performance; a small Python script refreshes it from OpenStreetMap’s Overpass API every day via GitHub Actions, no manual maintenance required.

Stack: Leaflet for the map, Cloudflare Pages Functions and D1 for community suggestions, Python for the daily data refresh.