Research Dashboards: When to Build, When to Avoid, and What Funders Expect

The dashboard exists. The PI demoed it at the consortium meeting. The funder noted it positively in the mid-term review. Six months later, nobody on the team has opened it. The quarterly numbers it was supposed to update are stale. When someone external clicks the link, half the charts fail to render because the upstream data source changed format.

Most research dashboards end this way. Built with good intentions, used briefly, abandoned quietly. The funder never asks because they don't know it's gone.

Before building a dashboard, the right question isn't "what should it show?" — it's "should this exist as a dashboard at all?" This post is a practical decision framework for research dashboard development in grant-funded contexts.

Why research dashboards fail

Almost every abandoned research dashboard fails for one of four reasons.

1. The data pipeline behind it isn't maintained

A dashboard is a window into a dataset. If the dataset stops being updated — because the postdoc graduates, the analysis script breaks, or the source system changes — the dashboard freezes. A frozen dashboard is worse than no dashboard, because it shows stale numbers as if they were current.

2. The audience never actually used it

The dashboard was built for a hypothetical viewer. The PI wanted "stakeholders to be able to explore the data". In practice, stakeholders read PDFs, not interactive dashboards. The dashboard's interactive features go unused; its static screenshots become the actual deliverable.

3. Maintenance lives with one person

The PhD student built it. The PhD student understood the data wrangling, the chart logic, and the deployment. The PhD student is now elsewhere. Maintenance requires reading 800 lines of dashboard code that nobody left documentation for.

4. The dashboard answers questions nobody is asking

The proposal said the project would produce a dashboard, so a dashboard was produced. But the actual research questions were better answered by a single annual report with five fixed figures. The dashboard's flexibility — the thing that justified building it — wasn't the thing the audience needed.

If a dashboard is going to fail for one of these reasons, building it is wasted time. The honest test is: which of these four am I most worried about?

When a dashboard IS the right answer

Three patterns make a research dashboard worth building.

Pattern A: The audience is genuinely doing data exploration

Programme officers at a foundation reviewing 12 grantees' progress monthly. Multi-site PIs comparing recruitment trajectories across countries weekly. A scientific advisory board reviewing intermediate findings before each meeting. These audiences open dashboards because their work involves comparing slices of data they didn't know they'd need to compare.

If your audience genuinely does exploration, a dashboard adds value. If they read the same five charts every time, a report is better.

Pattern B: The data is genuinely refreshing

Cohort recruitment progress. Active patient enrolment. Regional engagement metrics in a multi-site programme. Trial dropout rates. These benefit from being current — last month's snapshot is materially less useful than today's.

If the underlying data refreshes meaningfully (weekly or faster), a dashboard's "always-current" property is doing real work. If the data refreshes annually, you have a report, not a dashboard.

Pattern C: The dashboard is the operational interface, not just a viewer

Logistics tracking for a multi-site study. Field-data quality monitoring. Active workflow status for a research operation. These are tools the team uses to do the work, not tools to communicate findings.

This is the strongest case. The dashboard isn't a deliverable; it's infrastructure. Operational dashboards earn their maintenance because the team using them notices when they break.

When a dashboard ISN'T the right answer

Four patterns suggest a dashboard is the wrong choice — and an alternative is cheaper, more durable, and more useful.

Anti-pattern 1: The audience is a funder reading once at review

If the dashboard is for a funder who will look at it twice — at mid-term and final review — build a static report instead. A PDF with 8 well-chosen figures, a 3-page narrative, and a methodological appendix outperforms an interactive dashboard for this use case. It's also archive-stable.

Anti-pattern 2: The data is intermittent

If the data underlying the dashboard updates 2–4 times a year — at field-data collection waves, at annual cohort cuts — a dashboard's interactivity is unused most of the time. A report regenerated quarterly serves the same purpose with less overhead.

Anti-pattern 3: The team has no maintenance plan

