Skip to content
StriqTech Logo
Guides & Comparisons

How much a dashboard in Looker Studio or Metabase costs: the 3 questions that set the price

The price of a dashboard is not set by the tool: it is set by how many records have to be matched by hand, which decision depends on fresh data, and who signs off on the definition of each metric.

15 min readStriqTech

USD 400 on one side, USD 6,000 on the other, and both quotes use exactly the same software: Looker Studio and Metabase are free in the version a small business uses. The license does not explain a single cent of that difference. What you pay for is hours of getting data in order before the first chart even exists.

A distributor with 1,240 SKUs shows it better than any explanation: Tiendanube (a Latin American e-commerce platform) publishes with the internal code, Mercado Libre (the largest marketplace in the region) with its own listing identifier, and the cost spreadsheet the owner maintains writes “Blue 20 L drum”, “blue 20lt drum” and “BLUE DRUM 20” for the same product. That work — making two records written differently recognize each other as the same one, and getting two people at your company to sign off on what each number means — is 80 percent of the project and it does not show on the final screen.

That is why the price is not set by the tool or by the number of charts, but by three answers you can write yourself in ten minutes, before asking anyone for a quote: which field makes a record in one system correspond to one in another and how many will not correspond; which concrete decision changes if the number arrives a day late; and whether your team, today, gives the same number when you ask how much you sold last month. Two providers who receive those three answers quote similarly. Without them, they quote whatever they imagine.

The license is free; drawing the charts is the last hour of the project

Looker Studio does not charge per dashboard or per user in its standard version. Metabase is open source: running on your own server it has no license cost, and the version they manage themselves starts at around USD 85 a month for a small team, a number worth checking on the day you look at it because these plans change often.

Choosing one or the other moves one line, but not the one people think: Metabase on your own server pays no license and in exchange adds a server and someone to keep it updated, which means retainer, not setup. Looker Studio skips that line and in exchange ties you to having your data live where Google can read it.

So two quotes USD 3,400 apart use exactly the same software. As a rough rule — not a measurement of your case — drawing the charts takes around 10 to 20 percent of the hours. The other 80 goes into two jobs that do not show on the final screen: making two records written differently recognize each other as the same one, and getting two people at your company to sign off on what each number means. That is why a twelve-chart dashboard on a single spreadsheet costs less than a three-chart one that crosses your online store with your invoicing.

Question 1: which field joins the systems, and how many records will not join

Write down every number you want to see and next to it the system where it lives today. A small distributor ends up with something like this:

  • Sales by channel: Tiendanube and Mercado Libre.
  • Cost per product: a spreadsheet the owner maintains.
  • Collections and invoicing: the management system.
  • Stock: the management system, except for the new warehouse, which goes in another spreadsheet.

Four sources. But the number of sources barely moves the price: what moves it is the second half of the question. Which field makes a record in one system correspond to one in the other, and what percentage will be left out.

Put numbers on it. That distributor has 1,240 active SKUs. Tiendanube publishes with the internal code, Mercado Libre with its own listing identifier, and the cost spreadsheet identifies products by a hand-typed name: “Blue 20 L drum”, “blue 20lt drum”, “BLUE DRUM 20”. An automatic match on the normalized name pairs up somewhere in the order of 60 to 70 percent; the rest ends up in a list someone goes through row by row. That is some 400 to 500 cases, and at a reasonable pace of 40 an hour, between 10 and 13 hours of one person's time before the first chart. It is a typical order of magnitude, not a measurement of your catalog.

That is where the metric you are actually buying comes from: what percentage of your sales is left unmatched. A dashboard with 3 percent unmatched gets used, because it ties out against anyone's Excel and the differences can be explained. With 18 percent it does not get used: the first time someone compares it against their spreadsheet, the dashboard loses the argument and never gets opened again. And going from 18 down to 3 does not cost proportionally less than getting to 18: what is left are the ugly cases — bundles sold as a single unit whose cost is built out of five items, discontinued products that keep showing up, shipping charged as if it were an item — and each one is resolved with a decision of yours, not with a formula from the provider.

