You could build this yourself. Here's the rest of it.
We hear this one a lot, and we’re not going to pretend it’s wrong: you could build this yourself. It has never been easier to stand up a dashboarding tool. Open a terminal, point an agent at a warehouse, and by the end of the afternoon you’ll have charts. That’s not a sales objection to argue away. It’s true, and it’s worth saying plainly before we say anything else.
Yes, you could
Ask an agent to turn a query result into a dashboard today and the turnaround is genuinely startling. Paste in some rows, describe the layout you want, and a few minutes later you have working charts: a bar chart of revenue by region, a line chart of signups over time, a KPI row across the top. Wire it into a Streamlit page or spit out a static HTML file, and you have something you can screen-share in a standup that afternoon. We’ve written before about exactly this moment, because it’s the moment that convinced us dvt needed to exist. The instinct is correct. Describing a dashboard in a sentence beats clicking a GUI into submission, and it should.
That afternoon build is real, and it is a small fraction of what a dashboarding platform is. The rest is where this post lives.
What the afternoon build doesn’t have
The gap doesn’t show up in the demo. It shows up two weeks later, when someone asks the questions a demo never has to answer.
What happens when two people edit the same dashboard and you need to see what changed, not just what it looks like now? A single HTML file has no history: there’s nothing to diff, nothing to revert, nothing to say “this panel used to compute the metric a different way.” What happens when a junior analyst’s dashboard needs a second set of eyes before it goes in front of a customer? There’s no review loop, because there’s no format a reviewer can read against. What happens when two teams in the same org shouldn’t see each other’s data, or a dashboard needs to run inside a customer’s own Snowflake account instead of yours? That’s tenant isolation and packaging, not a chart library.
Warehouse drivers are their own quiet tax: Snowflake’s type system doesn’t behave like Postgres’s, BigQuery paginates differently than either, and Google Sheets isn’t a warehouse at all until you write the adapter that pretends it is. Render fidelity is another one: Apache ECharts alone has dozens of series types, and getting every one of them to render correctly, in every layout, at export resolution, is a long tail of edge cases that never shows up until a customer hits it. Then there’s exporting on a schedule, giving an agent the same authoring surface a human gets with attribution on every edit it makes, and getting through a security questionnaire when a prospect’s InfoSec team asks how you isolate their data. None of that is visible in a demo. All of it is where the actual engineering work goes.
Where the weeks actually went
We can put rough numbers on this because dvt’s entire history lives in a handful of git repos, and git doesn’t round up.
The product repository alone has crossed a thousand merged pull requests. Add the website, the infrastructure-as-code, and the internal agent harness we built to do the work, and the count runs past two thousand commits. Dozens of architecture decision records document the decisions behind that work. More than two hundred SQL migrations moved the schema forward. Hundreds of test files back it.
The shape of the commit history tells an honest story if you read it right: many small commits while the surface was forming, then fewer, larger, more reviewed pull requests as it stabilized. That’s not a team running out of steam. It’s refinement, not slowdown.
What that time bought is the product surface itself: warehouse drivers for Snowflake, Postgres, and BigQuery, a Google Sheets adapter, and a DuckDB reader for uploaded files, the full Apache ECharts chart surface, a Snowflake Native App that runs inside a customer’s own account rather than ours, an MCP server and a REST API so agents and humans author the same versioned JSON spec, visual diffs between dashboard versions, panel-anchored comments, scheduled exports, and agent attribution on every edit. Each of those is a project. None of them is visible in an afternoon demo.
The harness is the actual product
Here’s the part that’s easy to undercount: none of the above happened by a small team typing faster. It happened through a purpose-built agentic harness, and building that harness was its own sustained effort, run in parallel with the product it was building.
The harness is a review-and-ship system of specialized agents and enforcement hooks: unreviewed changes cannot become pull requests, shipped changes are verified against what the ticket asked for rather than just the code, and every measured mistake is written down so no agent repeats it.
Getting that discipline right took as long as the product, because it’s the thing that makes more than a thousand merged pull requests trustworthy instead of just numerous. An agent that can write a dashboard spec in an afternoon is a commodity now. A harness that keeps dozens of architecture decisions consistent with each other, blocks unreviewed changes automatically, and gets more disciplined over months instead of sloppier is not something you get from the same afternoon. It’s a second thing to build, and most teams evaluating “build vs buy” haven’t priced it in.
Build it yourself, or don’t, honestly
If dashboards are your product, if you’re a BI vendor or you’re building something genuinely novel in how data gets visualized, build. That’s a real business decision and an agent will get you further, faster than it would have a year ago.
If dashboards are the thing standing between your data and your decisions, and not the thing you’re in business to build, the afternoon demo was never the hard part. The dashboard spec is open, the product runs against your Snowflake account the way we describe here, and the Builder is free to try. The months are already spent. You don’t have to spend them again to find out what an afternoon build was missing.