Gritt has been eyeing an essay around since May. It argues that dashboards are mostly a sales layer, and it has been waiting for a receipt. This month one arrived: a three-person team that let Claude write its dashboards and published the bill. We make a few dashboards ourselves, so we read the numbers with professional interest. These build-or-buy calls changed for some teams, not others, and he hands over the three checks that tell the two apart. — Muximus
A three-person data platform team at a company of about 500 people built a replacement for much of its Looker use in eight months. The build bill came to about $8.3k: roughly $6.4k in Claude tokens and $1.9k in AWS.
Staff and an analyst agent use Claude to write each dashboard as an HTML file. A small internal service hosts it. Running the whole thing costs about $20k a year, most of it new feature work.
David Lequin published those numbers on October 14. He compares them with $150k a year for Looker - which he labels as the average Looker license for roughly 300 seats, taken from 355 Looker deals reported by Vendr via Coefficient. It's a market average, not his company's invoice.
Each new dashboard now costs about $0.50 to make.
The dashboard just became the cheap part
We buy BI seats because building and maintaining dashboards takes skilled time. That's the belief.
Lequin's analyst agent uses about a million tokens to go from a first question to a finished page. After the team moved it to Opus 5.5, the cost per dashboard dropped from about $2.50 to about $0.50. The agent did the same work. The tokens got cheaper.
At fifty cents a page, the old reason to buy gets weak.
The platform around the dashboards wasn't a weekend hack either: 325 commits, about 74,000 lines of code, about 20,000 of them tests. Lequin says Claude wrote most of it, while three engineers worked on it on the side.
And people used it. Weekly viewers went from 23 in March to 136 in June. By the time Lequin wrote the post, the tool had as many weekly users as Looker, "maybe even more." Looker usage is down by about a third.
Down a third. Not gone.
The value was never in the dashboard
The dashboards are not what made Lequin's setup safe. Three things upstream of them did.
Permissions stay in the warehouse. Every query runs with the viewer's own Snowflake token. The API checks who is asking with SELECT CURRENT_USER(). Sharing a dashboard never grants access to data the viewer couldn't already read.
Definitions stay in the semantic layer. The team already ran a dbt project with more than 2,000 models. (dbt is where a company writes down, in code, what "revenue" or "active customer" actually means.) A metadata service flags any dashboard that reads raw data instead of a dbt model. Lequin's own summary: "The governance that matters already happens upstream, in dbt models and Snowflake roles."
A human publishes. Anything an AI uploads lands as a draft. A person has to click Publish.
With those three in place, the dashboards can be loose, fast and disposable. Without them, a cheap dashboard is just a cheap way to show the wrong number to the whole company.
That's the build-or-buy call in one line. The BI license was paying for two things at once: the charts, and the rules about who sees what and what each number means. The charts are now almost free. The rules are not, and they belong in the warehouse anyway.
What broke on the way
Lequin is plain about the failures. For anyone planning the same move, this is the most useful part of his post.
Accuracy first. A year earlier, his team's "chat with your data" demos looked great on a toy schema with four tables and failed at company scale: "The SQL ran without errors, but the numbers were wrong."
Security second. In the first version, dashboard JavaScript ran on the same origin as the user's session. In his words: "It was basically one big XSS hole: any dashboard could run code as whoever opened it and pull data out in their name." The team shipped it anyway. It was internal, it sat behind VPN and SSO, and there was no other tool for the work.
The rebuild is a checklist worth stealing:
- Each dashboard runs in a sandboxed iframe on its own origin, with no cookies and a strict content security policy. It talks to the parent page only through
postMessage. - Content tokens last one hour and work for one dashboard, one viewer and one host.
- A metadata service reads every new version and applies rules. Some only report - unpinned scripts, no opens in 90 days. Some block - an unfamiliar package script, or a WebRTC connection, which a content security policy can't stop.
What the bill leaves out
Three gaps, before anyone pastes these numbers into a board deck.
The $150k is a market average. It's not this company's contract. The 12x figure in Lequin's cost chart compares the eight-month build ($8.3k) with eight months of Looker at that average, about $100k.
Engineer time isn't in the $8.3k. Lequin says so himself: "We can't put an honest number on the hours, because they were spread across everything else we did." Pipelines, dbt, the warehouse, Kubernetes and on-call are excluded too.
It's one team's self-report. We couldn't check the viewer counts or the costs independently. And this team started from a place many companies haven't reached: warehouse roles already set up, a mature dbt project, and three people who run a data platform for a living.
Lequin's own rule fits that: build when you need software that fits your work and you already have a platform and a team, unless the product's advantage is scale.
The argument underneath
In May, Tamir Pomerantz made the same case from the other side. His Hebrew-language post is titled (in translation) "Tools for non-human consumption: why dashboards need to die."
His point: the product is the pipeline - the functions, logs, models and rules running in the background. The dashboard is a narrative layer on top, "meant to sell the system and give a feeling of 'control.'"
Lequin's numbers show what happens when that layer gets cheap. The spend moves to the pipeline and to the rules around it.
Pomerantz also points at what comes next. An organization runs dozens of similar systems, each with a dashboard that hardly anyone but the CTO looks at. "The dashboard for managing 30 dashboards can't be a bigger dashboard." His alternative is an interface that turns the logs into questions that need a decision - ten keys unused for more than three months, what now? - and sends them, rarely, to the person accountable for the outcome.
That's a design idea, not a shipped product. But it follows from the same economics. When a chart costs fifty cents, the scarce thing is a person's attention.
The vendor in the room
Anthropic launched Claude Dashboards in beta on October 8 for paid plans, with connectors to Snowflake, BigQuery, Redshift, Databricks and others. Lequin says that if his team were starting from scratch, they would "probably look at it first."
Anthropic sells the tokens this build ran on, and now sells a dashboard product of its own. It benefits from this story, and the numbers should be weighed with that in mind.
Three checks before the BI renewal
Before a BI renewal, three checks decide whether any of this applies:
- Where do permissions and metric definitions live? If they live in warehouse roles and a semantic layer like dbt, dashboards can be cheap and disposable. If they live inside the BI tool, moving them upstream is the real project, and it comes first.
- Can a platform team own a small hosting service? SSO, a sandboxed origin per dashboard, short-lived scoped tokens, and a rule that anything an AI uploads stays a draft until a person publishes it.
- Start with the long tail. Pick the dashboards few people open. Replace those with AI-written ones, and track two numbers: weekly viewers and cost per dashboard.
If all three hold, the build is now cheap enough for us to try this quarter.
From founder thinking to company building.
We don’t just write about AI-native companies. We build them. VarOps works with leadership teams to rethink how their businesses operate, turning ambitious ideas into systems that actually work.
Sources
- David Lequin, "Can we replace a $150k Looker with a bucket of HTML files?", October 14, 2026: https://david.lequin.dev/blog/bi-software-is-dead/
- Tamir Pomerantz, "Tools for non-human consumption: why dashboards need to die" (Hebrew), May 11, 2026: https://tamirp.com/blog/dashboards.html
- Anthropic, "Build live dashboards and animate explainers with Claude", October 8, 2026: https://claude.com/resources/articles/dashboards-and-motion
