> 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.
Yeah, I personally draw a distinction between data viz and BI. AI has definitely changed the former, it's pretty cool to be able to design visuals with claude design: you're not bound by what libs can do, html + svg lets you visualize data exactly how you want (and you can even get fancy with 3d stuff, with the pitfall of just showing eye candy with no real insights). I've built some fun stuff like that myself (also with duckdb-wasm).
But BI is more than just visualization: you need stuff like solid data models and semantic layers, tools that help enforce data governance (so that the same metric doesn't get re-defined in 12 different places, possibly with slight variations each time), proper access control (with RLS/CLS). Sure you can probably vibe-code your own BI tool, but it's gonna take quite a bit more work than just the viz part.
You are making an argument (that I can faintly see the outlines of) but eliding over the meat of it. I think you need to define “hairy internal situations.”
For ages the data industry has obsessed over tooling when really the biggest impact comes from the organisational/people aspects - achieving consensus on metrics, dimensions, key entities. In short, governance. You can't buy that you like can a SaaS product.
I have loved D3 for more than a decade but I'd never recommend it to a client because maintenance requires a large learning curve. Not any more, ${YourAIAgent} + D3 is awesome.
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.
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.
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
You should also factor in that you have way more flexibility in the dashboards you create and everybody can build them easily, just by describing what they need.
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.
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.
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.
yep, sw had their own visualization, those platforms were the chewed out version. now with llm, the entry bar is lower; the dinosaur managers at enterprise will have to adapt tho
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:
(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.
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.
Speak more on this, if you don't mind. I've worked some DBT migration projects before, and agree the manual management of everything was fairly time consuming. We used prefect for job management but DBT never struck me as fully baked (like most tech, I assume it has matured some since my time with it)
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 :).
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?
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.
That is a lot of tables for one schema. Maintaining so many tables seems like a security vulnerability in and of itself from risk PoV.
I think your prediction makes sense. There needs to be a lot of guardrails and you need a fully integrated platform/stack on the backend to protect the user from doing dangerous things because the AI ain't gonna tell them when something is dangerous or doesn't perform at the scale they need
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.
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.
Snowflake is a Data Warehouse that is hosted in the cloud. The permission policies that you can define can become very complex - actually I find it's too complicated, I prefer BigQuery from GCP because of this reason.
ex: you don't want all users to be able to access finance's tables, else you might have folks trading stock on information they're not supposed to be privy to.
Hundreds of dashboards that get outdated and stop feeding data correctly without anyone noticing... What can go wrong?
I agree with the idea that Looker is a low hanging fruit to replace a well maintained dashboard with a collection of one-use single case dashboards with the metrics AI decides is a bad decision, I think.
"The most you can charge for your software is my cost to recreate it."
It's interesting to see what other factors will come into play by vendors to allow charging higher prices. Lock-in in various forms, legal responsibility, etc.
Building is easy, supporting and sustaining is harder especially in light of things like all the CVEs. My startup valet.dev is a platform for skills, websites, apps, and agents that is solving for this by baking governance and sustainability into the system. All engineering teams need this, but as we see the rise of citizen developers bring productivity gains to their companies the need for collaboration, security, and sustainability builtin to the environment they work in is even more important than ever.
Don't forget 18 months trailing Soc II, Type 2. And that the time to execute on this idea was 15 years ago, back when this was relatively difficult to build.
We just started using GrokBot. After hooking it up to our PSA, the INCREDIBLE reports that this thing generates has blown us away. From a simple prompt like:
I need a usage and analytics report from the PSA. I need by tech, company and service board
That was my prompt and this thing created a report that was amazing in 10 minutes and something that we could NEVER get with BrightGauge. If you haven't already hooked up GrokBot to all your services, you are doing yourself an injustice.
> We already run everything on Kubernetes, so deploying a service was mostly a matter of adding a Terraform module and a Helm chart.
Haha "we run everything on kubernetes, so deployment is a matter of using the least logical complement to it, and the lowest budget, flakiest and overbuilt alternative to plan manifests with none of the benefits of an operator"
The introduction seems human written, but the slightly technical bits after that are clearly AI written, which makes sense, since the system that's being described was written by AI as well.
if you want to operate this 'bucket of HTML files' over time, my startup https://valet.dev gives you the tools to host, govern, enforce policies, and secure what vibe coders create at your company.
The world of who can create software is growing (hello citizen developers!) but the challenges of operating and maintaining software is just as hard.
Pando looks nice, thanks for sharing. Is this an overlay on e.g, AWS, or is the idea that this spins up a single container and creates partitions for each of the user apps its hosting?
It’s more of an orchestrator. Destinations are controlled through runtime “adapters” which essentially tell Pando where and how to put apps. Instead of partitioning a container, it creates an isolated network and deploys the different workloads of your app as containers (database, web, api, etc.)
Since it’s modular, the goal is to be able to use AWS, GCP, kubernetes, etc. as the destination for apps, if you are already using that.(not all of them are built yet). By default it uses Docker.
I wonder how much of that orchestration is necessary for a narrow use-case with low numbers of users. So many of our patterns are for a scale a small internal tool will never see.
> 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.
Yeah, I personally draw a distinction between data viz and BI. AI has definitely changed the former, it's pretty cool to be able to design visuals with claude design: you're not bound by what libs can do, html + svg lets you visualize data exactly how you want (and you can even get fancy with 3d stuff, with the pitfall of just showing eye candy with no real insights). I've built some fun stuff like that myself (also with duckdb-wasm).
But BI is more than just visualization: you need stuff like solid data models and semantic layers, tools that help enforce data governance (so that the same metric doesn't get re-defined in 12 different places, possibly with slight variations each time), proper access control (with RLS/CLS). Sure you can probably vibe-code your own BI tool, but it's gonna take quite a bit more work than just the viz part.
You are making an argument (that I can faintly see the outlines of) but eliding over the meat of it. I think you need to define “hairy internal situations.”
Agreed.
For ages the data industry has obsessed over tooling when really the biggest impact comes from the organisational/people aspects - achieving consensus on metrics, dimensions, key entities. In short, governance. You can't buy that you like can a SaaS product.
I have loved D3 for more than a decade but I'd never recommend it to a client because maintenance requires a large learning curve. Not any more, ${YourAIAgent} + D3 is awesome.
> most companies struggle to define what is important, what needs to be measured
Today that’s just a chat session, see https://reportr.com
Is it yours? Every BI tool has chat now, just like every other enterprise app.
Not SAP. That's 2 major outages/upgrades away
Can you imagine how much a SAP token will cost though
If I have to ask.. an Aston Martin? Maybe 2 fionas and a shekel
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.
Exactly this. My joke tagline for BI is "Lie to your colleagues with confidence and ease".
It doesn't have to be intentional, it just needs to be a sufficiently complex, messy real-world data.
> Lie to your colleagues with confidence and ease
https://xkcd.com/1138/
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.
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
You should also factor in that you have way more flexibility in the dashboards you create and everybody can build them easily, just by describing what they need.
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
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.
yep, sw had their own visualization, those platforms were the chewed out version. now with llm, the entry bar is lower; the dinosaur managers at enterprise will have to adapt tho
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.
Speak more on this, if you don't mind. I've worked some DBT migration projects before, and agree the manual management of everything was fairly time consuming. We used prefect for job management but DBT never struck me as fully baked (like most tech, I assume it has matured some since my time with it)
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
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?
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.
That is a lot of tables for one schema. Maintaining so many tables seems like a security vulnerability in and of itself from risk PoV.
I think your prediction makes sense. There needs to be a lot of guardrails and you need a fully integrated platform/stack on the backend to protect the user from doing dangerous things because the AI ain't gonna tell them when something is dangerous or doesn't perform at the scale they need
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.
Snowflake is a Data Warehouse that is hosted in the cloud. The permission policies that you can define can become very complex - actually I find it's too complicated, I prefer BigQuery from GCP because of this reason.
Thanks!
When you have 10,000 users scattered across every continent your access control needs get complex.
ex: you don't want all users to be able to access finance's tables, else you might have folks trading stock on information they're not supposed to be privy to.
Hundreds of dashboards that get outdated and stop feeding data correctly without anyone noticing... What can go wrong?
I agree with the idea that Looker is a low hanging fruit to replace a well maintained dashboard with a collection of one-use single case dashboards with the metrics AI decides is a bad decision, I think.
"The most you can charge for your software is my cost to recreate it."
It's interesting to see what other factors will come into play by vendors to allow charging higher prices. Lock-in in various forms, legal responsibility, etc.
I believe few minutes ago I read about the death threat to the BI tools on HN [0] and this is exactly an example of it.
[0]: https://news.ycombinator.com/item?id=50200997
You certainly don't need Looker or AI to do this!
Easy to host using many open source reporting/BI/analytics frameworks on a cloud page and maintain for pennies a day!
Good luck and most importantly have fun.
Wouldn't hurt to link Looker in the first sentence.
Building is easy, supporting and sustaining is harder especially in light of things like all the CVEs. My startup valet.dev is a platform for skills, websites, apps, and agents that is solving for this by baking governance and sustainability into the system. All engineering teams need this, but as we see the rise of citizen developers bring productivity gains to their companies the need for collaboration, security, and sustainability builtin to the environment they work in is even more important than ever.
BI tools have always been borderline easy to replace IMO. So long as you have a decent data layer.
This could be significantly cheaper if they used a different model.
At least replace it with dbt charts rather than a whole new vibe coded mess.
lol aren't dbt charts are like a month old? I assume this all happened before all that was open sourced
Were the dashboard used for insights or for making the managers feel good?
ERR_CONNECTION_REFUSED
I guess I'm not reading this...
it works now
Nope, seemingly geo blocked...
What is Looker?
Multi billion 'Business intelligence' tool now from Google; more or less a fancy charting library with some access controls.
Damn sounds like easy money.
If 12 month enterprise sales cycles sounds like easy money then sure.
Don't forget 18 months trailing Soc II, Type 2. And that the time to execute on this idea was 15 years ago, back when this was relatively difficult to build.
https://lmgtfy.com/?q=looker
“Looker is Google Cloud agentic business intelligence and embedded analytics platform.”
Something of the past according to the author.
Looker has already started pivoting into the agentic BI platform but it is still not great.
We just started using GrokBot. After hooking it up to our PSA, the INCREDIBLE reports that this thing generates has blown us away. From a simple prompt like:
I need a usage and analytics report from the PSA. I need by tech, company and service board
That was my prompt and this thing created a report that was amazing in 10 minutes and something that we could NEVER get with BrightGauge. If you haven't already hooked up GrokBot to all your services, you are doing yourself an injustice.
IF you are using Looker in 2026 look at ai/grok/fable/etc.
Billionaires out there are gaining billions everyday meanwhile i see common folk nickle and diming each other.
" look how i vibecoded this app and save $1.99"
> We already run everything on Kubernetes, so deploying a service was mostly a matter of adding a Terraform module and a Helm chart.
Haha "we run everything on kubernetes, so deployment is a matter of using the least logical complement to it, and the lowest budget, flakiest and overbuilt alternative to plan manifests with none of the benefits of an operator"
AI wrote this
The introduction seems human written, but the slightly technical bits after that are clearly AI written, which makes sense, since the system that's being described was written by AI as well.
Honestly do not care that the words are vaguely AI tinted. The semantic content is not AI, it's not slop.
Put it this way: would you rather this article didn't exist, or had less detail? Because that's the alternative in many cases.
It is a pretty good article. If AI wrote it then good for AI.
If it was so good, why do you have nothing to say about the content?
Criticize the content, not the means of creation.
Attack the substance of the criticism, not the form.
What substance?
AI wrote the article
WOW
if you want to operate this 'bucket of HTML files' over time, my startup https://valet.dev gives you the tools to host, govern, enforce policies, and secure what vibe coders create at your company.
The world of who can create software is growing (hello citizen developers!) but the challenges of operating and maintaining software is just as hard.
This is very similar to the open-source platform I’ve been building called Pando (https://github.com/trypando/pando)
Validating to see others trying to solve this problem too!
Pando looks nice, thanks for sharing. Is this an overlay on e.g, AWS, or is the idea that this spins up a single container and creates partitions for each of the user apps its hosting?
It’s more of an orchestrator. Destinations are controlled through runtime “adapters” which essentially tell Pando where and how to put apps. Instead of partitioning a container, it creates an isolated network and deploys the different workloads of your app as containers (database, web, api, etc.)
Since it’s modular, the goal is to be able to use AWS, GCP, kubernetes, etc. as the destination for apps, if you are already using that.(not all of them are built yet). By default it uses Docker.
I wonder how much of that orchestration is necessary for a narrow use-case with low numbers of users. So many of our patterns are for a scale a small internal tool will never see.