There are several approaches to creating a dashboard for sharing your most important metrics - we covered the most common ones in this article.

Often the decision over which approach to take boils down to building your own (or hiring someone to build one for you) or going with an off-the-shelf KPI dashboard solution like Geckoboard.

Here we’re going to discuss the pros and cons of build versus buy to help you make an informed decision as to what’s the right approach for you.

Pros and Cons


It’s undeniable that building your own dashboard from scratch offers more flexibility than an off-the-shelf product. The only real limit to what you can do is time, money and know-how. Coding your own dashboard you’ll be able to completely customize the appearance, use any visualization you want and do more extensive data processing.

The one exception to this is that some of the tools in your stack - that contain the data you want to visualize - only offer full access to their data to select partners, which you might not get.


The flipside to flexibility is cost and effort.

To build a Geckoboard dashboard using our pre-made integrations is likely to take you less than an hour and our paid plans start at $35 a month.

Building your own dashboard from scratch is going to take significantly longer (days or weeks of engineering time), require some level of project management, and carry the opportunity cost of diverting energy and money away from core projects.

You’ll also need to consider where to host the dashboard code and how to keep their contents secure - this is sensitive business data, after all.

You should also factor in ongoing maintenance. What you need on your dashboards will change over time as your organization's goals and KPIs evolve. APIs (the method for programmatically getting data from a service) also change frequently, requiring updates to keep working.

Even what seem like relatively simple dashboards at face value can easily add up to tens of thousands of dollars. We’ve had some customers quoted $100K+ by their own IT teams to create the same setup they were able to achieve themselves in a few hours with Geckoboard.

Ease of making changes

Good dashboards require constant iteration. Only once you start using your dashboard in earnest do you truly discover what metrics are most useful and what visualisations work best. The same charts that work well in a report might be too hard to interpret, or not engaging enough on a dashboard that’s meant to be looked at more regularly by a wider audience.

Keeping your team engaged with your dashboard requires you to make constant changes, and, when business goals change, dashboards need to be updated quickly to stay relevant.

Making changes to your dashboard is much harder if you need to file a ticket, lobby a project manager, or hire a developer. This is a common reason DIY dashboard projects often end up failing.


Coding your own dashboard gives you complete control over how your dashboard looks. And whilst most open source charting libraries provide hundreds, if not thousands of ways to present your data, they rarely produce attractive graphs out-the-box. To make an attractive dashboard from scratch, someone will need to customize them heavily and have an opinion on which visualizations are better than others. A designer with a good understanding of data visualization best practices is essential for good results.

With dashboard software like Geckoboard you get attractive, professionally designed dashboards that everyone in your organization will be able to understand as standard.

Advanced functionality

With an off-the-shelf dashboard product like Geckoboard you get features like scheduling your dashboard to post to Slack, displaying your dashboards on a big screen or TV, dashboard loops, and status indicators. Unless you’ve got a very generous budget, it’s unlikely you’ll be able to replicate these with your own homegrown approach.

Technical considerations when coding your own dashboard

If you decide to take the do-it-yourself approach you will need to:

  1. Create a spec of exactly what you or other stakeholders want to include on your dashboards. For each metric consider exactly how it should be calculated, where the data is coming from, how it should be visualised, details like axis scales, what timeframe it should be reported on, and how quickly it should be updated. Also think about the overall layout.
  2. Technically review how you’ll return the data for each metric. Have a developer look at each data source’s API documentation to check the data required can be returned and what additional processing will be required.
  3. Decide a technical approach. This includes how to pull the data, where the code will be hosted, what charting libraries to use, and how to ensure secure access.
  4. Code and deploy your dashboard.
  5. Verify the data matches your spec and what the values you’re expecting.
  6. Review your dashboard after a few weeks of use and iterate. Once you or your stakeholders start using your dashboard it’s very likely you’ll want to make changes. Some metrics may not lend themselves well to a dashboard or confuse your audience. Asking others for feedback on what they find useful is an essential step.

Hidden complexities to be aware of when building your own dashboard

The biggest challenge of building your own dashboard is working with third party APIs. We’ve worked with 100s of different APIs over the years. Here’s what you need to watch out for:

Missing metric endpoints

For most cloud services APIs are an afterthought and aren’t designed to provide all the data you require via a single API request e.g. ‘tell me what my First Response Time was for my US team yesterday’.

Many, like Zendesk, provide you with raw information about your individual tickets, but don’t provide any calculated metrics.

You therefore need to return the atomic data (e.g. every ticket raised in the last 30 days), reverse engineer how the metric is calculated within Zendesk, and then process the data to calculate the metric you need. Because APIs like this need to return thousands of rows of data they are also almost always paginated - meaning you need to make multiple requests to return all the data you want and may end up handling huge volumes of data.

At Geckoboard we spend a lot of time talking to companies to find out exactly how their metrics are calculated and how they handle timezones, to minimise any potential data discrepancies.

No historical data

Some APIs will return the exact metric you require but, frustratingly, won’t provide any historical data for that metric. So you might be able to see how many impressions you had on your website today, but not yesterday or last month. If you want to see trends for the metric over time you’ll need to store the data yourself and build up your own table of results. If you’re taking a snapshot you’ll want to make sure you pull back the data at exactly the same time everyday.

API rate limits

Another potential gotcha with APIs, particularly paginated ones, are rate limits. Many vendors limit how many requests you can make in a certain amount of time as well as how many you can make in parallel. Some, like Salesforce, even charge for API usage.

Overcoming this can involve having to store more data locally, implementing caching, and adding your own rate limiting.

Changing APIs

Most services work on their APIs continually and they frequently make breaking changes. It’s important to take into account that even if your requirements stay the same you’re likely to need to make ongoing changes (as often as every quarter) to your code just to keep your dashboard working.

The big players like Google and Facebook, as well as smaller rapidly growing organizations, are particularly guilty of this.


Using a tool like Geckoboard will work out significantly cheaper than building your own dashboard in almost every case - especially when you consider ongoing maintenance.

The biggest selling point though is that being able to easily update your dashboards is going to make them far more likely to be successful longer term. Dashboards that don’t match your current team priorities are useless.

However, building your own dashboard solution from scratch offers the ultimate flexibility. If you can dedicate the time and money to build and maintain it you’ll be able to customise it more heavily to your needs. Just make sure you go in with your eyes open and don’t underestimate the complexity.