# Replacing Scattered Dashboards With One Analytics Cockpit > How consolidating fragmented BI into a self-hosted app on a refactored warehouse schema cut cost, built trust, and became the platform multiple business units actually adopted — a warehouse refactor nobody sees but everyone uses. By Cody Bakken · 2026-07-31 · https://codybakken.com/writing/retiring-dashboard-sprawl/ In a lot of companies, the first ten minutes of every leadership meeting go to the same argument: whose number is right. Sales has one figure for pipeline, the exec deck has another, product reports a third — same label, different tools, different people, and no way to tell which one to believe. Nobody built a *wrong* dashboard. They built six slightly different ones, and the result is that leadership trusts none of them. That's the real cost of dashboard sprawl, and it's why "we have too many reports" is the wrong way to describe the problem. The reports aren't the issue. The issue is that they disagree, and disagreement is corrosive in a way a messy folder of dashboards never is. ## How sprawl happens It's nobody's fault, which is what makes it hard to stop. A team needs a report, so they spin one up in whatever tool is handy — a quick dashboard here, a workbook there, a spreadsheet feeding both. Each one re-implements the same business logic a little differently. "Active customer," "pipeline," "engaged user" — each gets defined independently three or four times, and the definitions drift apart over months until no two match. Nobody owns the whole picture. The tool licenses add up, but that's the small cost. The real one is that leadership slowly stops believing any single source, and an organization that doesn't trust its own numbers makes slower, worse decisions and doesn't always notice it's happening. ## The decision to consolidate The fix was to bring it into one place, and I'll be candid about the build-versus-buy call, because it's the part people get wrong. Every BI tool charts fine; visualization was never the gap. What we lacked was a single, owned application where each metric is defined once and everyone reads the same thing. Buying another reporting tool would have added a seventh dashboard to the pile. So we built one: a self-hosted analytics app that consolidated the reporting scattered across a half-dozen tools — executive KPIs, company and per-rep sales, customer health, partner success, product usage, and content coverage — behind one front door. One place to go, one set of definitions, one thing to trust. *[Diagram — see the web version: https://codybakken.com/writing/retiring-dashboard-sprawl/]* ## The part nobody sees The app is what people point at. The real work was underneath it, in the modeling layer — the transformation code (a dbt- or Dataform-style setup) that turns raw tables into the datasets every report reads from. Consolidating the dashboards meant consolidating *that*: defining each metric exactly once, with its dependencies and data-quality checks living in one versioned place, so "pipeline" or "active customer" has a single definition and a lineage you can trace back to source. The discipline that makes it hold is boring and non-negotiable: the app carries no business logic of its own. It doesn't recompute "engaged user" in a callback or a spreadsheet formula — every page reads from a modeled table where that definition already lives. When a number needs to change, it changes in one model, and it changes everywhere at once. That's the mechanism that keeps the six dashboards from drifting apart again. Refactoring that model also cut compute and storage cost by a real margin, but the savings were a side effect. The point was one definition, computed one way, everywhere it appears. Nobody ever sees a warehouse schema; everybody uses the numbers it produces. A clean, well-modeled foundation is invisible by design, and it's the reason the visible layer on top can be trusted at all. ## Consolidation is an ownership problem Picking the tool is the easy, visible part of a project like this, and it's the part everyone fixates on. The decision that actually determines whether it works is organizational: one source of truth, each metric owned and defined a single time, and one place leadership goes to look. Get that right and the arguments about whose number is correct simply stop. That's also what adoption runs on. Business units moved onto the platform because they could trust it and because everything was finally in one spot — and adoption across teams is the only honest measure that a consolidation actually worked. A "single source of truth" nobody uses is just another dashboard. ## Coding agents made it buildable Here's the part that would have been hard to imagine a few years ago: a self-hosted production app plus a refactored modeling layer is the kind of scope that used to require a dedicated platform team. It didn't. A small team built and owns the whole thing, and the honest reason is coding agents. Pairing with an AI agent, one person can stand up the app, wire the deployment, write the transformation models, and cover the tests — the breadth that used to mean several specialists and a much longer runway. The wrinkle worth sitting with: the agent accelerated the *building*. It did not supply the *foundation*. Coding agents are fast at producing code on top of a clean data model, but they can't hand you a clean data model you never invested in. Point one at a tangle of conflicting definitions and you get the same tangle, generated faster. The leverage only appears because the infrastructure underneath — modeled, owned, grounded data — was already there for the agent to build on. ## The foundation is the product This comes back to a conviction that runs through most of my work: the visible layer is the easy part, and the data underneath is what makes it worth anything. That's truer in the agent era, not less — when a working app is an afternoon of pairing with an agent, the modeled foundation underneath is the part that stays hard, and the part that carries the value. A polished app sitting on five conflicting definitions is just a more convincing way to be wrong in a meeting. Ground the model — one definition, one lineage, clean and owned — and the dashboard on top finally means something. Dashboard sprawl looks like a tooling problem, so teams keep solving it by buying tools. Underneath, it's a foundation problem. Fix the model, give every metric a single home, and the payoff shows up where it counts: numbers people actually believe, and meetings that open with the decision instead of an argument about the data.