First rule of vibe coder club? Vibe-code a dashboard. Second rule? Tell your mom and all your followers about it.

Paid, free, duct-taped together, in Lovable, Cursor, Replit, wherever. And it looks great. The person didn't write a line of code, and by evening they've built themselves a panel with charts, filters, and a pretty "Export" button. Cool, right?

On one hand, yes. This is exactly the world we dreamed about: less dependence on the dev team, fewer queues, more freedom for marketers, analysts, and PMs.

But there's another side.

Building a dashboard got easier. And here's the paradox: it didn't solve the old problems. It added new ones.

How? Watch.

A dashboard is a function. It helps you make better decisions. It's not a magic wand. It's a shovel you dig a hole with.

So a dashboard, like any analytics tool, doesn't do the decision-making for you. More often it sells you new work: open it, explore, understand, explain to colleagues, turn it into a task, follow up, come back, check.

Trick question: why are we buying ourselves new work?

Why did dashboards start breeding right now?

LLMs and vibe coding made building products dramatically easier. A landing page, a prototype, a form, an internal admin panel, an integration, a small tool for the team. All of it comes together faster. What used to look like a separate project now sometimes gets done in one evening.

And what do we do with this new superpower?

Build another screen with charts, faster.

Funny? Yeah. Logical? Also yeah.

The dashboard used to be an expensive artifact. You had to put it in the queue, write the requirements, ask an analyst, then a BI developer, then wait, then redo half of it because "that's not actually what I meant."

Now you can build it yourself.

And that changes behavior. When something gets cheap, we start doing it more. Even when we don't really need to. Not because we're dumb. Because we're human.

The problem: the speed of building a dashboard isn't the speed of making a decision.

You can throw together five new charts in an evening. But in the morning you still have to figure out:

what changed?
why?
who does it affect?
who owns it?

And above all: what do we do next?

And here's the shitty part. More dashboards don't lead to more decisions. They lead to more questions.

Once more. Dashboards are shovels. Question: do you need more pretty shovels?

What PostHog figured out about the next step in analytics

I recently listened to an interview with James Hawkins, co-founder and CEO of PostHog.

PostHog started as open-source product analytics: events, funnels, session recordings, errors, experiments.

But in the interview Hawkins says something more interesting: PostHog is heading toward self-driving software. Software that doesn't just show you the problem but helps you fix it.

That's a really important shift.

Not "let's ship one more dashboard."
But "let's create effective new decisions."

For example: we see the data, the errors, the session recordings, the support tickets, the Slack threads, the customer calls. We figure out where the person got stuck. We suggest a small change. We open an issue or a draft pull request. The person reviews it. After release, the system checks whether things actually got better.

Analytics stops being a source of new problems. It solves the old ones.

How many people does it take to fix one problem?

Here's the traditional way of solving problems:

A user complains. Support opens a ticket. An analyst digs through events, the funnel, session recordings, errors. A PM frames the task. An engineer fixes it. A week or a month later, someone checks the metric.

Logical? No. It's buying yourself a fresh headache.

At every step a piece of context gets lost. In this chain the dashboard usually doesn't shorten the path. It just adds one more stage:

"Now someone has to look at the chart and decide what to do with it."

A bad dashboard is a work generator.

It doesn't help you decide faster. It just multiplies the places you have to look.

And, sadly, almost every vibe-coded dashboard is bad.

What should happen after the chart?

This, I think, is where the main question has to change.

Not "what other chart do we need?"
But "what is it for?"

Look at the product analytics flow again:

data → chart → a human looks → a human thinks → a human hunts for the cause → a human writes a task → someone builds it → someone checks it later.

What if we shifted it a little? Say:

data → explanation → possible action → human review → result check.

The difference sounds small. In real life it's enormous.

Say the system notices that after an onboarding change, activation of new users dropped.

The product of your analytics isn't the chart, and it isn't even the alert. It's a request to a stakeholder for approval:

