How I Built Portugal
Data Intelligence

Portugal's economic data is everywhere and nowhere

If you want to understand how the Portuguese economy moved through the sovereign debt crisis, COVID, and the rebound, the data exists, but it's scattered across several national and European statistical authorities, each with its own portal, format, cadence, and quirks. INE publishes one thing, Banco de Portugal another, Eurostat and the ECB two more. There's no single place that consolidates them, lines them up on a common timeline, and lets you ask cross-cutting questions like "how did unemployment and sovereign bond yields actually move together?"

That was the surface problem. The real reason I built it was to push my own depth, to take a project from raw API responses all the way to a boardroom-ready briefing, owning every layer in between, instead of inheriting a clean dataset and only doing the last mile.

The first decision: what's real, and what's modelled

Twelve pillars across fifteen years is a lot of surface area, and not all of it is available through a clean open API. The most important early decision wasn't technical. It was about honesty. I split the data into two tiers and made the split explicit everywhere it matters.

It would have been easy to present all twelve pillars as if they carried equal authority. I didn't, because the moment someone discovers one modelled number presented as gospel, they stop trusting all of them. The committed dataset is deterministic and reproducible from a snapshot, so anyone can rebuild it and get the same result, and the data-provenance documentation spells out exactly which pillars are which.

A three-stage pipeline, every layer owned

The system is a single command (python main.py) that runs three stages end to end. Keeping them cleanly separated (extract, analyse, deliver) meant I could rebuild any one layer without touching the others, and test each in isolation.

The unglamorous truth of data work is that the middle layer is the easy part to show off and the hard part to trust. So I spent most of my effort on the two ends nobody photographs: the quality gate going in, and the "so what" going out.

The boring layer that decides everything

A single wrong number in a macro dashboard isn't a cosmetic bug. It's the kind of thing that makes a reader quietly discount the entire report. So before any series reaches the analytics layer, it passes an eight-check validation framework. Every pillar, every load, every time.

Each run writes a JSON quality report and a lineage record (a UUID run_id, file checksums, provenance metadata) so if a number looks wrong I can trace it backwards through the layers to the exact batch and source that produced it. That traceability is the difference between "I think the data's fine" and "I can prove where this came from."

Beyond charts: what the analytics layer actually does

This is where a financial analyst's instinct met a deeper statistical toolkit. The goal was never to forecast Portuguese GDP better than the central bank. It was to demonstrate the methods properly, with honest validation rather than a confident line drawn into the future.

The honest framing throughout: where a method is genuinely robust on this data, I lean on it; where the modelled pillars make it illustrative, I say so. A forecasting chart that hides its own error metrics is marketing, not analysis.

From "here's the data" to "here's what it means"

The single biggest thing that separates this project from a tidy set of charts is the final layer. A dashboard makes a reader do the interpretation. An advisory deliverable does the interpretation for them, and stakes a position. The platform generates a self-contained HTML briefing that ends not with a chart but with a risk matrix and strategic recommendations.

Keeping the report deterministic was a deliberate product decision, not a limitation. For something presented as economic analysis, a number that changes every time you regenerate the page is worse than useless. It's a trust hole. The LLM accelerates the prose; it never decides the figures.

Why a portfolio project has 489 tests

It would be reasonable to ask why a solo analytics project needs a real test suite, containers, and CI. The answer is that the engineering discipline is part of what the project is meant to demonstrate, that I can build data work the way a team would actually have to maintain it.

What worked, and what I'd change

The project did what I built it for: it took me through every layer of a data platform, from a raw API response to a recommendation a reader could act on. A few honest reflections: