Build your own dashboard

An agent will often default to calling sources live on every page load, which is neither pull-on-a-schedule nor push, and tends to be the fragile worst of both. Make the choice explicit.

Your numbers live somewhere already: inside a payment tool like Stripe, inside your app’s own database, inside a spreadsheet you keep by hand. Each of those is a source. How you reach each one, and pull versus push, is covered just above in how the numbers get in. The decision here is the one people skip: how many sources does this really need, and how painful is the worst of them?

One source is a weekend. The honest difficulty of most dashboards is “I need three different places and they all speak differently,” and knowing that before you start is what keeps a quick win from turning into a slog.

Here is the decision most people do not realize they are making. Do you fetch the numbers fresh from the source every single time, or do you pull them once, keep a copy, and read from the copy? Keeping a copy is a cache, and for a dashboard it is almost always the right move: your page loads instantly, you stop hammering the source, and the dashboard still works for a minute if a source hiccups.

That copy has to live somewhere, which is its own small decision with real trade-offs. For a personal dashboard it is genuinely tiny: a flat file or an on-device database is plenty. You only need more the day the dashboard is shared and busy. That whole decision has its own page.

Now that you keep a copy, you have to decide how often to refresh it. The instinct is “live, always up to the second.” You rarely need that, and chasing it is where personal dashboards turn into a tangle. The simple pattern is polling: a small job wakes up on a schedule, pulls fresh numbers from each source into your local copy, and goes back to sleep. The dashboard just reads the copy. The schedule itself is usually a cron job.

The question that sets the whole design is not technical, it is about you: how stale is too stale? For most personal dashboards the true answer is “an hour old is completely fine,” and that answer lets you build the simplest possible version.

Decide how fresh you actually need the numbers to be. That one answer quietly determines how hard the whole thing is to build.

This is the fun part and the easiest to get wrong. You already saw the three shapes at the top of the page: the scoreboard, the charts, the list. Most good dashboards are a small mix of them, and the mistake is always more. An agent will happily give you twelve charts, and twelve charts is noise you will stop looking at inside a week. A dashboard earns its keep when it answers one question at a glance: is anything different, and do I need to act? That usually means a few big numbers, maybe one trend line, and almost nothing else.

The discipline is to pick the handful of numbers that would actually change a decision, and cut the rest, however interesting they look. A number you will never act on is decoration.

The moment you keep a copy of a number, that copy starts aging. The source has moved on; your dashboard has not caught up yet. This is called staleness, and it is not a bug to eliminate, it is a dial to set. A dashboard refreshed every hour is up to an hour stale, and for almost everything personal that is completely fine. Trying to drive staleness to zero is exactly the over-engineering that turns a weekend build into a month.

The one place it bites: showing a stale number next to a timestamp that implies it is live. If you show “live revenue: $4,210” and it is actually an hour old, you have not saved time, you have built a small liar. Label the freshness honestly (“as of 2pm”) and the problem disappears.

There are really only three ways your copy gets updated. You pull on a schedule (a job refreshes it every so often, whether or not anyone is looking). You pull on demand (you refresh only when the page is actually opened, which saves work but makes the first load slow). Or you are pushed to (the source tells you the instant something changes, usually through a webhook). Push is the most “live” and the most fiddly to set up. For a dashboard you glance at, scheduled pulling wins on simplicity almost every time.

Every number on a dashboard is a summary, and every summary throws information away on purpose. “Average response time: 1.2s” can look healthy while a tenth of your users sit at ten seconds, because the average buried them. “Revenue is up” can hide that one big customer carried the month and everyone else shrank. This is not dishonesty, it is what summarizing is, but a dashboard presents summaries with such confidence that it is easy to forget.

The habit worth building: for each headline number, ask what it is hiding. Often the fix is to show the shape, not just the summary (a distribution instead of an average, a breakdown instead of a total). You do not need all of that on a personal dashboard, but you should know which simplifications you accepted.

Say you run a small paid app and you are tired of opening Stripe in one tab and your app’s admin in another just to see how the week is going. You want one page: signups this week, revenue this month, and how many people actually came back.

Source. Two places have what you need. Stripe has an API for the revenue, and your app already has its own database with the signups and the activity. So, two sources, both reachable in code. Your agent’s first instinct will be to call both live on every page load. Note it, and overrule it in the next step.

Store. You do not want to hit Stripe every time you glance at the page, so you keep a small local copy. How small? Three numbers and a little history. This is the storage decision from the storage page, and here it collapses almost instantly: an on-device SQLite file is more than enough, no server, nothing to run. A flat file would even do, but SQLite costs nothing extra and makes the little bit of history easy to keep.

Refresh. How fresh do these numbers need to be? Honestly, an hour old is fine, you are not trading stocks, you are checking in. So a small scheduled job wakes up every hour, pulls from Stripe and your app database into the SQLite copy, and sleeps. The page just reads the copy, so it loads instantly and still works if Stripe is briefly down.

Display. The temptation is a grid of charts. Resist it. Three big numbers (signups this week, revenue this month, weekly active) and one small trend line underneath is the whole thing. Each of those three would actually change what you do this week; nothing else earns its place yet. Label them “as of 2pm” so you are never fooled into thinking they are live.

Add it up and the build is small on purpose: an hourly script, one SQLite file, one plain page, running on the laptop you already have or a cheap always-on box if you want to see it from your phone. No server to speak of, no real-time anything, and every corner you cut you cut knowingly.

A personal dashboard never asked who you were, because the answer was always “me, on my laptop.” Add a second person and the app suddenly needs authentication: a trustworthy way to prove each visitor is who they claim. This is the single most common thing people underestimate and the most dangerous to improvise. The right move on this rung is almost always to let a dedicated service handle logins rather than rolling your own.

Knowing who someone is (authentication) is different from deciding what they may see (authorization). The instant your dashboard holds more than one person’s data, every single query has to be scoped to the right person, or someone will eventually load the page and see numbers that are not theirs. This is the most common serious bug in shared apps, and an agent will not add the scoping unless you make it a rule.

When the only data at risk was yours, a dropped database was a bad afternoon. When it is customers’ data, the same loss is an incident you have to answer for, and a leak of it can be a legal one. This is exactly the far end of the storage page: recovery stops being optional (a copy you have never restored is not a backup), and what you choose to collect in the first place starts to matter, because the safest data to lose is the data you never stored.

Your personal dashboard could crash overnight and you would fix it with coffee. Once other people open it during their workday, “it is down” becomes their problem and your reputation. You do not need heroic uptime on day one, but you do need to decide, on purpose, where it runs so it stays up without you watching, and how you find out when it does not. That is the beginning of the operations half of software, and it is a real rung, not a footnote.