That is why it is better to place yourself by the type of work, not by the number of systems:

  • Nothing to match. Every number lives in a single system and no chart mixes two. There is no mapping table, and if a budget line shows up for this, ask what it is for.
  • Matching by key. Both systems share the same SKU, customer number or invoice number, written the same on both sides. It is a matter of hours, it is done once, and the only thing to negotiate is what the dashboard shows when a record with no counterpart appears.
  • Matching by judgment. There is no field in common and someone has to decide, case by case, that these two rows are the same thing. This is where the mapping table lives: it is the most expensive line in the budget and the only one that keeps costing money after delivery, because every new product adds a row.

Before quoting anything, send a one-line email to whoever sold you the management system: whether it has an API or a schedulable automatic export, or whether the only way out is for a person to click “export to Excel”. If it is the second, that export is not a detail: it is a step someone at your company repeats every week forever, and it has to be budgeted in your own people's hours.

Question 2: which decision changes if the number arrives a day late

Answer it number by number, not in general. With everyday metrics it looks like this:

  • Stock replenishment: the decision is made once a week, when you put together the order to your supplier. A dashboard that refreshes on Monday mornings is more than enough.
  • Cutting an ad campaign that is not converting: the decision is made every morning. You need fresh data before 9.
  • Stopping a shipment to a customer with overdue debt: the decision is made at the exact moment the truck leaves. That is not a dashboard.

The third case is the one that saves the most money: when the answer is “I need to find out right away” you do not need a more expensive dashboard, you need an alert, which costs quite a bit less. A dashboard is a place you go to look at; an alert comes looking for you. Run your list through that filter before quoting: there are almost always two or three numbers that are alerts and you were about to pay for them as screens.

For the ones that really are a dashboard, each frequency forces something different to exist:

  • Monthly or weekly: it is enough for one person to press a button on Monday. The problem is not technical, it is that someone has to remember, and that is why it is worth tying it to a meeting that already exists.
  • Daily and unattended: the process runs on its own and, above all, warns you when it did not run. That warning — to an email or a chat, naming which source failed — is the part of the monthly retainer that really is worth paying for.
  • Every few minutes: querying the systems live stops working, because they will rate-limit your queries and the screens will lag. You need a database of your own in between storing the data as it happens: that changes the whole project, not the dashboard.

And the one that is always forgotten: from what date the series is comparable with itself. The problem is not how many months of data you have, it is which month you changed the criteria in without recording it. If in March you started invoicing shipping as a separate item, or migrated management systems, or stopped voiding credit notes and started offsetting them instead, your curve has a step that is not a change in the business: it is a change in accounting. An honest dashboard marks it with a vertical line and a footnote; a bad one shows it to you as if you had grown 12 percent from one month to the next. Write in the quote request from what date you want the series and what changes of criteria there were in between: normalizing that is a separate item and one of the most underestimated.

Question 3: if you ask four people for last month's sales, do they give you the same number?

Do it today, separately and without saying what it is for. The pattern that shows up almost always, with made-up numbers for the example:

  • Sales says USD 82,000, because they added up everything that was ordered.
  • Administration says USD 71,000, because they added up what was invoiced.
  • The owner remembers USD 78,000, which is what came into the bank.
  • The accountant says USD 74,500, because they count by the issue date of the tax invoice and take out the month's credit notes.

All four are right and they are measuring different things. A dashboard is obliged to pick one and label the other three with a different name, and that choice is signed off by you, not by the provider. If the answers do not match, you do not have a dashboard project: you have a definitions project with a dashboard at the end, and between 10 and 30 hours of the budget are meetings and validation.

Write each metric on a single line with four elements: what is counted, when it is counted, what is excluded and what it is compared against. Like this:

Monthly sales: sum of orders in dispatched status, counted by dispatch date, excluding VAT and shipping cost, excluding returns credited within the same month, compared against the average of the previous three months.

And then the part almost nobody asks for, which is the only serious acceptance test a dashboard has: the control month. Pick an already closed month for which a number exists that someone would defend in writing — the one that went into the financial statements, the one reported to the bank, the one the accountant signed — and ask for the dashboard to reproduce it before calling it delivered, with a tolerance stated in the proposal: less than 0.5 percent difference in invoicing and less than 2 percent in units, for example. If it comes out 6 percent off, the problem is not cosmetic: there are records being counted twice, or sales that did not match and disappeared from the total. A provider who accepts that clause without arguing is one who has been through it before.

If you can write the four-element line for all your metrics and you already have the control month picked, the project is short. If you cannot manage it for more than half of them, add those 10 to 30 hours and two or three weeks of calendar time that do not depend on the provider but on your people's schedules. And keep the list short: a dashboard that actually gets looked at has between five and eight numbers on the main screen, and every extra metric gets charged twice, when it is built and every time someone changes their mind about what it means.

