Dashboards that tell you what you did not know

Yes, and that is often where we start. A dashboard built on dirty data produces nice charts that mean nothing, or worse: numbers that contradict each other. We start with a data-quality audit: which sources do you have, which fields are reliable, where are the duplicates, empty records, broken formats, outdated definitions. Then we set up a lightweight modelling layer (usually with dbt) where the logic lives once: what is an active customer, how do we count revenue, which records belong to which campaign. Only on top of that clean layer do we build dashboards and AI analysis. It sounds like a detour but is cheaper than building twice on data you cannot trust. We are honest: sometimes this groundwork is bigger than the dashboard itself, and we will say so.

We work with BigQuery, Postgres, or DuckDB as the warehouse, dbt for modelling, Fivetran or Airbyte for connectors (or custom scripts when that is cheaper), and Looker Studio, Metabase, or Hex for dashboards. For AI analysis we use Claude or GPT via API. This is deliberately an open stack: your SQL models run on any warehouse, dbt is open source, dashboards can be moved to a tool you can manage yourself. We always deliver documentation and code in your repository, not in a platform that locks you in. If you switch vendor later or want to take it over, you can. No black box.

Customer segmentation and behaviour analysis fall under GDPR the moment you process personal data, even if it is only an email address or customer ID. Important: the legal basis must be clear. For analysis on your own customer data this is usually legitimate interest or contract performance, provided you can justify it and the impact on the customer is limited. We help make that assessment and document it. For heavier profiling with automated decision-making, stricter rules apply (Article 22 GDPR). Practical measures we set up by default: pseudonymisation where possible, retention periods on datasets, no customer data sent to external AI vendors without a DPA, and a processing register update so you can defend it in an audit. For edge cases: the AI Quickscan first checks what data you may use at /ai-strategie.

Self-maintenance is the starting point. We build dashboards in tools you can open, adjust, and share without us, like Looker Studio (free, Google account) or Metabase (open source, your own server). The SQL models underneath sit in dbt and are version-controlled in your GitHub or GitLab, so any colleague with SQL knowledge can read and edit them. We document every metric: what counts, what does not, and why. If you have or hire an internal data person, they can take over. We are happy to stay involved for heavier AI analysis and new sources, but that is a choice, not a dependency.

A data warehouse is structured storage for clean, modelled data, typically SQL tables that dashboards and reports run on. Examples: BigQuery, Snowflake, Postgres, DuckDB. A data lake is rawer storage, often on cheap object storage (S3, GCS), where data lands in its original form before being modelled. For most SMBs, a data warehouse is enough. A data lake (or "datalake") only becomes useful at high volumes of unstructured data, like log files, images, or sensor data you might want to use later. We almost always recommend starting with a simple warehouse (BigQuery is cheap until you genuinely need more) and only expanding to a lake architecture when the use cases justify it. Data warehousing principles apply either way: clean modelling, traceable definitions, tested pipelines.

Yes. We often work with Looker Studio, Metabase, or Hex because it is faster and cheaper for SMBs, but if you already invest in Power BI or Tableau we just build on top of that. The warehouse and dbt models work the same, only the visualisation layer differs. What we often see: the dashboard work in Power BI is fine, but the data underneath is a tangle of Excel exports and manual steps. That is where the value is, not in the visualisation. We then tackle the pipeline and keep Power BI as the presentation layer. Same for Tableau, Qlik, or Pyramid.

Yes, and that is often where most value sits. If your data is already clean in a warehouse, we can build on top: anomaly detection (which transactions deviate from the pattern), customer segmentation by behaviour (clustering with machine learning), forecasts (cashflow, inventory, churn), sentiment analysis on reviews or support tickets, and natural-language interfaces ("ask your data how many orders we had last month from Brabant"). We connect to your existing tables, do not add new systems unless we have to, and return output to dashboards you already know or in automated reports to email or Slack.

Three checks we build in by default. One: every number in a dashboard has a definition and a traceable query. You can always drill down to the underlying rows to verify. Two: dbt has tests (uniqueness, not-null, referential integrity, business rules) that run on every refresh. If the data deviates we get an alert before you see it in the dashboard. Three: for AI analysis (forecasts, segmentations) we run a back-test on historical data and show how well the output matches what actually happened. No blind trust in a model. If the back-test is poor, we say so. A good dashboard tells you something you did not know, but it has to be correct.