Do we need a full data warehouse for this?

Usually not at the start. We begin with a data layer alongside the source systems: read access, fixed reporting logic, one place for the figures. Whether that grows into a full warehouse is a decision for the second stage — not for the first invoice.

What happens to our existing spreadsheets?

They are the best starting point there is: they hold the logic that actually applies in the business, special cases included. We read them, move the rules into queries and replace the manual part. The number stays the same — the copying goes away.

How current are the figures?

As current as the source systems allow. A nightly run is typical, so the comparison is ready in the morning. Where it matters we go more often. Where it changes nothing we deliberately keep it nightly rather than generating constant load for a feeling of real time.

What if a number looks wrong?

Then it has to be traceable. Every figure has a documented path back to the source table. A dashboard whose numbers nobody can explain stops being opened after three weeks — that is the most common way BI projects quietly die.

03 · Data

Your figures in one place, current every morning

In most businesses the figures already exist — just in five places at once and in three versions. The monthly report is then assembled by hand, and the meeting is spent deciding which number is correct rather than what to do about it. The problem is rarely missing software. It is a missing shared model.

Data from ERP, shop, time tracking and bank brought into one model — with dashboards that are already right first thing in the morning, and figures nobody argues about in the meeting.

›Data hub: ETL pipelines from ERP, inventory, shop and bank
›Dashboards and KPI cockpits with Metabase
›SQL Server and PostgreSQL: modelling, queries, tuning
›Replacing discontinued reporting servers without changing licences

MetabaseSQL ServerPostgreSQLETLGristEBICS

Who this fits

Businesses where management needs figures from more than one system, and where someone currently copies spreadsheets together to produce them. If your ERP ships reporting that is good enough, we will say so — you do not need us for that.

What we run ourselves

The reporting for a group of nine companies runs on exactly this setup — including the awkward parts: group-level views, prior-year comparison and bank data.

Controlling cockpit: Figures from the ERP with prior-year comparison, per-company and group-level views. Replaces a report that was built by hand every month.
Lost customers: A report that flags when a customer's ordering pattern breaks off — before it shows up in the annual comparison, by which point it is too late.
Bank data automatically: Statements are collected via EBICS and fed into the liquidity view, instead of being exported and pasted in every month.
Replacing a reporting server: A discontinued reporting service was replaced by our own interface on the same data — without licence costs and without a migration project.
Spreadsheet replacement: A grown spreadsheet with well over a thousand rows now runs as a database with several people editing at once — no version conflicts, no file doing the rounds.

How a project runs

We do not build the complete model and unveil it six months later. We take the one figure that matters most and make that one trustworthy.

1The first figure
Which number is missed most, and who makes which decision with it? That determines which sources get connected first.
1 meeting
2Connect and read
Read access to the source systems, the first ETL pipeline, a model with traceable origins. Still without any polish on the surface.
1–3 weeks
3Dashboard and reconciliation
The report is checked against the previous manual calculation. The discrepancies are the real work here — and the reason anyone trusts the figures later.
1–2 weeks
4Extend
More sources, more views, per-role access, a nightly run with monitoring. Every stage is usable on its own, even if it stops there.
ongoing

What it costs

Billed per stage. The first one is deliberately small: it exists to prove the figures are right before more money goes in.

What drives the price: The number of source systems and how accessible they are. A documented database is cheap; a system that only hands out its data as a finished report costs detours.
What lowers the price: One person allowed to define the business logic with authority. The most expensive reports are the ones where three departments define the same figure differently.
Running costs: Metabase, PostgreSQL and the ETL pipelines are open source and run on your own hardware — no cost per report recipient. That is precisely where reporting usually fails: it never gets distributed, because every extra seat costs money.

What you get

✓A data model that brings more than one source system together
✓Reports with a traceable path back to the source table
✓Nightly runs with monitoring instead of hand-built reports
✓Per-role access, with no cost per recipient
✓Queries and scripts in your own repository, not locked inside a tool

Frequent questions

Do we need a full data warehouse for this?: Usually not at the start. We begin with a data layer alongside the source systems: read access, fixed reporting logic, one place for the figures. Whether that grows into a full warehouse is a decision for the second stage — not for the first invoice.
What happens to our existing spreadsheets?: They are the best starting point there is: they hold the logic that actually applies in the business, special cases included. We read them, move the rules into queries and replace the manual part. The number stays the same — the copying goes away.
How current are the figures?: As current as the source systems allow. A nightly run is typical, so the comparison is ready in the morning. Where it matters we go more often. Where it changes nothing we deliberately keep it nightly rather than generating constant load for a feeling of real time.
What if a number looks wrong?: Then it has to be traceable. Every figure has a documented path back to the source table. A dashboard whose numbers nobody can explain stops being opened after three weeks — that is the most common way BI projects quietly die.

Let's talk. Services