Data Platform and Dashboards for a Finance Provider

⚠ This case study is anonymised under a non-disclosure agreement. The client name, logo, and all business figures are not published. What is described below is the engineering scope of the work.

The problem

The daily operational report was assembled by hand every morning from four separate systems: the core system, the CRM, an accounting tool, and one export from an external vendor. The same number was defined differently in each system, so meetings often turned into an argument about which report was right rather than about what to do.

What we built

• Ingestion layer. Scheduled pipelines pulling from all four sources, with retries, partial-load handling, and alerts when a source is unavailable.
• Warehouse and modelling layer. One central schema with metric definitions written as code, so “active customers” has a single definition anyone can read.
• Data quality checks. Tests on every load: key uniqueness, plausible value ranges, and row count reconciliation against the source system. A failing load stops and alerts rather than continuing quietly.
• Operational dashboards. Six views for different teams, all built on the same modelling layer.

Engineering decisions

The hard part was not the pipelines, it was agreeing the metric definitions. We ran a series of short sessions with each system owner until every metric had one written definition, then implemented those definitions as reviewed code rather than as a formula inside a dashboard that anyone could change.

All infrastructure is written in Terraform, so staging is identical to production and either can be rebuilt from nothing.

Handover

The repository, the Terraform configuration, the metric definition catalogue, and the recovery runbook were handed to the client’s data team, along with one recorded knowledge transfer session.