A dashboard built with no plan for who maintains it after the original developer leaves is a liability. If the team can't articulate who is on the hook for the next two years of maintenance, build a one-shot artefact instead. Academic research software without a maintenance plan dies inside 18 months.

Anti-pattern 4: The questions the dashboard answers are well-defined

If you can write down the 6 questions the audience will ask, the answer to each is a fixed chart, and those charts will be the same in 12 months — that's a report. The dashboard's flexibility isn't worth the build cost or maintenance overhead.

What funders actually expect

Most evaluators don't know what they want from a dashboard. They know what they want from a research project: clear evidence of impact, defensible methodology, transparent processes. A dashboard either delivers those signals or it doesn't.

Specifically, funders want to see:

• A current state of the project: where you are vs. where you committed to be
• Comparable cross-site or cross-cohort metrics: when relevant
• Provenance and update cadence: when was this last refreshed, against what data
• Methodological transparency: how each metric is calculated
• Long-term accessibility: a stable URL that will still work in 3 years

The biggest mismatch we see: teams build dashboards optimised for stakeholder exploration when the funder needs evidence of grant compliance. The two require different surfaces. If the dashboard is genuinely for the funder, build the simpler thing — they don't need filters, just trust.

Build choices: configurable platform vs custom build

When the answer is genuinely "build a dashboard", the next question is which path.

Configurable platforms (Path A)

Looker Studio (free, Google-account auth, weak custom logic), Metabase (open-source, self-hosted or cloud, decent SQL UX), Grafana (open-source, time-series strong, weaker for general data), Apache Superset (open-source, more complex setup, powerful when set up).

Pick when: standard chart types serve your needs, your data lives in a queryable database, you don't need bespoke UX. Time-to-first-version: 1–2 weeks. Maintenance: low if your data infrastructure stays stable.

Custom build (Path B)

Next.js / React with a charting library (Recharts, Plotly.js, Observable Plot, D3 for the ambitious), authenticated API backend, deployed to a managed service.

Pick when: the dashboard is operationally critical, the UX needs are specific, the audience is large enough that polish matters, integration with bespoke research-data systems is required. Time-to-first-version: 4–8 weeks. Maintenance: real, ongoing — needs documented runbooks and someone responsible.

The honest math for most grant-funded research projects: path A or no dashboard at all. Path B is right when the dashboard is the deliverable, not just a way to communicate the deliverable.

A 30-minute decision exercise

Block 30 minutes. Answer:

1. Who is the actual audience? Names, roles, count. If you can't list them, that's the answer.
2. How often will they open it? Honest estimate. Once a quarter, weekly, daily?
3. Does the underlying data refresh meaningfully between their visits? Yes / no.
4. Who maintains this in 18 months? Specific person, with capacity.
5. What 5 fixed charts would answer 80% of what the audience needs? Listing these is usually enough — and once listed, often a report is enough too.
6. If the dashboard didn't exist, what would the audience use instead? If the answer is "the same PDF report we'd send anyway", the dashboard isn't adding value.

If the answers are crisp and a dashboard still feels like the right choice, build it. If they're fuzzy, build a static report instead.

Where Pragma fits

We build research dashboards when the brief justifies them — operational interfaces, programme-monitoring tools for foundations, multi-site recruitment trackers. We also tell teams when not to build one. Our Research Tool MVP engagement scopes the build-vs-avoid decision in the first week and ships the right artefact in 4–10 weeks.

If you have a dashboard line item in the work plan and you're not sure whether to build it, request a scope review. The 30-minute decision exercise above is one we run with you on the call.

Three things to do this week

1. Run the 30-minute decision exercise above for the dashboard you're considering. Be honest on item 4.
2. List the 5 charts that would answer 80% of audience needs. If you can write them down, your honest answer is probably "report, not dashboard".
3. If the answer is genuinely "build", request a scope review. We'll confirm whether path A (configure) or path B (custom) is right and what the maintenance plan needs to be.

The most expensive failure in research data visualization is the abandoned dashboard. The second most expensive is the dashboard nobody told you was unnecessary. Both are avoidable.