When a company wants a dashboard, the question almost always arrives in the same form: Power BI or Looker Studio? It is a fair question, but it comes too early. Before choosing a tool it helps to know how many sources you have, how reliable the data is, who will use the views and who will maintain them. This guide does not compare products. It gives you a matrix for deciding, a calculation so you don't underestimate the hidden work, five questions to ask yourself and the signs that the problem is the data, not the tool.
The tool is a project choice, not the starting point
A dashboard tool is a container. What decides whether the result works is what you put in it: sources, definitions, views. That is why the tool should be chosen after those things are clear, not before. Teams that start from the tool end up building fast and fixing later.
The hidden work shows up in a calculation. An example with made-up numbers. An ecommerce team decides to build its own dashboard with a tool you configure yourself. The build takes 5 weeks at 8 hours a week: 40 hours. Then upkeep: checking that refreshes ran, fixing connections that break, reconciling numbers with the management system and explaining why two reports don't match. Say 3 hours a week for 50 weeks: 150 hours. First-year total: 190 hours. At an internal cost of €40 an hour, that is €7,600 of people's time that nobody budgeted.
This is not an argument against configurable tools. If upkeep were 1 hour a week, the sum would be 40 + 50 = 90 hours, or €3,600, and it could be an excellent choice. The point is that the real cost is time, and it should be estimated up front: how many hours, whose, and what does not get done in those hours.
A matrix for deciding
The table compares six aspects. For each one you see when a configurable tool is enough and when custom becomes the more sensible choice.
| Aspect | A configurable tool is enough when | Custom makes sense when |
|---|---|---|
| Number of sources | You have one or two sources with connections already available | There are many sources, some internal or without a ready-made connection |
| Data quality | Data is already clean and consistent across sources | There are mismatched codes, duplicates and manual fixes: a data model has to be built first |
| In-house skills | Someone has the time and the skill to build and maintain it | Nobody has the time, or the one person who can do it is a single point of failure |
| KPI definitions | They are simple and shared by everyone | They are complex, differ between departments and need to be fixed and documented |
| Views for different roles | One role reads the data, or several roles with similar views | Roles with different decisions, needing different levels of detail and access |
| Evolution | Your needs change little over time | New sources and new questions keep arriving, and the system has to grow with the company |
How to read it: if most rows fall in the middle column, start with a configurable tool and don't make life harder than it needs to be. If most fall in the right column, custom saves you work. If you are split, the useful question is which row weighs most in your company.
Custom has costs of its own, and they should be said out loud. It takes more decisions up front, a listening phase and a well-run handover, and for a simple need it is out of proportion.
Five questions to ask before deciding
Answer in writing, ideally with the people who will use the data. They are the starting template for any project.
- Who will read the view, and for which decision? If you can't answer, the problem comes before the dashboard.
- Which sources do the numbers come from, and who owns each one? List every source, spreadsheets included.
- Are the KPI definitions written down? What "sales" means, what gets subtracted, which period is used.
- Who will maintain the system in a year? A dashboard with no owner stops being updated.
- What happens when a source changes? A new channel, a replaced system, a renamed field: who notices, and who fixes it?
When the problem is the data, not the tool
Many teams switch tools hoping to fix a problem that lives elsewhere. These signs say to look at the data first.
| Sign | What it can mean | What to check |
|---|---|---|
| Two reports give different numbers for the same sale | Different definitions, or sources that are not aligned | Write down the definition and compare order lines one by one |
| Someone corrects the numbers by hand before every meeting | Rules that exist only in one person's head | List the corrections: each one is a missing rule |
| You can't link one source to another | There is no shared identifier, such as a matching product code | Check that every source uses the same code for the same item |
| Nobody trusts the dashboard | Past errors that were never explained | Pick one number and rebuild it from the source, in front of the skeptics |
| Data arrives incomplete or late | Irregular data capture | Check when and how each source arrives |
If you recognize yourself in this table, a new tool will bring the same problem in new clothes. It is better to fix the integration first, as the guide on what you need before building a dashboard explains.
How a custom project is set up
A custom project follows four phases. There is no standard duration: it depends on the case and is set after the assessment.
- Listening. You start from the people who use the data: which decisions they make, which questions they ask, what they cannot see today.
- Data. You look at the sources, their quality and the KPI definitions. You build the link between sources and a data model that the views rest on.
- Views. You build the dashboards by role, starting from the questions, and check them with the people who will use them.
- Handover. You deliver with documentation and make clear who maintains what, so the system does not depend on one person.
The tool is chosen along this path, when you know what it has to hold and who will use it. Sometimes the answer is a well-configured off-the-shelf tool, sometimes it is something else.
Where Opalca Lab fits
Opalca Lab offers custom consulting and development: data source integration, custom API connectors and databases, custom dashboards, data visualization and data modeling. There is no standard price list: each project is assessed on its own case. Among the cases: Turnover, an agency specializing in selling on Amazon, has custom Amazon reporting dashboards built with Opalca Lab. Fairflai, a multidisciplinary team of artificial intelligence experts, works with the AI Readiness Assessment framework and has custom reporting and a tailored roadmap built with Opalca Lab.
Weighing up how to set up your reporting? Tell us about your situation, or contact us.
Keep reading
- Data integration: what you need before building a dashboard
- Data visualization: from table to decision
Frequently asked questions
Power BI or Looker Studio: which one should I choose?
There is no answer that fits everyone. It depends on your sources, skills and the roles that will read the data. Answer the five questions in this guide first: often the choice of tool becomes a detail.
When is a configurable tool enough?
When you have a few sources that are already clean, simple definitions, a single role reading the data and someone with the time to maintain the system.
When does custom make sense?
When there are many sources, the data needs aligning, different roles need different views and the system has to evolve over time.
How do I estimate the cost of doing it myself?
Count the build hours and the weekly upkeep hours, multiply by your internal hourly cost and add what does not get done in that time. The calculation in this guide shows how.
How long does a custom project take?
There is no standard duration. It depends on the number of sources, the quality of the data and the views required, and it is set after assessing the case.