Why your internal tools probably need a custom dashboard, not another Notion template
There's a quiet epidemic in operations teams. It looks like a Notion workspace with 47 pages, five "master databases," and a sidebar of tags nobody can quite remember the purpose of. The symptoms are subtle at first: someone asks where the real numbers live, and the answer is "in the spreadsheet that Sarah maintains, but the Notion version is the source of truth, but also the Airtable has the most recent totals." If you've seen it, you know.
This post is about when a custom dashboard is the right answer — and, just as importantly, when it isn't. We build these at rootsbit, and our services page has the details, but I want to talk about the decision itself first because the decision matters more than the build.
When a Notion template is the right answer
Let me start with the honest version, because I'm tired of reading posts that treat Notion as the enemy. Notion (and Airtable, Coda, Smartsheet, and the rest) are genuinely good tools for three things:
- Early-stage discovery. When you don't yet know what your process is, a flexible document tool lets you figure it out. The cost of changing the shape of your data is zero.
- Cross-functional documentation. Read-heavy surfaces — policy docs, runbooks, meeting notes — belong in a document tool, not a database.
- Small teams, low frequency. If five people use the tool once a week and the data volume is in the low hundreds of rows, building custom software is overkill. The maintenance cost of custom software is real and recurring.
The mistake is staying in the template-when-you-should-have-built stage for a year longer than you should have. Here's how to tell.
Five signals you've outgrown the template
You probably need a custom dashboard if three or more of these are true:
- The same report takes two people a full day to produce every month. This is the most reliable signal. If reconciliation has a recurring named ritual, your tool is failing you.
- You have more than one "source of truth" for the same metric. When finance asks "how many active customers do we have," the answer depends on which screen the person is looking at. This is not a discipline problem; it is a data model problem.
- Permissions need to be enforced, not asked nicely for. Notion's permission model is read/write at the page level. If you need "the salesperson can see their own accounts but not another salesperson's, and finance can see all," you have outgrown it.
- You are using a spreadsheet as a job queue. Once rows start moving between sheets through Zapier or Make or a scheduled script, you have built a distributed system in the worst possible substrate.
- You can't answer a founder's question in under an hour. "Who churned last month and why?" should be a saved query, not an archaeology project.
If you want a concrete version of this transition, our case study on Northwind Cooperative describes what it looked like when a 40-person co-op went from six spreadsheets to a single dashboard. The reconciliation ritual went from two days to 45 minutes. The dashboard didn't solve the problem — it let the team see the problem clearly enough to solve it.
When to build, when to buy
Once you've decided the template era is over, the next fork is build vs. buy. The honest version:
Buy when the workflow is standard. If what you need is a CRM, an ATS, a project tracker, a help desk, or a billing system, buy. The vendors in these categories have spent a decade on the edge cases you will hit in month four. I have seen teams spend $80k building a worse version of Linear. Do not do this.
Build when the workflow is yours. Internal tools that are worth building fall into a specific shape: they combine data from 2–4 sources that don't naturally talk to each other (your Postgres, Stripe, a third-party API, and a manual CSV), they're used daily by a specific small group of operators, and the shape of the question changes every quarter. The shelf products can't follow that shape. A custom dashboard can.
The cliché in this space is "build vs. buy is a false binary." It is. The actual answer is usually "buy the commodity parts, build the connective tissue." A good custom dashboard is often 60% off-the-shelf charting (Visx, Recharts, or Tremor), 30% glue (a typed data layer that pulls from your sources), and 10% bespoke (the specific UI your operators need).
What a good internal dashboard actually looks like
I have a small list of things that separate a dashboard operators use from a dashboard operators resent. None of them are technically difficult. All of them are routinely skipped.
It opens to the answer, not to a filter screen
The default view of your dashboard should be the most-asked question on the most-common role. For an ops dashboard, that's usually "what needs my attention today." For a finance dashboard, it's "where are we against forecast this month." If a user has to click three times to see the thing they came for, they'll go back to the spreadsheet.
It exports in the formatauditors actually want
PDF exports that match the format your auditor already expected is worth more than any chart. This is unglamorous and I will defend it forever. We wrote about this in the case study on Northwind — the dashboard didn't fully replace the spreadsheets until the finance lead could hand the auditor a PDF that looked like the spreadsheet they'd been using for years.
It loads in under a second on cellular
If your dashboard takes four seconds to render on a phone on 4G, the field team will stop using it. This is a performance budget, not a feature. The web.dev performance scoring methodology is a useful reference if your team pushes back on this — anything above LCP 2.5s on mobile is broken.
It has a "what changed since I last looked" surface
The single highest-leverage UI element in an internal tool is a smart "what's new" list. It turns a dashboard from a passive reference into a place an operator starts their day. Build it once and watch the usage data — it is always the most-clicked thing on the page.
Error states are honest
When a data source fails, the dashboard should say so. Most off-the-shelf BI tools show a partial view that looks complete. That's how someone makes a decision on stale data. A red banner saying "Stripe sync failed 12 minutes ago — last successful sync 2h ago" is worth more than any chart.
The actual decision
If I had to compress all of this into one paragraph: if the same person produces the same report every week, and the report matters to a decision, and the data comes from more than two sources, you probably need a custom dashboard — and building it will return its cost inside a quarter. If the report is produced occasionally, by different people, from one source, keep your Notion template.
We've written about the broader process we use for these engagements — the build itself is the easy part. The hard part is deciding you need it.
---
If you're unsure, reach out. The first conversation is free and usually clarifies whether you need a build, a buy, or just a better template. We'll tell you which one.