BI tool or build your own dashboard? Why I did neither

I built dashboardbase because I was tired of two things: paying for expensive third-party dashboard tools, and spending my own time (and lately, AI tokens) building dashboards myself. This post is about why neither worked for me, and what I do now.

Building it yourself

I've built plenty of dashboards by hand. Before AI coding tools, each one took hours: the frontend, the charts, the layout, login and access control, then hosting it somewhere.

AI made the writing part faster. It didn't make the rest go away. Someone still has to host the thing, keep it running, update dependencies and remember how it works six months later. I didn't want to spend tokens or mental energy on a frontend that only shows numbers my backend already knows.

What you get: full control over every pixel, and no outside dependency.

What it costs: the first version, then everything after it. Hosting, auth, maintenance, and a new piece of UI every time someone wants a new number. (The long version is here.)

Using a BI tool

Power BI, Tableau and Looker are powerful, and for real analytics across large datasets they're the right tool. My problem with them was never the charts.

It was the data. A BI tool wants a copy of it: you connect your database or warehouse, set up syncing, and the numbers now live in someone else's system too. I never liked handing my data to a third party just to look at it, and I didn't want a sync job to babysit.

What you get: advanced analysis, lots of built-in visualisations, and data exploration.

What it costs: database access for an outside tool, a pipeline to keep in sync, a query model to learn, and permissions managed in yet another place. For an API-driven backend it's a poor fit.

The third option: point a dashboard at your API

dashboardbase doesn't touch your database and doesn't store a copy of your data. Your backend already has the numbers. You add an endpoint that returns them as JSON in a fixed format, and each endpoint becomes a widget. The data stays behind your own API, and you decide what it returns.

The dashboard runs on the web and in the native iOS and Android apps, and I don't host or maintain any of it myself.

Writing the endpoint is the only real work, and you don't start from a blank file. A free Skill teaches Claude Code, Cursor or any skills-capable agent the JSON format, and the editor can generate a copy-paste prompt for one widget or a whole dashboard. You review the endpoint and can check its response in the validator before wiring it up.

A real example: page views from Fathom

I use Fathom Analytics for website stats. Fathom has its own dashboard, but I wanted page views next to my other numbers, not in a separate tool.

So I added an endpoint that reads page views from Fathom's API and returns them as a widget. It took about ten minutes. Now page views sit on the same dashboard as my other numbers, instead of in Fathom's.

That's the pattern I use for everything: if a number is reachable from my backend, it's ten minutes from being on a dashboard, and it lives next to the rest.

When to pick something else

dashboardbase isn't for everyone, and I'd rather say so here:

• You don't have an API or a backend. dashboardbase reads endpoints. If there's nothing to call, there's nothing to show.
• You want point-and-click with connectors to all your apps. If your data lives in a dozen SaaS tools and nobody on the team writes code, a connector-based tool like Geckoboard or Databox is the better fit.
• You need deep ad-hoc analysis across large datasets. That's what BI tools are built for.

How they compare

If your numbers already live behind an API, you don't need to build a frontend or copy your data anywhere to see them. That's the gap I built dashboardbase for.