I use Claude every day. I still build dashboards in SquaredUp

If you've looked at SquaredUp and thought "I don't need this, I'll just use Claude", I understand completely. I've thought it too. Here's what changed my mind.

I use Claude constantly. I've also spent the last few months building the parts of SquaredUp that let it in: our MCP server, the object graph and correlation, a stack of plugins. So this isn't a dashboard vendor being sniffy about AI.

I've watched Claude pull from several sources and produce something genuinely useful in under a minute. No tile configuration, no scope, no query syntax. After years of building dashboards by hand, that still gets me.

And yet I build dashboards in SquaredUp. With Claude, not instead of it. That's the part I'd most like to land: these aren't alternatives, and everything got better for me when I stopped treating them as a choice. It’s not Claude or SquaredUp, it’s most definitely Cluade with SquaredUp.

Here are five reasons I still build the dashboards.

1. I want the same answer twice. So does everyone else.

A few weeks ago I asked Claude to work out our monthly active users. We went back and forth, landed on a number, and I got on with my day.

Then I asked again. Not in the same words. I'd forgotten exactly how I'd phrased it. But the same question.

I got a different number.

Neither answer was wrong. One counted anyone who'd signed in, the other anyone who'd actually opened a dashboard. One used a rolling thirty days, the other the calendar month. Both were fair readings of "monthly active users", which turns out to be a phrase I had never actually defined.

That's not a flaw in the model. It's what happens when the method lives in a prompt instead of in a system.

Anyone who was around when every analyst got their own SQL access will recognise this. The promise was that everyone could answer their own questions. And they could, six different ways, arriving at six numbers, all defensible, none reconcilable, all in the same meeting. As often as not the argument was about what counted as an active user. The fix was never taking SQL away. It was agreeing the definition once and letting people query freely around it.

That isn't a history lesson. Everyone on your team has the same AI now, and their own way of phrasing things. Six people, six prompts, six subtly different answers, and nothing to tell you which one to act on. The tool is far better than it was. The failure mode is identical.

A KPI in SquaredUp is defined once. Next month's number is comparable to this month's because it was calculated the same way, not because I happened to ask the same way. And it's the same number for everyone, because there's only one of it.

2. My tools don't know about each other. SquaredUp does.

Here's a question I actually care about: how much did it cost to build that feature?

To answer it, something has to know that my Jira account and the author of that GitHub pull request are the same person. That the PR was merged. That merging it triggered a build in Azure DevOps. That the build deployed a Lambda. And that the Lambda has been costing money ever since.

Four tools, and not one shared identifier between them.

Claude can have a good go at this. It matches on names, timestamps and branch conventions, and it'll often get it right. But "often" is doing a lot of work there, and when it's wrong it doesn't throw an error. It just attributes the cost to the wrong thing, confidently, and you can't see the broken join from a chat window.

In SquaredUp that map is declared. It's a rule somebody wrote down, not a guess made on the fly. And rules can be wrong too. But a bad rule is wrong the same way every time, somewhere you can go and look, which means someone can fix it. A bad guess is wrong invisibly, and differently each time you ask.

That's the difference between a map of your technology and a map of your business.

3. Other people need to look at it too

An answer in Claude chat is mine. If someone else wants it, I paste a screenshot into Slack or send them a link they can't open.

A SquaredUp dashboard has an address, and it keeps working. It isn't a picture of what was true on Tuesday afternoon. It's the same question being asked again every time someone opens it. It goes in a runbook, on a wall, into a scheduled report, in front of a customer. It's still current when I'm on holiday.

Then there's checking it. When Claude hands me a number in a chat window, verifying it mostly means doing the work again. On a dashboard I can click into the tile and see which entities, what timeframe, which source. So can everyone else, including the person who thinks the number is wrong.

That isn't because dashboards are inherently trustworthy. Plenty of dashboards are quietly wrong. It's that a dashboard can be checked and a paragraph of text can't, and being checkable is what trust is actually made of. "The AI worked it out" isn't an answer you can give a customer disputing an SLA credit.

4. Not everyone has the keys

My AI assistant can only reach what my credentials can reach. That's correct, and it's also the problem.

For everyone to answer their own questions this way, everyone needs their own access to every tool in the chain. That's a lot of credentials in a lot of places, granted per person, per connection, per tool.

In SquaredUp the connection is configured once by someone who should be doing it, and access to what it returns is set at the workspace by whoever actually knows who should see what. People get the answer without getting the keys.

For an MSP with customer data in the mix, that distinction isn't administrative. It's the whole job.

5. I have better things to do with my time (and tokens)

There are over 100 integrations already built and maintained in SquaredUp, and a visualization layer designed for exactly this. Asking an AI to reconstruct that from raw APIs on every request means solving paging, rate limits, auth refresh and schema quirks again each time. It also means quietly absorbing whatever it gets wrong, like a partial result that looks complete.

Yes, this also costs tokens, but that's the least interesting version of the argument. The real cost is doing work that was already done.

The dashboard is the memory

Here's the way I've come to think about it, and it changed how I work.

When I'm solving something with Claude, we go back and forth. I explain the estate, it queries, I correct it, it tries again. Eventually we land on something right: the correct scope, the right filters, the definition of "healthy" that matches how we actually operate.

That conversation is expensive. Not in tokens, but in my attention and my judgement.

So the last step isn't to have Claude remember it. It's to build a dashboard. The point isn't that the AI can give me the same answer next month. It's that it doesn't have to.

Building it turns out to be the last check, too. You can't put a number on a dashboard without deciding exactly what it measures, over what period, for which systems. Everything that stayed comfortably vague in the conversation has to be pinned down before it becomes a tile.

The dashboard is where a good answer stops being a conversation and becomes a fact. It's the memory: the place that answer gets promoted to, so nobody has to work it out again, argue about it again, or hope this month's phrasing matched last month's.

What I still use Claude for, constantly

• Anything I'm asking for the first time. Exploration is where it's strongest and it isn't close.
• "What happened overnight?" Questions with no shelf life.
• The messy middle, where I don't yet know what the right metric is.
• Building the dashboard itself. That's the part I didn't expect: the fastest way to get a good dashboard is to work the problem out in conversation, then have it built.

One explores. One remembers. I'd not want to give up either.

The bit I'd want you to take away

If you've been asking an AI the same question every month, that's your signal. Not that it's failing. It's answering fine. It's that you've found something worth knowing repeatedly, and you're paying to work it out from scratch every single time.

The best outcome of a good conversation isn't a good answer. It's not needing to ask again.