You have the data. Somewhere in your ERP, your CRM, your order system — the numbers are there. What's missing is a clear, reliable view of them. Every Monday someone compiles a report in Excel, and by Tuesday half the figures are already out of date.
The obvious move: add reporting. But which kind? A BI tool like Power BI or Tableau, a self-hosted option like Metabase, or a dashboard built into your own software? The choice affects your costs, your data governance, and how useful the result actually is for the people who need it. Here's how to think through it.
Two types of reporting — and why the distinction matters
Most businesses conflate two things that work very differently in practice.
Analytical BI is for exploration: slicing revenue by region, finding patterns across two years of sales data, building one-off reports for the management meeting. The user wants flexibility — to pivot, filter, drill down. Power BI, Tableau, Looker and Metabase are built for exactly this. They are excellent at it.
Operational dashboards are for monitoring: the production floor supervisor who needs to see today's order count, the support manager checking open tickets right now, the warehouse screen showing what needs picking in the next two hours. These users don't want exploration — they want a specific, reliable view of live data, and they want it fast. A custom dashboard embedded in your software is usually better here than a general BI tool.
The mistake is using an analytical tool to solve an operational problem, or building custom software when a BI tool would do the job in a week. Knowing which category you're in is the most important decision in the whole project.
When standard BI tools are the right answer
Power BI, Metabase, Redash and their peers are genuinely good products. For many Dutch businesses they are the correct and complete solution. Choose them when:
- The primary users are analysts or managers who need to explore data themselves
- Your data lives in standard sources — a database, an ERP with a good reporting API, a data warehouse
- You can tolerate a slight delay (minutes to hours) in data freshness
- Report requirements change frequently — a product manager tweaks filters, a finance director wants a new cut
- You don't have strong opinions about the UI — the BI tool's own look and feel is fine
Power BI licenses run roughly €10 per user per month for Pro, and Metabase's self-hosted version is free. Against a custom build, this is hard to beat for analytical use cases — assuming your data is clean and accessible in the first place.
When custom dashboards make sense
Custom reporting earns its cost in four situations:
Operational screens embedded in your workflow. The warehouse employee doesn't open a separate BI tool — they see live pick counts on the same screen they use for everything else. Embedding live data into your application beats a separate tool that nobody opens.
Data that can't leave your system. Sending patient records, financial transactions or personally identifiable information to an external SaaS BI platform creates an AVG (GDPR) data processing question. If the legal basis is thin or the processing agreement hard to arrange, keeping the data inside your own infrastructure resolves it cleanly.
Specific, non-negotiable design requirements. A client portal where customers see their own usage data needs your branding, your exact fields and your access model — not Power BI's embedded iframes with their own visual language.
Real-time or event-driven requirements. Most BI tools work on scheduled refreshes. If you need a dashboard that updates within seconds — a live operations screen, a logistics overview — you need a custom build backed by a proper data pipeline or websocket layer. That's a different engineering problem than building a weekly report.
What it actually costs
Adding reporting to an existing custom application typically falls into these ranges:
- Simple internal dashboard (5–10 metrics, scheduled refresh): €4,000 – €12,000. A set of charts and KPI tiles pulling from your existing database, no complex aggregation. Often the fastest win.
- Operational monitoring screen (real-time, embedded in the app): €8,000 – €20,000. Requires a real-time data layer — websockets or server-sent events — plus careful UX work so the screen is readable under pressure.
- Customer-facing reporting in a portal: €12,000 – €35,000. Each customer sees only their own data; the access model and performance under multi-tenant load make this more complex than it looks.
- Full data warehouse and BI layer: €25,000 – €80,000+. Building a proper analytical foundation — ETL pipelines, a clean data model, a reporting layer on top — is a significant project. This is the right investment if you have ten or more data sources and need flexible analysis across all of them.
The hidden cost in all of these: data preparation. In almost every project, 40–60% of the time goes not into building charts but into getting the data into a consistent, queryable state. Data spread across three systems in incompatible formats doesn't produce clean dashboards without work. That work has to happen regardless of which tool you choose.
The data foundation problem
This is where most reporting projects stall. You want a dashboard showing revenue by product line — but revenue lives in the ERP, product metadata is in a spreadsheet someone maintains manually, and returns are in a different system with a different product code scheme. The dashboard you need can't be built until those three sources are reconciled.
A clean data architecture matters here. If your operational software was built with reporting in mind — consistent identifiers across systems, a read replica database, well-designed tables — adding reporting is straightforward. If it was built as a collection of disconnected tools, the first step is data integration, not dashboard building. A proper custom build accounts for this from the start.
EU data residency: a practical concern
Several popular BI tools default to US data centres. Sending business data there for processing requires a legal basis under the AVG — usually Standard Contractual Clauses, which add administrative overhead and carry legal uncertainty. EU-hosted options exist for most major platforms, but you have to explicitly choose and configure them. Self-hosted options like Metabase on an EU server sidestep the problem entirely.
For businesses handling sensitive financial or client data, this is worth resolving before choosing a tool rather than discovering it after the first security audit.
Five questions to answer before you start
- Who are the users, and what decisions do they make? A warehouse supervisor and a CFO need fundamentally different things. Building one dashboard for both is how you end up with something nobody uses.
- Where does the data live, and is it consistent? Name your three most important metrics and trace each one to a specific table or field in a specific system. If you can't, the data foundation is the project, not the dashboard.
- How fresh does the data need to be? Daily is simple. Hourly is manageable. Seconds is a different engineering problem with a different price tag.
- Can this data go to an external service? Check your data classification before evaluating SaaS tools. Some data simply should not leave your own infrastructure.
- Does this need to be in your software, or can it be a separate tool? Separate tools are faster to deploy and easier to change. Embedded is better for adoption and access control. Neither is always right.
The honest summary
For analytical reporting where your data is already accessible and clean, a BI tool is almost always faster and cheaper than building custom. For operational screens, customer-facing portals, real-time monitoring or data that can't leave your infrastructure, custom is the better investment.
The more common situation: a hybrid. A clean operational system that owns the data, plus a BI tool sitting on top of it for the analysts who need to explore. That combination costs more upfront than one tool alone, but it gives each group exactly what they need rather than asking everyone to compromise.
If you want an honest read on which approach fits your situation — what your data would need to look like, what it would cost to get there, and whether a standard tool is enough — describe what you're trying to measure and I'll give you a direct answer.