The dashboard is the most winnable custom build in business software, and the reason is unglamorous: most companies do not need a BI platform, they need eight charts that are actually correct, visible to the right people, updated without anyone exporting a CSV.
BI vendors sell the platform. The need is usually the eight charts. That gap is where the build-vs-buy math gets interesting.
What you are actually comparing
Not "Metabase vs a React app." The real comparison is between two cost structures:
Buying means per-seat or per-usage licensing forever, a semantic layer you configure but do not control, connectors that mostly exist, and a vendor roadmap that may or may not care about your use case. The hidden line item: the analyst who maintains the workspace, because self-serve BI is self-serve the way IKEA is furniture.
Building means development cost once, hosting cost always, and a maintenance owner forever. Total control of logic and presentation. The hidden line item: the data plumbing underneath, which is most of the work and is required either way.
That last sentence is the one people miss, so it gets its own paragraph.
The dashboard is the cheap part
Whether you buy or build, the actual work is upstream: getting data out of your shop, CRM, ad platforms and database; cleaning it; agreeing what "revenue" and "customer" mean; joining identities across systems. That pipeline is eighty-plus percent of any dashboard project I have ever built or audited, and it is identical in both scenarios. (When definitions are the real problem, no tool choice saves you; that failure mode is why your single source of truth keeps lying.)
Practical consequence: if a vendor demo looks magical, it is because the demo data was clean. If a build quote looks cheap, it is because it assumes your data is clean. Neither condition survives contact with your actual systems.
When buying wins
- Your questions are standard: sales by period, funnel by stage, spend versus revenue. The BI category exists because these repeat everywhere.
- You need exploration, not just display. Analysts slicing freely is exactly what BI platforms are for and exactly what custom builds do badly.
- Nobody in-house can own code. A dashboard with no maintainer becomes wrong silently, which is worse than absent.
- Seat count is small. License economics only start to hurt at scale; five seats of anything is cheaper than any build.
When building wins
- The logic is yours: custom pricing, margin bands, regulatory formulas, a domain model no semantic layer expresses without violence.
- Wide, read-only audiences. Fifty warehouse screens or an all-hands display versus fifty licensed seats is where per-seat pricing stops being funny.
- The dashboard faces customers or partners. Embedding licensed BI into a product is possible and priced accordingly; at some point you are paying rent on your own product's feature.
- It is small and known. Eight charts, defined metrics, stable sources. Small custom builds age gracefully because there is little to rot. In my own project pricing, builds start around the cost of a mid-range laptop fleet, not a rebrand; the point is they are bounded, and license fees are not.
The hybrid that usually wins
The setup I end up recommending most: a proper data layer (warehouse or even a disciplined set of scheduled queries), open-source or low-cost BI on top for internal exploration, and a small custom layer only where the standard tools genuinely cannot go: the customer-facing view, the odd domain logic, the wallboard.
This keeps the expensive property (the clean, defined data) in your hands, uses cheap commodity tools for commodity needs, and spends custom development only on the slice where it has no substitute.
Run the numbers in one afternoon
Write down: license cost at your real seat count over three years; the hours per week someone currently spends assembling reports by hand, priced at their salary; the build quote; and a maintenance line of roughly a day a month. Compare honestly. In my experience the answer is "buy, but fix the data layer" more often than either camp likes, and the exercise takes an afternoon, not an engagement.
If the numbers are close or the data layer is the obvious blocker, that is a well-shaped small project: define the metrics, build the pipeline, and defer the build-vs-buy call until the data can support either answer. That ordering never turns out to be wrong.