Before you build a dashboard
Most people think of Power BI first, and for good reason. But "dashboard" covers two different jobs that are modelled differently underneath, and knowing which one you need makes the choice simple.
Ask a room of business owners how they would get a dashboard and most will say Power BI. That is a sensible first answer. It is the best known tool in the category, it is a genuinely strong product, and if your business already runs on Microsoft 365 it is effectively sitting there waiting for you.
The reason it is worth a second thought is not that Power BI is the wrong tool. It is that the word "dashboard" covers two fairly different jobs, and the two are built differently underneath. Knowing which one you are asking for makes the decision straightforward.
Two different jobs, one word
The first job is exploring. Someone needs to interrogate the data: filter it, break it down by region or product, and answer a question nobody thought of when the report was built. That is analysis, and it is skilled work.
The second job is seeing. There are ten numbers that tell you whether the week is going well, everyone broadly agrees what they are, and people need to glance at them without thinking. That is an operational view.
Both are legitimately called dashboards. The trouble starts when a business buys for one job and actually needed the other.
The real difference is in the modelling
Power BI is built around a data model. You bring your data in, describe how the tables relate to each other, and define your measures once so they are reused everywhere. That modelling layer is the product's great strength: you define what "gross margin" means a single time, and every report that uses it agrees. It is also what makes the exploring job possible, because a well-built model can answer questions nobody has asked yet.
A custom dashboard usually skips that layer. It asks your source systems directly for the specific figures the page shows, and works them out in code. There is no general-purpose model to design or maintain, which is lighter when the questions are settled, and limiting when they are not.
A model is worth building when you do not yet know every question. It is overhead when you do.
| Power BI | A custom dashboard | |
|---|---|---|
| Built to | Explore and report on data | Show a known set of numbers |
| Data modelling | A semantic model designed up front: tables, relationships, reusable measures | Queries written for the specific figures on the page |
| New questions | Slice and pivot on the spot | Needs a change made |
| Who changes it | An analyst, without a developer | A developer |
| Where it lives | The Power BI service and app | Any screen, or inside a system you already use |
| Access | Licensed per person who views it | You control access; no per-person licence |
| Suits | Finance and analysis teams | Whole-team operational views |
Where the money actually goes
Whichever you choose, most of the cost is the plumbing. Somebody has to get the data out of your systems reliably, reconcile it so the figures agree, and keep it running when a supplier changes their software. That work is the same job either way, so it is a poor basis for choosing between them.
Where they differ is how the cost scales afterwards. Power BI is licensed per person, so it tracks the number of people looking. A custom build is mostly a one-off cost plus hosting. Neither is universally cheaper: a handful of people asking a lot of questions favours Power BI comfortably, while a lot of people glancing at settled numbers favours a custom view.
When Power BI is the right call
Take Power BI if your team needs to ask new questions regularly, if you have someone who enjoys working with data, if different people need to see different slices of it, or if you are already invested in Microsoft 365. There is another advantage worth naming: it is a mainstream skill. You can hire for it, train for it, and get help without depending on whoever built the thing.
When a custom view fits better
A custom dashboard fits when the numbers are few and settled, when a lot of people should see them, when it needs to live inside a system your team already has open rather than in a separate app they must remember to check, or when the calculation is specific enough that you would spend the project bending a general tool into shape.
It is also frequently not either/or. Plenty of businesses run Power BI for analysis and a small operational view on the workshop or office screen, and the two are not competing. They are doing different jobs.
The short version
Thinking of Power BI first is a good instinct, not a mistake. The useful question underneath it is whether you need to explore your numbers or simply see them. If you need to explore, you want a model, and Power BI is built for exactly that. If you only need to see, something lighter may do the job for less. Either way, budget for the plumbing, because that is what decides whether anyone trusts the numbers on the screen.
Not sure whether your process passes?
Tell us what it is and we will walk through the questions with you. No charge, no obligation.
Before you automate anything
Four questions worth answering about a process before you spend a dollar automating it. Most of the automation projects we are asked to rescue skipped at least two of them.
Spreadsheets are not the problem
For a lot of what SMEs do, a good spreadsheet is the right tool. This is how to tell when yours has quietly become a liability.