Home Dashboard

Under the hood — for the technical folks

Claude built this as a Flask application serving five pages from a single base.html layout, with interactions handled through HTMX partials. A SQLite database holds the shopping list, todos, and small amounts of state between visits. A session-based login protects the whole surface; passwords are hashed with scrypt.

The TV page talks to a companion service on a small media machine to trigger playback, wake the display, and control input. The Smart Home page talks to a home automation hub over its REST API. The House page reads local weather from a public forecast API with graceful degradation if the source is slow.

A thin PWA manifest makes the site installable on iOS and Android, with a separate manifest for development so the two never collide on the same phone.

The choice to use HTMX instead of a heavier front-end framework wasn’t a style call — it was what made the whole thing changeable. When I wanted a page to behave differently, I could open a template and rewrite it in minutes, without a build step or framework in the way. That’s why I can keep tweaking it — notice something annoying in the morning, fix it before lunch, and have it running again that afternoon.

Technical highlights Claude built under direction:

• Session auth with scrypt-hashed passwords and a small CSRF helper
• HTMX partial endpoints for every interactive element, each returning a sub-template the page swaps in place
• Jinja macros for reusable UI primitives so templates stay short
• Open-Meteo weather integration with graceful degradation
• Home automation REST integration with bearer token held server-side
• Two PWA manifests (development and production) so the installable app can be iterated without clobbering the live install
• Small deployment footprint — single gunicorn process behind a reverse proxy, managed by systemd, self-hosted in a container

Stack: Python · Flask · HTMX · Jinja · SQLite · scrypt · Open-Meteo · REST integrations · PWA

---

What I wanted

I was tired of flipping between four phone apps every morning — one for the TV, one for the lights, one for the shopping list, one for the forecast. Each one wanted me to sign in, update, open a sub-menu, and then wait. I wanted one screen, swipeable, fast, and designed for the way I actually use it: holding a phone with one hand.

How I got it

I told Claude what I wanted, got an initial version working, and iterated from there. My first asks were about the feel — it had to load instantly on a cheap phone, it had to not need an account, it had to be something I could change in minutes instead of going through an app store. Claude suggested the simplest option rather than the trendy one, and I trusted the call. Most of my work after that was sending pages back saying “this is too busy” or “this should be one tap, not two,” and deciding when each page was done enough to use.

What it does

Five pages you swipe between: a TV remote, a house overview with the weather, smart-home controls for lights and scenes, a shopping list and todos, and a services page. Tap anything and it responds immediately — no spinners, no loading bars. You can install it to your phone’s home screen like a real app. It stays small enough to work even when the wifi is slow.

Why it matters to me

It replaced four apps my girlfriend and I were tired of juggling. When I want to change something, I can change it in a minute, because the whole thing is small enough that nothing gets in the way. I use it every day. The interesting part isn’t the tech; it’s that I have a tool that fits my morning instead of one I have to fit myself around.

What I learned

This was the project where I realized the biggest lever I have is asking for something simpler. Claude’s first draft was more ambitious than what I actually needed, and every round where I asked for less — fewer pages, fewer taps, less framework — the result got faster and easier to change. After this one, I started every new build with the same prompt: what’s the simplest shape this could take?