![\"My](\"https:\/\/nazeem.me\/wp-content\/uploads\/2026\/08\/Screenshot_20260815_191927-1024x854.png\")
<\/figure>\n\n\n\nInformation you have to go and fetch is information you check less often than you should.<\/p>\n\n\n\n
\n\n\n\n
What It Looks Like Now<\/h2>\n\n\n\n
One page. Five modules, each running in its own container, pulled together by a dashboard shell called Glance<\/strong>. The shell is configuration, not a product \u2014 it reads each service’s API and renders the numbers. That’s the whole trick (admittedly greatly helped by LLMs to design):<\/p>\n\n\n\n The health module was the biggest piece by some distance. I exported four years of Fitbit<\/strong> history and imported it alongside live Garmin<\/strong> data, so the trend line runs continuously from March 2022 to today instead of restarting when I changed watches. About 7 million data points. There’s a real gap of six days in January where neither device recorded anything, which is the week I switched. I’ve left it in. It’s honest.<\/p>\n\n\n\n The finance module pulls positions from my broker and reconciles them against manually entered accounts for the things a broker doesn’t know about \u2014 Provident Fund, cash, the rest. Everything now sits behind a single login.<\/p>\n\n\n\n This is the part worth writing down.<\/p>\n\n\n\n I planned the whole thing on paper first (with the help of AI, of course, including this post), including which endpoint each module would call and which fields it would read. When I came to build it, three of the four were wrong.<\/p>\n\n\n\n The monitoring tool returned a flat structure where I’d assumed a nested one (I needed the LLM to explain this to me too!). The finance app had moved its performance endpoint to a new API version, and the old path returned a 404<\/strong>. The travel app used different field names to what I was expecting.<\/p>\n\n\n\n None of these would have crashed anything. Each would have quietly rendered an error tile on a dashboard I’d then have trusted. The fix was boring and it worked: read a live response from every endpoint before writing a single line of template code.<\/p>\n\n\n\n The last gap was authentication. Several services were reachable on my network with no login at all, and the obvious answer was to put single sign-on in front of everything.<\/p>\n\n\n\n So I drafted the whole build. Container, secrets, rollout order, backups. Then I actually tested my assumptions and found that most of the services I’d listed as unprotected were, in fact, protected. The real list was less than half of what I’d written down (i.e. in my issue backlog in my Obsidian Vault). A lot of the services were things I wanted open so I could use them on the fly on an ipad or my phone. <\/p>\n\n\n\n I closed the gap with tools already running instead. I stopped proxying my router’s admin interface entirely rather than putting a login in front of it, and turned off open registration on one app that had it. That took an afternoon and added nothing new to maintain.<\/p>\n\n\n\n![\"The](\"https:\/\/nazeem.me\/wp-content\/uploads\/2026\/08\/Screenshot_20260815_192114-1.png\")
<\/figure>\n\n\n\n
\n\n\n\nThree of My Four API Guesses Were Wrong<\/h2>\n\n\n\n
\n\n\n\nThe Service I Decided Not to Build<\/h2>\n\n\n\n