How hard is it to reverse-engineer BI tools?

My company is looking for a BI solution and evaluating different options. Currently we have Cube backend + Metabase frontend. Out of curiosity I asked Claude: “How hard is it to reverse-engineer BI UI features — like Looker’s — when all our data is already in Cube models?”

Here’s Claude’s answer:

This is a solid question. Since you already have Cube as your semantic layer, you've actually knocked out one of the hardest parts.

Here's a breakdown of the difficulty by feature area:

What Cube Already Gives You
- Semantic modeling (measures, dimensions, joins)
- Query API (REST + GraphQL)
- Caching & pre-aggregations
- Access control at the data level
- SQL generation & optimization

Feature Difficulty Spectrum

Easier to build (weeks):
- Basic query builder — Cube's meta API exposes available measures/dimensions/filters, so you can build a "pick columns + measures" UI that maps directly to Cube queries
- Simple table/chart rendering — libraries like Recharts, ECharts, or AG Grid handle this well
- Basic filters — Cube's filter API is well-structured, mapping UI controls to it is straightforward

Medium difficulty (1-3 months):
- Dashboard builder — layout engine (drag/drop tiles, resize), saving/loading state, filter propagation across tiles
- Drill-down / explore flow — Looker's "click a bar to drill into it" requires managing query context chains
- Dynamic filter controls — date pickers, cascading dropdowns, cross-filtering between charts
- Pivot tables — Cube supports pivoting but the UI for configurable row/column pivots is non-trivial

Hard to replicate well (3-6+ months):
- LookML-style "Explore" UX — the full-featured query builder with join path awareness, field picker with descriptions, custom expressions
- Scheduling & delivery — email/Slack delivery of snapshots, PDF rendering, threshold alerts
- Row-level security + embedded analytics — multi-tenant embedding with per-viewer access control (Cube helps here but the UI/auth layer is work)
- Caching UX — showing freshness, allowing manual refresh, pre-aggregation management UI
- Version-controlled content — Looker's git-backed model is a whole workflow

Very hard / probably not worth rebuilding:
- SQL runner with autocomplete — IDE-level SQL editing
- Data catalog / lineage — field-level documentation, usage analytics, impact analysis
- Governance layer — content certification, usage tracking, deprecation workflows

Practical Recommendation

Given you're on Cube, the sweet spot is usually:
1. Build a custom query builder + dashboard layer on top of Cube's APIs — this is where most teams get 80% of Looker's value with 20% of the effort
2. Use Cube's REST API /meta endpoint to dynamically populate your field pickers
3. Skip the generic BI platform and build domain-specific views that match your actual use cases (you'll get better UX than Looker for your specific workflows)

The main risk isn't any single feature — it's the compounding complexity of making them all work together smoothly (filters + drill-down + pivots + dashboards + permissions). That's where BI tools have years of edge-case handling.

Sounds like it would be hard to build to a point that works better than Metabase.