Can we replace a $150k Looker with a bucket of HTML files? (david.lequin.dev)

> A BI tool is mostly a way to turn a query into a picture, and a picture now costs about $0.50 of tokens. It gets hard to justify a $150k licence for that part

That is an awfully simplified view of BI. In my experience, most companies struggle to define what is important, what needs to be measured, and how those measurements should be used to improve business.

While businesses try to work these details out, they try getting their analysts to in the author's words print out good pictures. But the BI tools really exist to make it easy for analysts to navigate hairy internal situations.

Producing a picture or HTML more easily is not going to solve the decisioning problem. If anything it might make it worse.

In the end, it's going to cost a lot more than 50 cents a picture.

Over a decade ago i worked at a company with a BI tool that was exactly this, minus the AI of course. it was just PHP pages backed by embedded SQL built by a non engineer. anytime someone wanted a different slice of data, the person just copied an existing page and swapped out the sql and the column names. URL query string was used for the different parameters of the SQL statement, i forget if it was open to sql injection but it was an internal tool only. even after implementing a BI tool everyone still used the PHP pages because it was faster and easier to just bookmark the specific page you want with the data you wanted.

much like low code tools, most people dont want to mess with self serve BI. AI might help with that but i think the tool in the article opens the door for people creating slightly different versions of the same thing. also, claude is awful at visualizations. every one i see looks the same, crammed full of bad charts and too much text, poor color choices, and no real value in terms of story. still, this is an interesting implementation of that concept.

Ayeee! We're actively doing this right now at my company. One of the more clever engineers has tackled replacing a $300k/yr Looker subscription, which we've paid for a decade, with a homegrown implementation sponsored by Claude.

And it seems like we're succeeding! To be fair, we weren't making good use of Looker's features and so the problem was easier than expected... but the core idea was validated in a couple of weeks, we've had just one person on the project part-time for a couple of months, and we told Looker (well, Google) we won't be renewing yesterday.

We're just doing a 1:1 conversion to start with the hope that our customers barely notice the change. Afterward, we'll re-envision our dashboards with the new found flexibility of not serving them via iframe.

Crazy times!

I built something similar in my previous job. The part that we were never able to figure out is how to guarantee that everybody is looking at the right numbers. Even if you have a comprehensive semantic layer, there are still a lot of things that can go wrong in putting metrics on a dashboard. This is why analysts are still needed, IMHO.

I've been working in "genBI" for a few years now and this has been exactly the trajectory. We started by focusing on selling shiny viz with an AI engine to produce it. But now making a fancy chart indeed costs 0.50, except it's going to be the wrong chart with the wrong data that will be read once and lost.

The hard part with all of this is building and maintaining a semantic layer, but more importantly capturing all the prompts and queries users are firing in to make these shiny HTMLs. Since making them is so cheap, what you want to do is capture that usage and convert that into improvements to the actual BI layer (the semantic definitions, the skills and knowledge base files, even the charting engine rules) so you can provide a consistent, correct source of truth for everyone at your company (or anyone relying on you for analytics, even your end users).

The data model underneath all these charts, especially a self-improving one based on processing usage data into quality evals and fine tuned models, is now the key. The charts can be replaced with HTMLs made by Claude for sure.