The quote request that makes proposals comparable

With the three answers written down, send this exactly as it is to each provider:

Metrics I need to see, with the one-line definition of each: [list].

Where each one comes from: [system by system].

To cross [system A] with [system B] I have this field in common: [field]. For [system C] I have none: it is about [N] records to match by judgment.

Refresh needed: [daily before 9 / weekly on Mondays / monthly], because with that data I decide [concrete decision]. If the refresh fails, I want an alert sent to [email or chat] the same day.

Historical series from [date]. In [month] we changed [criterion] and it has to be marked on the charts.

Control month for accepting the dashboard: [closed month], against the number from [official source], with a tolerance of [X percent].

I need the quote split into four lines: matching and preparing the data, agreeing and documenting the definitions, building the dashboard, and monthly retainer with the detail of what it includes. Also tell me how many hours of my team you are going to need and what for.

How to read the data preparation line

The last two lines of the request are the ones that do the work, and this is how you read them.

If your case is matching by judgment, preparation has to be the biggest of the three setup lines. If you are quoted USD 3,000 and that line says USD 200, it is not a bargain: it means they plan to solve it by hand every month, with someone pasting into a spreadsheet, and that cost comes back all the same, disguised as a retainer or as a dashboard that goes stale in March.

The reverse applies too. If all your numbers come out of a single system with clean codes and preparation takes half the budget, ask them to break it down into tasks with hours. It may be legitimate — old history, changes of criteria, a migration in between — or it may be filler, and the breakdown clears that up in one line.

And ask for your team's hours in writing. Access, definitions and validation of the control month you are going to put in anyway: that is between 10 and 25 hours of your own people in a small project, and it is the only thing you cannot outsource.

Where the hours of getting data in order go

This breakdown deliberately carries no prices: it is there to compare proposals that do carry them, line against line.

WorkWhat triggers itTypical hoursWhat you ask to be itemized
Access and repeatable extractionA system with no API, or a user the software vendor has to create4-15 hWho creates each user and on what date it is ready
Mapping tableTwo catalogs with no code in common10-30 h the first timeWho maintains it afterwards and what the dashboard does with the ones that do not match
Definitions sign-off documentTwo departments answer with different numbers10-30 hHow many meetings it includes and who signs off each metric
History and changes of criteriaYou want more than a year of series, or you migrated systems in between6-20 hFrom what date and which steps stay marked
Building the dashboardNumber of screens and of views per user8-20 hThe list of screens, number by number
Unattended refresh and failure alertThe dashboard has to be up to date without anyone pressing anything6-15 hWhere the alert lands and how quickly it is answered
Control month and validationAlways4-10 hThe accepted tolerance, written into the proposal

These are typical ranges for this kind of implementation, not a price list. In a single-source project with the definitions already written, three of these seven rows are worth zero, and that is why the same software can cost USD 500. What does work as a signal is the other way around: if an expensive proposal touches none of these rows and only lists charts, it is not a quote yet.

When a dashboard is not worth it for you yet, and what the three questions do not fix

The three questions are there to stop you comparing apples with oranges and to stop you overpaying. There are two things they do not do, and both are discovered after signing.

They do not tell you whether the data underneath is reliable. A dashboard cleans nothing: it publishes faster what you already have. If every salesperson enters the customer name however they feel like, you will see three customers where there is one, now on a big screen with the company logo on top. Matching brings together what looks alike; it does not fix what was entered wrong at the source.

They do not cover the moment it breaks, which is silent. A broken dashboard almost never shows an error: it shows a number. The one from the day before yesterday, or the one from half the sources while the other half stayed frozen. Nobody finds out until someone decides something with it, or until two people compare their screens and do not agree. That is why the first thing to demand is not a sophisticated alert: it is that the date and time of the latest data be written on every screen, in plain sight.

