Almost everyone who sets out to build a dashboard starts in the same place: a number they want to see, in a system that won't show it to them. What happens next depends almost entirely on a decision made in the first ten minutes, usually without much thought.

There are three ways to build a dashboard. They differ enormously in cost, and the cheapest one for you depends on a single question: where does the number live?

The three ways to build a dashboard

1. Build it yourself — a frontend app, a chart library, and somewhere to host it.

2. Use a BI or connector-based tool — point it at a database or pick from a catalogue of integrations.

3. Point a dashboard at an API you already have — write an endpoint that returns the number, and let something else render it.

Each is genuinely the right answer sometimes. What follows is what each one actually costs, so you can pick on evidence rather than on which one sounds easiest at the start.

Route 1: Build it yourself

You write a React or Vue app, pull in a chart library, wire it to your API, and deploy it.

This is the right call when the dashboard is the product — a customer-facing analytics page, something with heavy interaction, or a view so specific that no generic widget renders it. If people outside your company will look at it, build it.

The trap is that the first version takes an afternoon and looks great, which makes everything after it feel unplanned. What you've committed to isn't the afternoon — it's the chart library's next major version, the auth layer when a second person needs access, the responsive pass when someone opens it on a phone, the hosting, and the quiet afternoon in eight months when it breaks and the person who wrote it has left.

We've written the long version of this in why building dashboards yourself is more work than you think. The short version: the build is cheap and the ownership isn't.

Route 2: A BI tool or connector-based dashboard product

Two different things get grouped here, and it's worth separating them.

BI tools — Metabase, Looker Studio, Power BI, Superset — connect to a database or warehouse and let you query it. They're excellent at exploration: ask a question, get a chart, ask a better question. If your numbers already live in a queryable store and someone on the team is comfortable in SQL, this is a strong default and you should take it seriously.

Connector-based dashboard products — Geckoboard, Klipfolio, Databox — offer a catalogue of pre-built integrations. Pick your sources, drag out tiles, done. When your stack is entirely made of things in that catalogue, this is the fastest route on this page by a wide margin.

Where both get expensive is the number that isn't in the catalogue and isn't in the database: a metric defined by your own business logic, a third-party API nobody built a connector for, or a figure that needs two systems joined. Then you're writing a custom connector, staging data into a warehouse you didn't want, or wiring a Zapier hop that silently stops one Tuesday.

There's a second cost that gets discovered late. Most of these tools want credentials — database access, API keys for every source. That's a real conversation with whoever owns your security review, and it can outlast the evaluation.

Route 3: Point a dashboard at the API you already have

If your data is behind a REST API — and after a decade of building this way, it almost always is — there's a shorter path. Write a small endpoint that returns exactly the number you want, in a fixed JSON shape, and let a rendering tool turn it into a widget.

The endpoint is where your business logic already lives, so the awkward parts stay in the language you already use. Does a trialing customer count toward MRR? That's an if statement in your own code, not a setting in someone's UI.

This is the right call when the numbers come from an API rather than a queryable store, when your metric definitions are opinionated, when combining sources matters, or when handing over database credentials is a blocker. It's what we built dashboardbase to do — you write the endpoint, we render the JSON.

The cost is real and worth stating plainly: you have to be able to write and deploy an endpoint. If that's a two-week change process, or nobody on the team writes backend code, this route is worse for you than either of the others.

What the work actually is

Building a dashboard isn't one job. It's about ten, and the routes differ in who does each.

The pattern is the point. Route 1 puts every row in your column. Route 2 takes almost all of them off you and asks for credentials plus a catalogue match in exchange. Route 3 keeps exactly the two rows where your knowledge is irreplaceable — where the data is and what it means — and hands over the eight where it isn't.

Which route should you pick?

Answer these in order and stop at the first yes.

1. Will people outside your company use this? → Build it yourself. It's part of your product.

2. Is the job exploring a dataset rather than watching known numbers? → BI tool. That's what query builders are for.

3. Does all your data already sit in one queryable database, and is someone comfortable in SQL? → BI tool, probably self-hosted if credentials are sensitive.

4. Is every source you need in a connector catalogue, and is nobody going to write code? → Connector-based dashboard product.

5. Is your data behind APIs, spread across systems, or defined by your own logic — and can someone write a small endpoint? → API-first.

Most small technical teams land on 5 and try 1 first, because the first afternoon of route 1 is the most satisfying afternoon in the whole comparison.

A worked example: one endpoint, one widget

Here's the entire API-first route, end to end. A KPI widget wants this shape:

{
  "title": "MRR",
  "actions": [
    {
      "title": "View Details",
      "type": "link",
      "url": "https://example.com/mrr-details"
    }
  ],
  "data": {
    "header": {
      "title": "$12,345",
      "subtitle": "vs last month",
      "badge": {
        "text": "+$1,120",
        "icon": "ArrowUp",
        "color": "Success"
      }
    }
  }
}

You can check that right now, without an account, in the free endpoint validator — paste a response, find out whether a widget can render it.

The handler is the boring part:

app.get('/dashboard/mrr', async (req, res) => {
  const cents = await currentMrrCents()
  const delta = cents - (await lastMonthMrrCents())

  res.json({
    title: 'MRR',
    actions: [
      { title: 'View Details', type: 'link', url: 'https://example.com/mrr-details' },
    ],
    data: {
      header: {
        title: usd(cents),
        subtitle: 'vs last month',
        badge: {
          text: `${delta >= 0 ? '+' : '-'}${usd(Math.abs(delta))}`,
          icon: delta >= 0 ? 'ArrowUp' : 'ArrowDown',
          color: delta >= 0 ? 'Success' : 'Danger',
        },
      },
    },
  })
})

Paste the URL into a widget and you have a dashboard. Charts and tables follow the same envelope with different contents inside data.

If even that feels like work, it can be generated. The open-source dashboardbase Skill teaches Claude Code or Cursor the contract so an agent scaffolds the endpoint properly, and the widget editor generates a copy-pasteable prompt for whatever AI tool you already use. Both give you a draft you review and run yourself — which is roughly the whole argument of building a dashboard with AI.

Where the API-first route breaks down

We'd rather you find this out here than three weeks in.

• You need exploration, not a board. There's no drag-and-drop query builder. If the question changes every day, you'll be redeploying endpoints, and you should be using a BI tool.

• Nobody can write an endpoint. This is the hard prerequisite. Non-technical teams are genuinely better served elsewhere.

• You need write actions. Approving refunds, editing records, triggering jobs — that's an internal-tools problem, and Retool exists for it. Dashboards here are read-only on purpose.

• You want everything joined in one semantic model. Deeply integrated suite reporting across a large org is a warehouse-and-BI problem, and no amount of endpoints makes it not one.

The honest bottom line

The question isn't "which dashboard tool is best." It's where your numbers live and who's willing to write code.

If they live in a warehouse and someone writes SQL, use a BI tool. If they live in a catalogue of SaaS products and nobody writes code, use a connector product. If they live behind APIs you already own — and they usually do — writing a fifteen-line endpoint is the shortest honest path to a dashboard you'll still have in two years.

If you're specifically weighing that last route against building it yourself, our build-versus-buy framework goes deeper on the ownership maths, and API-first dashboards explains the mental model.

Or just point one at an endpoint you already have and see what it renders. That takes less time than finishing the comparison.