"The drop started after the release. Mobile-traffic users got hit hardest. They're stuck on the integration-connection step. Possible action: add a clear explanation and a fallback CTA. Here's the task, examples, and the metric to check it against."

This still isn't magic. It's just normal work, the kind people used to do between calls, in Slack, in Jira, and around the phrase "so who's picking this up?"

You're not staring at a dashboard. You're reading a draft pull request and the agent's arguments.

The human stays on review, merge, priorities, and accountability.

Accountability is the most expensive part of analytics. Not building the chart. Getting something to actually change after it.

What I do when a client asks for a dashboard

For me this isn't abstract.

I work as a Fractional Head of Marketing Analytics. And most of the time the client really does come in asking for a dashboard.

That's a fine request.

The team needs to see channels, leads, CAC, ROAS, revenue, the funnel, conversions, traffic quality.

But more and more I think a dashboard by itself is half the work. Sometimes a quarter.

Because at best a dashboard answers "what's happening?"

And the business wants to know "what do we do about it?"

Here's the paradox. Even when a client asks for a dashboard, by default I'm not thinking "which charts go on it."

I'm thinking: what decision is this dashboard supposed to speed up?

If there's no clear answer, we don't have a dashboard task. We have an expectation-therapy task.

So I always design and include whatever boosts the thing that matters most: decisions.

Sometimes that really does need a dashboard.
Sometimes it's a chat with your data: "Why did paid search dip yesterday?", "Where did CAC go up but pipeline didn't?", "Which segments should we kill?"
Sometimes it's automatic anomaly explanation.
Sometimes it's an alert that doesn't just scream "a metric changed" but shows the likely causes.
And sometimes the best dashboard is the one we didn't build.

Yes, that sounds dangerous. Especially if you sell dashboards.

But a good marketing analytics layer should reduce work. Not create new work.

Every time you order a dashboard, you're buying more than a tool. You're buying yourself another job: open it, study it, understand it, explain it to the team, turn it into a task, chase the action through, come back, check the result.

And by the way: if you sell dashboards, I've got bad news for you.

Why AI should cut the number of dashboards

Every other person out there is vibe-coding a control panel for their life, business, sleep, leads, budget, meatballs, and spiritual growth.

But the hangover always comes. And that's great.

I'm waiting for it to become obvious to everyone: the problem isn't that we have too few dashboards. The problem is that we have too few decisions.

The easier it gets to build products and internal tools, the more often people will ask: "why do I need a dashboard in front of my next dashboard?"

And, oddly enough, that's great.

AI is quietly teaching us the most important BI skill: don't build a dashboard on autopilot because someone asked. Ask what work it's supposed to take away.

What to ask before your next report

Don't rush off to build an AI that commits straight to prod.

Most companies don't need that right now. And honestly, it's a little scary. We haven't even fully agreed on UTM tags.

You can start simpler.

Before every new report, ask: what decision will this help me make?

Then step away for a smoke. And ask one more thing: could I do this without the report?

Building an alert on a metric drop is easy.

What if the alert produced not just anxiety, but the next step?

From there you can move toward issues and draft PRs for small, safe changes. Leave the merge to a human. Leave product decisions to a human.

And the boring work between "we spotted a problem" and "we framed the first action," shrink it bit by bit.

What did your analytics do after the takeaway?

The dashboard was a fine interface for the era when analytics ended at "here's what happened."

But if AI can already write code, read logs, summarize calls, find anomalies, and explain data, stopping at the chart is strange.

The takeaway is only the middle. The new work starts after it.

The real question is different: what did your analytics do after it understood the problem?

If the answer is "showed another dashboard," then maybe you didn't buy yourself a decision.

You bought yourself another job.

Want all my best GA4-BQ queries in one place? I turned them into a Chrome extension — top SQL queries you can search and copy in seconds.

Go here to install it for FREE.

Prefer the web version? It’s here.