(Disclosure: I'm the founder of Upsolve so I think about these problems every day)

We were paying $40K/year for both salesforce and salesloft. Both got built into a simple app for the sales and SDR team. The new app is way clean and faster than Salesforce. We even hired a consulting agency to setup/manage Salesforce and its reports. That consulting agency is also gone.

We replaced Looker with Hex [1], which was 7x cheaper (for our use case). But soon afterwards we built our own in-house data agent platform "Reef", which has now effectively changed how the entire company operates, from sales and customer success, to defining commercial and operational strategy. One of my engineers Samuel has done a small writeup about it [2]. Essentially, if you take care of your ETL and make data modelling a first class citizen, you can build your own BI (or even better - agentic BI) relatively easily.

[1] https://hex.tech/

[2] https://www.samuelsvensson.com/blog/reef

It would be been a more thorough analysis if they had accounted for the engineering teams’ salaries in time devoted to recreating this tool and maintaining it, rather than just tokens.

In the end, it would likely work out to more like 50% cost savings. Still good, but certainly more expensive than this article ultimately claims

For some use cases, and when everyone has access to all the systems, and data volumes allow reasonable perf, I could see this working well.

For things like customer-facing analytics, there needs to be a deployment layer for AI-native artifacts that supports ongoing operations & maintenance. If you want a conversational data agent to answer questions and reduce custom analytics requests, that's more to manage and maintain.

If you watched the Claude Dashboards announcement, they said legacy bi will be the deployment layer for AI artifacts. I don't buy it. Legacy BI was terrible at deployment in the first place.

We've built a performant, browser-native alternative to deploy and scale AI artifacts at Ridge AI (ridgedata.ai).

Fascinating to watch all of this evolve in real time.

We just exited looker by having codex migrate the dashboards to html.

Now it's just a git repo.

This is similar to what we did pre-SaaS. When I joined Uber in 2014, each person had an S3 bucket scoped to their username, and any html file you put there had a static url that could be shared with anyone at the company. We started with dumping jupyter notebooks to share analysis, then over time scheduled jobs to update more and more complex dashboards. It was a lot of fun!

Add Tableau to this list. Claude natural language produces better visualizations. The constant which will survive traditional BI is the data warehouse not the presentation layer.

If you like Looker semantic models and Git workflow, but want to build your own AI-BI platform now, I recommend looking at Credible Data as the engine:

https://www.credibledata.com/

(I have no connection to the company, just know the industry well.)

Credible uses Malloy as the semantic model language. Malloy is built by the original Looker founder and friends, essentially as their next-gen "what would we do differently now" project. It's been discussed on HN a few times in comparison to PRQL, Cube, etc.

Credible layers on some serving infrastructure and RAG and the like. They specifically target the SWE persona as their user. Very technical team with good perspective on the future of the industry IMO.

Categorically, yes.

We had a very similar scenario except with Snowplow (I think - this was many years ago) that used to cost silly money per month.

Replace most of it with GCP BQ Schedule Queries.

A few years we hired a "data" team, they came in and prompt introduced the cluster fire that was DBT. Costs exploded, data was a mess. The few bits of data that we owned, we ring fenced and just kept chugging along on GCP BQ Schedule Queries.

KISS.

It seems like this is a relatively simpler case, where everyone sees the same content. Oftentimes, people want dashboards to query as the current user, some user group, or the people below the current user in the org chart. That means that you need to run queries dynamically, and generate the chart at runtime, rather than just hosting HTML.

Great article! This is exactly the use case we created dbt Charts for. If you're thinking of making a system like this, do consider us for your Chartifact format. You can host it locally, in streamlit, or with our provided hosting that adds some nice UI, agents, permissions, Claude connectors, etc. We've also got some Looker and other tool migrators :).

https://dbtcharts.com

I work at Retool, and probably the majority of our business today is "replacing SaaS with citizen-developed apps". I think that a lot of these CRUD-y SaaS products (which is, really, what BI is) will disappear over the next few years. The bottlenecks I see:

* Data quality — we've seen Databricks / Snowflake schemas with 10^5 tables. Just putting a LLM on that doesn't work - you do need some sort of semantic layer. This is especially bad since LLMs are like slop cannons — if you ask it to prove X with the data, it will build you an app / visualization that proves X.

* Deduplication — it turns out many people want moderately different views of the same data. How can you host everything centrally and DRY everything out such that you can guarantee correctness?

* Writing data back — this is where it gets really hairy. Dashboards that only read data from Databricks is dangerous insofar that data can leak. But once you start needing to write data back, you need access to APIs / MCPs... and then you want some sort of authorization layer (since many SaaS apps don't have great authorization within themselves).

Obviously we work on quite a bit of this at Retool, but we are always looking for ideas on how to make this better. We believe that many things should be in a platform (e.g. centralized data connectivity, authentication, authorization, etc.) setup by engineering, and then non-developers can go crazy generating safe apps.

It reads to me like their first version (sharing the output html) essentially skipped their permission layer. That seems like a dangerous decision if someone can share the sales data analysis openly with users not allowed to see such data?

For a related use case, I have been using claude to add or change features in my own tensorboard log reader. The flexibility of being able to change anything at any time so I can see what I want to see is really nice.

I've always preferred local monitoring tools, but tensorboard is seemingly just on life support at this point.

https://github.com/dleemiller/BlernsBoard

We’ve been using evidence (https://github.com/evidence-dev/evidence) for this. You can have agents build an ad hoc dashboard, or if it is worth sharing you can commit it.

Enterprise friends: what is snowflake and why did it have fine grained permissions for a whole company? I didn’t understand it from the snowflake website.