Direct answer
Embedded BI is right when the user is an analyst who already expects filters, exports, and last week vs last year. A custom dashboard is right when a specific role must see one number and do one thing — and that number cannot leak across tenants.
Core Web Vitals still apply to the shell. A two-megabyte chart library on the first paint is a product choice, not a given.
Dashboards without a job
Most first dashboards fail because they display every column the warehouse has. Usability 101: pick the decision, then the metric, then the chart.
If the user cannot say what they will do differently after seeing the number, cut the widget.
A practical sequence
Keep v1 to one role and one decision.
- Name the decision the dashboard is supposed to change
- Scope the metric to the user’s workspace
- Show empty, loading, and stale timestamps
- Lazy-load heavy charts below the first paint
- Export as CSV before you build a pixel-perfect PNG
Permissions are not a colour
A ‘hide this chart’ flag in the UI is not authorization. The query must be tenant-scoped. OWASP’s authorization notes apply to read paths, not only POSTs.
What to send if you want a senior review
Share the decision, the role, and whether analysts already have a BI seat. Related work at Kiwi: SaaS MVP design and development.
Frequently asked questions
Can we start with a spreadsheet and replace it later?
Yes, if the spreadsheet is not shared beyond the people who should see it. Replace it when you need tenant isolation or an audit trail.
Do custom dashboards rank in Google?
They should not. App routes belong behind login with noindex. Rank the public explanation of the product, not the signed-in chart.
Will a custom dashboard improve conversion?
It can improve an operator or customer job. It is not a ranking or lead promise. Measure the job, not a vanity bounce rate.
Sources
Figures cited above are drawn from the linked publications and are the responsibility of their sources; we date and scope them rather than presenting them as universal guarantees.