BI & Dashboards
Dashboards your business actually uses — live, fast and readable without a data analyst in the room.
A dashboard that requires a data analyst to interpret it is not a dashboard — it is a report. We design and build BI views that surface the right metric to the right stakeholder at a glance, load in under three seconds, and stay current without anyone running an export. The difference between a dashboard that gets used and one that gets ignored is almost always whether it answers the specific question someone has on a Monday morning.
We build on the tools your team already has or can operate: Power BI, Tableau, Looker and Looker Studio for standard BI environments, Metabase or Superset for open-source stacks, and custom embedded analytics inside your own product using a charting library wired directly to your data warehouse. Every dashboard sits on a clean, documented data model so numbers are consistent across every view.
What this covers
Stakeholder interviews to map the actual decisions the dashboard is meant to support
Metric definitions and KPI framework agreed in writing before design begins
Dashboard design: layout, chart selection, filter hierarchy and mobile-responsive views
BI tool implementation in Power BI, Tableau, Looker, Looker Studio, Metabase or Superset
Embedded analytics inside your own web app using Recharts, Observable Plot or similar
Row-level security and role-based access so every user sees only what they should
Scheduled email reports and alert subscriptions for threshold-based notifications
Deliverables
- Live dashboards on your preferred BI tool, accessible via link or embedded in your product
- A documented metrics glossary so every number has a clear, agreed definition
- Underlying data model or semantic layer owned and operable by your team
- A short training session or recorded walkthrough for the stakeholders who will use it daily
What we build with
Business intelligence & embedded analytics
Business intelligence is the practice of surfacing data-driven answers to business questions at the moment and in the form a decision-maker needs them. The scope includes the semantic layer (where metrics are defined), the BI tool or embedded charting layer (where they are visualised), and the access model (who can see which subset of data). BI ends at the decision — not at the chart. A dashboard that requires an analyst to interpret it before it can be acted on is a report, not BI.
The most common failure in BI work is building dashboards before agreeing on metric definitions. When 'monthly active users' is defined differently in the product team's Tableau workbook, the finance team's Power BI report, and the CEO's Looker dashboard, every stakeholder meeting becomes a reconciliation exercise. The semantic layer — whether implemented as LookML, dbt MetricFlow, or a Cube.js schema — is the engineering solution to this problem: metric definitions written once in version-controlled code, queried consistently by every downstream consumer.
BI engineering principles
These principles apply regardless of which BI tool is in use. A dashboard built against them is one that stays accurate, gets used, and can be maintained by someone who did not build it.
Define metrics before designing charts
A chart is a visualisation of a metric. If the metric does not have an agreed definition — including the filter conditions, the time-grain, the denominator for rates, and the handling of NULLs — the chart will mean different things to different viewers. Every BI engagement should start with a written metrics glossary agreed by the business owner before a single dashboard is laid out. The glossary entry for 'churn rate' should specify: the cohort definition, the observation window, whether it is customer-level or revenue-weighted, and the system of record.
BI tools should query certified models, not raw tables
A direct connection from a BI tool to a raw or staging table is a signal that the transformation layer is incomplete. When analysts pull raw tables into Tableau or write custom SQL in Power BI Desktop against an unnormalised source, the business logic ends up inside the BI file — untested, unversioned, and invisible to the data team. BI tools should connect to mart tables or semantic-layer endpoints that have passed dbt tests; the BI tool's job is layout and interaction, not transformation.
Row-level security belongs in the warehouse, not the tool
Implementing row-level security (RLS) only inside a BI tool means that anyone who bypasses the tool — a direct warehouse query, a data export, an API call — sees data they should not. RLS should be enforced at the warehouse or semantic layer level (BigQuery row-access policies, Snowflake row-access policies, Cube.js security context) and then mirrored in the BI tool for the user-facing filtering experience. The warehouse is the authoritative enforcement point.
Extract mode vs live connection: choose deliberately
An extract (imported dataset in Power BI, extract in Tableau) copies data into the BI tool's in-memory engine at refresh time. A live connection queries the warehouse at report-open time. Extracts deliver fast dashboard load times and allow calculated columns that the warehouse cannot compute at query time, but they introduce a freshness lag equal to the refresh schedule and consume BI tool storage. Live connections guarantee up-to-the-minute data but place load on the warehouse at every page view. The right choice depends on the dashboard's freshness SLA and the warehouse's concurrency headroom — not on which mode is easier to set up.
Cardinality determines filter performance
Dropdown filters backed by high-cardinality columns (customer_id, order_id, email address) will be slow in every BI tool. Filters should be backed by low-to-medium cardinality dimensions: region, product category, sales rep, plan tier. When a user genuinely needs to filter by a high-cardinality field, a search-as-you-type input that fires a parameterised query is more performant than a materialised dropdown list. Understanding cardinality before designing the filter bar prevents a dashboard that is unusable in production because the filter takes 30 seconds to populate.
A dashboard not used in 90 days is a liability, not an asset
BI sprawl — dozens of dashboards with overlapping metrics, inconsistent definitions, and no clear owners — is the most common reason organisations lose trust in their data platform. Every certified dashboard should have a named owner, a documented purpose, and a review date. BI tool usage analytics (available natively in Looker, Power BI, and Tableau) expose which dashboards are accessed, by whom, and how recently. Dashboards unused for 90 days should be archived or deleted, not retained on the assumption that someone might need them.
How we'd choose
There's rarely one right answer — these are the trade-offs we weigh before recommending an approach.
Power BI vs Tableau vs Looker vs Metabase
No single BI tool is universally correct. The right choice depends on your organisation's cloud commitments, the technical fluency of your primary users, your semantic-layer strategy, and whether you need embedded analytics. The rows below cover the criteria that most often determine which tool fits.
| Criterion | Power BI | Tableau | Looker | Metabase |
|---|---|---|---|---|
| Primary authoring persona | Business analysts comfortable with Excel and DAX; data teams on Microsoft stack | Analytical users who want drag-and-drop exploration without writing SQL | Data teams willing to write and maintain LookML; organisations that want BI and semantic layer unified in one system | Engineers and product teams who want self-serve SQL and simple chart building without a steep learning curve |
| Semantic / metric layer | DAX measures in the data model act as a weak semantic layer; metric definitions live inside Power BI Desktop files, making them hard to version-control or reuse outside the tool | Published data sources provide some centralisation but lack version control and test coverage; metric logic is easily duplicated across workbooks | LookML is the semantic layer — every metric, dimension, and join is defined once in version-controlled files; Looker generates SQL at query time from those definitions, guaranteeing definitional consistency | No built-in semantic layer; connects directly to the warehouse or to dbt-defined mart tables; works best when the semantic layer is owned by dbt MetricFlow or Cube upstream |
| Row-level security model | RLS defined in the Power BI data model using DAX filter expressions; integrates with Azure AD groups for dynamic access; enforced only within Power BI — does not protect direct warehouse access | Row-level security via user filters on published data sources; enforced only within Tableau Server / Cloud — bypass is possible via direct warehouse connection | RLS defined in LookML access filters and user attributes; enforced at query generation time so the warehouse only ever receives filtered SQL; tightest enforcement among BI tools | Row-level security via Metabase's sandboxing feature (requires Pro/Enterprise); simpler than LookML but less expressive; recommended to enforce primary RLS at the warehouse level |
| Embedded analytics support | Power BI Embedded with Azure capacity; JavaScript SDK for iframe embedding; pricing is per-capacity block, not per user, which makes it viable for large external user bases | Tableau Embedded Analytics with Connected Apps authentication; mature SDK; licensing cost is significant for external-facing embeds with many end users | Looker Embedded with signed embed URLs and granular per-user access control via user attributes; the most flexible embedding model but requires LookML investment to get value | Embedded iframes available on open-source and paid plans; limited SDK compared to enterprise tools; suitable for internal product embedding where full customisation is not required |
| Total cost of ownership | Low per-seat cost for internal users on Microsoft 365 E5 (Power BI Pro included); Power BI Premium or Fabric capacity required for pagination, large datasets, and deployment pipelines | Mid-to-high per-seat licensing; self-hosted (Tableau Server) adds infrastructure cost but removes per-user cloud fees; cost scales with user count | High per-seat licensing; cost is justified when LookML investment avoids duplicated metric definitions at scale; not economical for small teams or low-query-volume deployments | Free for self-hosted open-source; Metabase Cloud and Pro plans are inexpensive relative to enterprise BI tools; lowest cost option for internal analytics on a tight budget |
| When to choose | Organisation is Microsoft-committed (Azure AD, Teams, Office 365); primary consumers are business analysts; Power BI Pro licensing is already in the stack | Non-technical stakeholders need interactive exploration and customised views without writing SQL; visual analytics quality is the primary decision criterion | Data team is large enough to invest in LookML authorship; organisation needs a single authoritative semantic layer tightly coupled to the BI surface; embedded analytics with fine-grained access control is a requirement | Engineering or product team needs fast self-serve analytics without heavy BI tooling investment; existing data model lives in dbt and mart tables are already well-defined |
Anti-patterns to avoid
These are BI-specific failure modes — distinct from the underlying data-engineering anti-patterns. A technically sound pipeline can still produce a BI layer that is distrusted, unused, or unmaintainable.
Dashboard-first, definition-second
Building charts before agreeing on metric definitions is the single most common cause of BI work that has to be redone. When the dashboard comes first, each author interprets the metric name differently: one analyst counts unique users per calendar month, another counts sessions, a third counts logins with a 30-day rolling window. All three charts are labelled 'monthly active users'. The first time two executives compare screenshots in a meeting, trust in the data platform erodes — and the data team spends the next sprint explaining the discrepancy rather than building new capability.
Run a metric-definition workshop before layout begins. For each KPI on the proposed dashboard, agree in writing: the precise SQL or dbt MetricFlow expression, the denominator for rates, the time-grain options (daily / weekly / monthly), the filter conditions, and the system of record. Store these definitions in a metrics glossary that is linked from the dashboard itself. Only once definitions are signed off does chart design start.
Connecting BI tools directly to source or staging tables
When analysts connect Tableau or Power BI directly to a raw PostgreSQL table, a staging schema, or an unnormalised operational database, the transformation logic ends up inside the BI file. Joins, CASE expressions, aggregation filters, and date truncations accumulate in calculated fields that are invisible to the data engineering team, untested, and duplicated across workbooks. The first schema change in the source table cascades into broken reports, with no lineage to identify which dashboards are affected.
BI tools should connect exclusively to mart tables or semantic-layer endpoints that have been through the full transformation and quality pipeline. If the required data is not yet available in a mart, the correct response is to build the mart model, not to pull raw tables into the BI tool. Certify specific datasets in the BI tool's governance layer and enforce a policy that uncertified direct-warehouse connections require data-team review before publishing.
No access review on row-level security
Row-level security implemented in a BI tool at launch but never audited after launch is not security — it is a permission snapshot from one day in the past. Sales reps who change territories, managers who change teams, and users who leave the organisation retain access to the data they had at the time the RLS rule was written. In tools where RLS relies on a hardcoded user-attribute mapping (a lookup table of user email to region, for example), that mapping becomes stale within weeks of go-live without an automated sync from the source of record (the HR system or IdP).
Implement RLS by deriving access from a live authoritative source — Azure AD group membership, Looker user attributes synced from the IdP, or a warehouse-level row-access policy that joins against a current permissions table. Run a quarterly access review that compares who has dashboard access to who should have it based on current role. Document the RLS logic in the data catalog so an auditor can verify it without reading the BI tool's configuration UI.
Common questions
Our data is in multiple places and the numbers never agree — where do we start?
We start by agreeing a single definition for each metric and building one clean data model that all dashboards draw from. Once the source of truth is established, disagreements between dashboards disappear because there is only one answer — not one per system.
Can non-technical users create their own views and reports?
Yes, and that is the goal. Tools like Metabase and Looker are specifically designed for self-serve exploration by non-technical stakeholders. We set up the semantic layer and train your team; after that, most questions can be answered without asking the data team.
Related capabilities
Have something in mind?
Tell us what you're building or stuck on. The first consultation is free — no obligation, no hard sell.