Custom dashboard, Power BI or Retool? An honest decision guide
Updated · 9 min read
The short answer
If your users are analysts and managers inside your organisation, and the job is reporting on data you already hold, start with Power BI. If your team needs internal screens that read and write data (approve this, edit that, trigger a job), start with Retool. Both are mature, cheaper to start than custom code, and good enough for most internal work.
Build a custom dashboard when the dashboard is part of your product: customers log in to it, it carries your brand, it needs live or sub-minute data, it has unusual interaction, or per-seat licences start to cost more than owning the code. The honest test is who looks at it and how much it matters to your revenue.
Three tools for three different jobs
People compare these options as if they were the same thing at different prices. They are not. Power BI is a business intelligence tool: it is built to model data, calculate measures and publish reports that people read. Retool is an internal tool builder: it is built to put forms, tables and buttons on top of your databases and APIs so that staff can act on data, not only look at it. A custom dashboard is software you own: a web application, written in code, that shows exactly what you design and behaves exactly as you specify.
Most bad decisions in this area come from using one of these for the other’s job. Teams stretch Power BI into a data entry tool, push Retool into a customer-facing portal, or commission custom code for a weekly management report that a spreadsheet person could have built in Power BI in a fortnight. Start by naming the job, then the tool usually picks itself.
- Reading and analysing data, mostly internal audience: Power BI (or a similar BI tool).
- Acting on data, internal operations staff: Retool (or a similar internal tool builder).
- A product surface for customers, partners or the public, or anything with demanding performance or design needs: custom.
Side by side
The table below compares the three on the questions that usually decide the matter. Pricing is described at the level of the model rather than exact figures, because list prices change and vary by region. Check the vendors’ pricing pages before you budget.
| Question | Power BI | Retool | Custom dashboard |
|---|---|---|---|
| Best at | Reporting, data modelling, self-service analysis | Internal tools that read and write data | Customer-facing or product-grade dashboards |
| Pricing model (October 2026) | Per user (Pro, Premium Per User) or Fabric capacity; viewers need a licence unless content sits on F64 or larger capacity or is embedded | Per builder plus per internal user; external users priced separately on Business; Enterprise for SSO and unlimited users | Build cost up front, then hosting and maintenance; no per-seat fee |
| Time to first useful version | Days to weeks if the data is clean | Days to weeks | Weeks to months |
| Data freshness | Up to 8 scheduled refreshes a day on shared capacity, 48 on Premium or Fabric; DirectQuery for live sources | Queries run when the user loads or acts, so data is as fresh as the source | Whatever you design, including streaming and real time |
| Look and feel | Power BI visuals and themes; recognisably Power BI | Retool components; custom branding on higher tiers | Anything you can design |
| Who maintains it | Analysts with DAX and modelling skills | Developers or technical operations staff | Software engineers |
| Main risk | Model sprawl and licence creep | Platform lock-in, per-user cost at scale | Up-front cost and the need for ongoing engineering |
When Power BI is the right answer
Choose Power BI when your organisation already runs on Microsoft 365, your audience is internal, and the work is reporting: sales by region, cash position, pipeline, operational KPIs. At the time of writing, Pro is included in Microsoft 365 E5, which means many organisations already own the licences without realising it. The Free tier lets one person build, but sharing reports needs Pro, Premium Per User or capacity.
Power BI is also the right answer when your analysts want to explore. A well-built semantic model lets finance or operations people slice data themselves without asking engineering for a new screen. That is something custom dashboards rarely match without a lot of extra work.
Know the limits before you commit. Semantic models on shared capacity are limited to eight scheduled refreshes a day, and a refresh must complete within two hours. On Premium, Premium Per User or Fabric capacity you can schedule up to 48. If your source schema changes, scheduled refresh fails until someone fixes the model in Power BI Desktop and republishes. And Power BI pauses scheduled refresh on a model that nobody has viewed for two months, which is a sensible default that still surprises people.
- Good fit: management reporting, finance and operations KPIs, analysts who want to self-serve.
- Poor fit: data entry and workflows, customer-facing products that must look like your brand, sub-minute data.
- Watch for: every viewer needing a paid licence unless you move to F64 or larger capacity, or to Power BI Embedded.
When Retool is the right answer
Choose Retool when your operations team needs screens to do things: review applications, correct records, issue refunds, trigger a workflow, look up a customer across three systems. Building that kind of tool from scratch is slow and dull, and Retool gives you tables, forms, permissions and connectors to most databases and APIs out of the box. A developer can usually produce a working internal tool in days.
At the time of writing Retool prices by builder (anyone who built or edited an app in the billing cycle) and by internal user (everyone else), with external users such as partners or clients priced separately on the Business tier. SSO, SCIM and Git source control sit on Enterprise. Self-hosting is available, but user caps and feature availability differ by tier, so confirm what you need before planning a self-hosted deployment.
The trade-off is lock-in. Your apps are built inside Retool and run on Retool. If you later decide to move, you rebuild. For an internal back-office tool that is often an acceptable price for speed. For the core of your product, it usually is not.
- Good fit: admin panels, back-office operations, approval queues, support tooling.
- Poor fit: public-facing products, highly custom interaction, very large user counts where per-user pricing compounds.
- Watch for: business logic scattered across many apps with no tests or code review.
When a custom dashboard is worth it
A custom dashboard is worth paying for in a narrower set of cases than most vendors admit. The strongest case is when the dashboard is part of what you sell. If clients log in to see their portfolio, their loan book or their usage, the dashboard is a product surface. It needs your brand, your permissions model, careful performance and the freedom to change it every sprint. BI tools and internal tool builders are not designed for that, and embedding them often costs more and looks worse than building.
The second case is demanding data. Trading screens, live operations rooms and risk monitors need data that updates in seconds, not in scheduled refresh slots, and interactions that a generic visual library does not offer. Our team has shipped trading desk, lending and investing software in regulated financial services, and in that world the screen is often where the decision gets made, so it is built like a product.
The third case is cost at scale. Per-seat licences are cheap for twenty people and expensive for two thousand. Once you are paying a large recurring bill to show a fixed set of views to many users, owning the code can be cheaper over a few years. Do that sum honestly, including hosting, maintenance and the engineers who will look after it.
- Good fit: client portals, product analytics inside your app, real-time operations, regulated environments with strict audit needs.
- Poor fit: internal reports for a small team, exploratory analysis, anything that changes weekly at the request of analysts.
Failure modes to avoid
Each route has a typical way of going wrong. Knowing them in advance is cheaper than discovering them in production.
- Power BI: dozens of near-duplicate semantic models with conflicting definitions of the same metric. Fix it with a small set of certified models and an owner for each.
- Power BI: a report that worked in testing slows down as data grows, because the model was never designed. Treat modelling as engineering work.
- Retool: important business rules living inside app queries that nobody reviews. Put the rules in an API or database layer and keep Retool as the interface.
- Retool: an internal tool quietly becomes customer-facing, and per-user costs and branding limits arrive together.
- Custom: a team commissions a build, ships it, and has nobody to maintain it. Budget for ongoing work from day one.
- Custom: rebuilding features a BI tool would give you for free, such as export, filtering and drill-down, at great expense.
A five-question decision checklist
Answer these in order. The first clear answer usually settles it.
If you land on custom, it is still worth prototyping in Power BI or Retool first. A working prototype tells you which views people actually use, and that makes the custom build smaller and more accurate. If you land on Power BI or Retool, plan for the day you might outgrow it: keep your data and business rules in systems you control, so that the interface can be replaced without starting again.
- Will customers or partners log in to see it? If yes, lean custom, or Power BI Embedded if branding and interaction needs are modest.
- Do users need to change data, not only read it? If yes and they are staff, lean Retool.
- Do you need data fresher than a few times an hour? If yes, lean custom or a live connection, and test it early.
- Do you have analysts who will own and extend reports? If yes, lean Power BI.
- Will per-user licences for the full audience exceed the cost of building and maintaining your own over three years? If yes, cost out a custom build properly.
Questions
- Is a custom dashboard always more expensive than Power BI?
- Up front, almost always. Over several years it depends on audience size. Per-user licences scale with headcount, while a custom build is mostly a fixed cost plus maintenance. For a small internal audience Power BI is nearly always cheaper. For thousands of external users the sums can reverse.
- Can Power BI be used for customer-facing dashboards?
- Yes, through Power BI Embedded. In the App Owns Data model your customers do not need their own Power BI licences, and you pay for capacity instead. It works well when Power BI visuals and interaction are acceptable to your customers. It is less suitable when the dashboard needs to feel like a native part of your product.
- Can Retool replace a custom admin panel?
- For most internal admin panels, yes, and it will usually be faster to build. Keep your business rules in your own API or database so that Retool stays a replaceable interface rather than the place your logic lives.
- Should we prototype in Power BI or Retool before building custom?
- Usually, yes. A prototype in an off-the-shelf tool shows which views and actions people actually use. That evidence makes a custom build smaller, faster and more likely to be adopted.
- Does Wideline build dashboards in Power BI or Retool?
- We build custom dashboards and the data and integration work behind them. If your need is well served by Power BI or Retool, we will tell you so, and we can help you get the data ready for them.