And before all of that there are three situations where a dashboard is simply the wrong answer, no matter how well it is priced. All three can be recognized without asking for a quote:

  • The decision is already being made, and made well. If the owner puts together the order to the supplier on Mondays looking at a spreadsheet and has got it right for five years, a dashboard will show them the same thing, prettier. It is justified when the decision is made late today, or when it has to be made by someone who has no access to the data.
  • Nobody signs off the definitions. If the four people in the example give different numbers and there is no one to pick one, the project is not ready. First the definitions sign-off document and the control month; then the dashboard, which also costs less with those two things settled.
  • What you need is to find out, not to look. If, filtering your list with question 2, half of them are things you want to know at the moment they happen — a customer with debt asking for a shipment, a product that hit zero, a sale above a certain amount — those are alerts: they cost a fraction and do not depend on anyone opening anything.

Write to us at info@striqtech.com with the four things that come out of this article: your list of metrics with the one-line definition, which system each one comes from, which field crosses them and what your control month would be. We will send back the line-by-line breakdown — how many hours go into matching data, how many into agreeing definitions and how many into drawing — even if you do not hire us afterwards, because with that you can read any other quote.

If your data lives in spreadsheets today, what can be automated when you run everything in Excel starts with the four columns that make a spreadsheet crossable. If you are an agency and the dashboard is for your clients, the prior decision comes down to a division and it is in white label reporting: build it in-house or hire it out. And what to ask an automation provider before signing puts together the clauses that go into the contract.

Frequently asked questions

How much does a Looker Studio or Metabase license cost?

Looker Studio does not charge per dashboard or per user in its standard version: you get in with the Google account you already use. Metabase is open source and has no license cost if it runs on your own server; the version they manage themselves starts at around USD 85 per month for a small team, and that number is worth checking on the day you look at it, because it changes often. The only case where the tool does create an unavoidable monthly expense is when your systems stop being able to handle the dashboard querying them live and you need a database of your own in between: that is where USD 15 to USD 60 a month of managed database shows up. The difference between a USD 600 quote and a USD 4,000 one is never in the license.

Am I better off building the dashboard myself instead of hiring someone?

Try it before you decide: build the single-source dashboard yourself, using the source you already have cleanest, and publish it. If a week later you are still opening it, you gained an afternoon. After that you will hit two concrete walls, and neither one is solved with more hours of Looker Studio. The first is the day you have to bring two systems together and discover that neither of them identifies products the same way. The second is the Monday when the dashboard shows Friday's numbers because the refresh failed on Saturday and nobody noticed. Everything that comes before those two walls you do yourself; everything that comes after is a project.

If the license is free, what is the monthly retainer for?

For watching that the refresh actually ran and fixing it when it breaks, which in a dashboard is a silent failure: it keeps showing a number, only an old one. It also covers changes on your systems' side, like a new column in the management system export or a renamed field in the sales channel, which happen several times a year, and maintenance of the mapping table every time a new product comes in. Before signing a retainer, ask for two concrete things: that the date and time of the latest data be written on every screen of the dashboard, and that the failure alert reach someone at your company, not just the provider.

How long does it take to build a BI dashboard?

One to two weeks if everything comes out of a single, already tidy source, and four to eight when systems have to be matched. But the timeline is set by two dates of yours, not by the provider. The first is when access is granted: in many management systems you have to request the API user from whoever sold you the software, and that usually takes three to ten business days. The second is your accounting close, because a dashboard can only be called good when it reproduces an already closed month against a number someone would defend in writing. If you start on the 20th, final validation waits for the next close. Ask for both dates to appear in the schedule.

What is a mapping table and why is it quoted separately?

It is the list that declares that product ABC-12 in your management system, listing MLA-whatever on Mercado Libre (the largest marketplace in Latin America) and the “Blue 20 L drum” in the cost spreadsheet are the same thing. Without it there is no margin per product and no sales by category: there are three tables that do not talk to each other. It is quoted separately because it is manual work with an end that is hard to estimate (automatic matching solves part of it and a person looks at the rest, case by case) and because it does not finish on delivery day: every new product adds a row. When you ask for it, ask who maintains it afterwards and what the dashboard does with the records that do not match.

Why do I get quoted more if my data is in Excel and not in a database?

Because an Excel file does not read itself. Every manual export is a step someone has to repeat every week, and if that person goes on vacation the dashboard freezes. On top of that, spreadsheets change shape without warning: someone adds a column, changes the order or writes a total at the bottom, and whatever was built on top of it stops working. A source with an API costs more to connect the first time and quite a bit less to maintain.

Did this content help?

Implement this in your business in 72 hours

Let's talk for 15 minutes. No cost, no commitment. I'll audit one process and show you the projected ROI.

Let's talk on WhatsApp