š² Dashboards are Useful, Actually (it surprised me too!)
Why I built two custom dashboards instead of using normal analytics and activity tabs, the difference between data you look at and data you use, plus a skill file to train your coding agent with.
Historically, I have disliked dashboards. I never really got why people preferred Notion to Obsidian or why everyone was so happy when ābasesā became core. I prefer working at a lower abstraction level where I can get my hands into the guts of the information directly, and I am kind of bad at interpreting graphs (numbers are not my friend). I also do not trust other peopleās data visualizations, because every chart is an argument about what matters and I get annoyed when they donāt acknowledge the implicit biases appropriately. Also, tables are often slow and clunky. I once took a Microsoft Access class back in college, and could not figure out why anyone would use it instead of an Excel file.
So when I saw people on twitter dismissing Claude-built dashboards as productivity porn I kind of shrugged and didnāt care. But some of my colleagues built some custom dashboards and as soon as I saw them in a context of use I understood, with pain points I shared, I leapt to build my own.
The key thing is that they arenāt just for analytics, my dashboards are a one-stop-shop GUI on top of my common workflows.
I now maintain (it would be wrong to say I merely āhaveā them :P) two custom dashboards, and I am in love with them. One tracks information for my day job at a software company: channels I need to monitor, action items I need to check off, and patterns I need to be aware of. The other (which was very quick to build once I figured out all the fiddly bits for the other) is for handling social media and this newsletter: things I ought to reply to, my calendar of scheduled content, and notes on stuff Iāve read and annotated lately (hereās a quick tweet about the data sources for the dashboard section belowā¦ hopefully it loads!).
Crucially, I now spend a lot more time in this dashboard and a lot less time getting annoyed at the slop and crap the various apps try to feed me.
On the difference between analytics and operations
Most analytics tools Iāve seen are built around the question āhow are things going?ā They give you charts that go up and to the right (or not), and you look at them and feel good (or bad). I get why they do it ā for companies, itās important to know how something is performing so you can adapt, and for companies selling software to content creators the dashboards offer a behavioral nudge to get the creators making money.
Tbh, I really hate vanity metrics. I have always tried to find ways to turn off subscriber counts and view numbers in both Substack (itās now possible, I think, which is ironic) and Ghost (which is open source so itās technically possible there, too), but as a default, the platforms want you to see those metrics because that is how they make their money. If your number goes up, their number goes up, so they nudge you to make your number go up. The whole incentive structure is designed around their goals, which I donāt begrudge ā it costs money to send emails and host websites and they are footing the bill not me. But nonetheless I generally go out of my way not to be influenced by vanity metrics and the nudge to optimize for money.
Goodhartās law says that when a measure becomes a target, it ceases to be a good measure. Off-the-shelf analytics platforms choose your ākey performance indicatorsā for you, and those KPIs shape your behavior whether you want them to or not. Building a custom dashboard means choosing your own metrics, which means staying in control of what you are optimizing for. You can build a dashboard that nudges you toward the goals you actually care about, instead of the ones your opinionated tool thinks everyone should work toward.
And lest you think to yourself ādonāt be ridiculous Eleanor, of course you want to increase your subscriber count, you always ask us to share your articles with people we think will like them,ā well, sometimes, the best way to achieve my goals is to ignore themā¦ Claudeās reminders not withstanding.
My newsletter dashboard does not have a big subscriber count front and center. Instead, the first things I see when I open it is a ārespondablesā card are comments, mentions, and shares across platforms that I could reply to. It is much more useful than the notification sections of the various apps because it does not have all the likes and boosts mixed in, and it actually clears things when I check them off. It surfaced some pings I had completely missed even though I am pretty active on my social media accounts and try very hard to engage with everyone who reaches out. (Seriously, I love to chat. For algorithmic reasons I prefer comments on Substack of course, but the whole reason I do this at all is to have good conversations.) It also helped me find places that people had shared my articles that I was totally unaware of, like this r/femalemonarchs post about my article about the Ottoman queen Roxelana.
Beside the list of pings I ought to respond to, thereās a list of drafts Iām in the midst of that arenāt in Substack yet. If I click them, they automatically launch the file in Obsidian so I can start working on it. Thereās also a list of scored reply candidates ā threads in various places that I scrape (certain subreddits, hackernews) where my expertise is relevant and I might be able to help. My searches are optimized for finding discussions I can actually contribute to, which is quite unlike most social media algorithms.
On mini-maps and checking in
Back when I was learning how to play League of Legends, I was frequently lectured by my teammates about how the best players check the mini-map every ten to fifteen seconds. The mini-map is small and peripheral, and a pretty normal instinct is to focus on the fight your avatar is engaged in. But to avoid getting flanked, you have to build the habit of glancing at the overview.
A dashboard is like a mini-map. It exists to answer the question āis there something happening outside my current focus that I should know about?ā And the answer to that question is only useful if checking the map is quick and easy. I keep both of mine up on my second monitor, where I can glance up, tap refresh, and then keep cruising on my work without risking distraction.
This, by the way, is why information density matters a lot to me. A dashboard where every number lives on its own page, requiring clicks and scrolling to reach, is a dashboard I will not check. I prefer filter pills over dropdown menus, collapsible sections instead of separate pages, and sorting and filtering options on every table column. Convincing Claude to build click-throughs from every chart element into a detail view has been an adventure.
The information needs to be scannable, the way a map is scannable. If I have to scroll a bunch to understand the state of things, I will just skip it and (not at all metaphorically) get flanked... because things are moving so fast right now; not just in software, but with my offline life, too. My husband just had surgery, my daughter is deep in the throes of dropping naptime but still napping at school (which means 10:30pm bedtimes and sometimes, 5am wakeups), and I am finishing up some classes.
But I still need to keep on top of things at work, and Iām determined to keep up my social obligations and this newsletter. So thanks to my dashboard (and Claudeās little reminders), I am building an even better habit of checking in with the bigger picture ā metacognition and executive functioning require building habits of reflection, and while I have always been pretty good at all that, thereās always room for improvement.
On pretty vs useful design
Good design (like whatās offered by this really useful frontend design skill for AI tools) often tries to get rid of redundant information and explainers to look cleaner, but I want all the words. I want labels that remind me exactly what each button does. I want the context right there, not hidden behind a hover tooltip I will never find. This is partly personality and partly learned from using RSS to curate opportunities: my RSS workflow is built around scanning and filtering, and processing feeds in short bursts, because I read very fast. My dashboards take advantage of this; I donāt know how well this would work for other people who do not read quickly at a glance, so please report back.
My taste in dashboards follows the same pattern as my taste in Obsidian themes. I have always gravitated toward themes like my own Palatinate, which was deprecated by Sanctum, and my now-preferred Primary. These are chill and soothing, but have solid contrast, keep all the interface elements visible and labeled, and in fact add extra labeling like my beloved infoboxes and better checkboxes. I avoid ultra-minimal themes that hide controls for the sake of aesthetics because I often go months at a time without touching a tool (maybe Iām sick, maybe Iām busy with something else) and when I come back to it, getting back up to speed needs to be quick.
I still havenāt memorized the shortcuts for making dotfolders visible on Mac, or the one for deleting a whole terminal line. I like tooltips.
The worst possible dashboard is one that looks impressive in a screenshot but requires three clicks to reach the information I actually need.
Back in 2022 I wrote a whole article about shortcuts for finding the middle ground between pretty and practical so I wonāt continue to bore you here; go check it out, I just looked it over and removed the archival paywall.
On SQLite and simple tools
I did not want to deal with libraries I did not understand, which is part of why the architecture of my dashboards is so simple (although... not easy, not for someone as barely-technical as me!). I donāt have any libraries, although I did briefly consider building in a lightweight markdown editor using CodeMirror 6 (what Obsidian is built on top of). In the end I decided to just launch my drafts in Obsidian.
Both dashboards use SQLite, Python, and React, all of which Iām at least vaguely familiar with. SQLite runs in a single file on my laptop. The backend is a FastAPI server that starts in under a second. If something breaks, I shrug, restart it, or ask Claude why it didnāt run its tests before telling me a change was done :P
I am never going to sell (or even open source) this thing because itās extremely custom and honestly kind of brittle, and I donāt have time or the philosophical conviction to make it available to everyone because unlike, say, my Obsidian themes, it is extremely idiosyncratic. Even my work dashboard setup would barely be useful to my team; theyāre better off building their own, albeit based on shared data. If you would like to build your own, I did have Claude write out some dashboard creation tips for future agents, and you should be able to just link this article and the gist file.
When the tool breaks (and itās me: it will break, it would break even if it had 20 engineers full-time dedicated to making it perfect according to my whims, have you met me?), I want to fix it in minutes, in a language I can squint my way through, on a machine I not only control but understand (i.e. not a digital ocean droplet, not a virtual machine, not a dockerfile).
There is an old argument in personal knowledge management about local-first tools versus cloud services. I like Obsidian because it lets me control almost everything about my notes, and it is fast. I ended up using Substack over Ghost because it has much better network effects (stay tuned for my forthcoming article about this!) but also because I do not want to maintain my own mailgun and stripe integrations anymore or deal with any of the other little edge cases I kept running into. Where I come down on the spectrum of complexity, control, privacy, and maintenance cost is variable depending on what is going on in my life at any given time, and I am confident that where you come down on these things will be subtly different from me along several different axes.
But hopefully this article is useful for you (or someone you know!) anyway.
On what actually gets looked at
The most important principle I have learned from building dashboards is that every piece of information should either tell me something I did not know or prompt me to do something specific. If it does neither, it is clutter.
Early versions of my newsletter dashboard had the default topline KPI cards: total subscribers, total views, total posts. The AI built those because dashboards are āsupposedā to have KPIs at the top, and the first thing I did was rip all that out because I knew roughly how many subscribers I had. It does not change that much on a day-to-day basis and seeing the number did not make me communicate differently with people. Claude was copying a convention, operating from the id of the internet to serve the median case, not me.
Now I have inline task lists, drafts I still need to finish, things I need to respond to, and other action items. Posts that got a strong enough response awhile back to warrant a bump are listed out in a bite-size, responsive chunk. My dashboard is basically a custom, self-updating, smart todo list and I didnāt even have to learn reverse polish notation to use it.
At work, I have channels I need to monitor where I check things off when they are done, but Slack does not make completed messages disappear, and the channel gets noisy. It is hard to concentrate on action items when they are buried in conversation, and reminders are not accessible to my AI tools and they are hard to sort. I could move everything to a ticketing system like Linear, but I prefer not to mix streams, and that would be a lot of overhead for things that are fairly simple. The dashboard helps me filter out completed things using a simple heuristic based on a specific emoji, and uses simple API fetches to pull data in. It doesnāt even really need AI once it was built, although I do like the lightweight summarization that headless haiku can provide (among other things!).
On building for yourself vs buying (or not)
I am not recommending that everyone build custom dashboards (although if you want to, donāt forget that I put some hard-won advice into a gist file for coding agents to learn from). The upfront cost is nontrivial, the urge to fiddle instead of work is a real concern that nerdsnipes a lot of people in the knowledge management community, and most peopleās analytics needs are either adequately served by existing tools or realistically nonexistent. Jira gets a bad rep but it is probably a bad idea for every engineer to go build their own idiosyncratic version.
The conventional wisdom is āuse existing tools, donāt reinvent the wheel.ā That advice is correct for most people, most of the time. My needs are unusual enough that no off-the-shelf tool does what I want (even ignoring the fact that none of them do it at the price point I am willing to pay for a newsletter I do not go out of my way to monetize, although youāre obviously always welcome to help me out with hosting costs and the like!)
The issue is compounded by how nervous I am using software where I donāt have confidence in the business model. I trust that YouTube is going to continue existing in five years; it makes Google a lot of money, and itās pretty stable at this point. I am less confident that a company completely dependent on Twitterās API is going to continue to update their analytics software the next time Nikita & Elon fiddle with things.
With a custom dashboard, I do not need to wait for tools to figure out how to integrate niche platforms like Substack Notes (which does not have a public API) and Tumblr. My preferences are rarely aligned with what analytics tools offer, and I would rather build exactly what I need than compromise on what some product manager decided (probably correctly!) was a relatively rare use case for someone likely to spend money on their software.
So if you find yourself repeatedly opening multiple tools, cross-referencing numbers in your head, waiting forever for big corporate dashboards to load, trying to squint through multiple API call results in your terminal, making decisions based on fuzzy recollections of data you saw last weekā¦ that friction is solvable now, thanks to AI tools like Claude Code.
And I think itās worth doing, because building a dashboard like this taught me a lot, not just about databases (and backups! and tests! and APIs and scraping and...)
The act of deciding what goes on the dashboard forced me to really think about what I actually care about, similar to how writing notes and articles forces me to articulate things I thought I understood...
How do you feel about dashboards? Have I changed your opinion at all?