A service you can only use at a desk is half a service
Most home lab dashboards have a dirty secret: they’re only ever opened from the chair. The moment you’re standing in the garage, on a client site, or in the supermarket queue, that beautifully docker-composed stack of yours may as well be a screenshot. The services still run — you just can’t reach them, or reaching them is enough friction that you don’t bother.
I’ve been applying a simple filter when deciding what earns a place in the stack, and I’d argue it matters more than most feature comparisons: the phone test. Before a service graduates from “experiment” to “infrastructure”, I try to complete its core workflow from my phone — once on home Wi-Fi, once on mobile data, from somewhere that isn’t my house. If I can’t, it isn’t finished.
The instinct came from a piece on XDA where the author rebuilt their self-hosted stack around exactly this criterion — notes, photos, media, saved links, home control, tasks — and found it changed which tools they picked in the first place. That matches my experience, and I’d go one step further: mobile support isn’t a nice-to-have feature, it’s a proxy for whether the project is any good.
The phone app is an integration test
Here’s why the test works. A desktop web UI can hide a lot of sins. A native (or even decent wrapper) mobile app forces the project to have a stable API, working authentication, sane session handling, and a data model that survives intermittent connectivity. Projects that clear that bar tend to be well-engineered everywhere else. Projects that ship a WebView pointed at their own homepage tend to be fragile in other ways too.
So when I’m evaluating two candidates for the same job, I look at the phone experience first:
- Real app or thin wrapper? A WebView app that breaks the moment the CSS changes is a maintenance liability, not a client.
- Offline behaviour. Notes and read-later apps must work on a plane. A dashboard that goes blank without connectivity is tolerable. Know which one you’re getting.
- Background sync. Photo backup that only runs while the app is foregrounded is not a backup strategy.
- Push notifications. For anything that alerts — Home Assistant especially — this is the entire point of mobile access.
On those criteria, the same categories keep passing: Joplin for notes, Immich for photos, Home Assistant for the house, a read-later tool (Wallabag or Karakeep), and a task board you can actually tap an item into. If a category’s mobile story is weak across every candidate, that tells you something too — maybe the workflow doesn’t need a phone, or maybe it’s a gap worth solving with a shortcut or an API script instead of a full app.
The test is really a network decision in disguise
Where people trip up isn’t the apps — it’s what mobile access implies. A phone on mobile data cannot reach http://192.168.1.10:8096, and the two honest answers to that are:
- A VPN, not a port forward. Tailscale or WireGuard on the phone, and every service is reachable by name from anywhere, with zero public attack surface. This is my default and I’d make it yours.
- A reverse proxy with real auth for the few things that must be public. If a service genuinely needs sharing with other humans, it goes behind HTTPS, with authentication that isn’t a password in a URL.
What you should never do is port-forward six services “for convenience” and tell yourself you’ll get to auth later. The phone test fails permanently the day your stack becomes someone else’s crypto miner. One VPN app on the phone, configured once, covers the whole lab — and it also covers the apps’ strict requirements, because most mobile clients refuse plain HTTP remotes anyway.
For small businesses the same logic applies with higher stakes. The owner who can check the booking system, the camera at the shop, or the backup status from the car park makes faster decisions than one chained to the office PC. Field staff with phones are the norm; give them infrastructure that assumes it.
Run the test before you adopt, not after
The cheap version of all this: before you commit a weekend to deploying a new service, install its phone app first and point it at the demo instance. If the app is a disaster, you’ve saved yourself a weekend. If it’s good, you’ve learned more about the project’s engineering culture than any README can tell you.
Self-hosting is supposed to make your tools yours — every screen you own, not just the one bolted to the desk. If the stack only works from the chair, you haven’t replaced the cloud service; you’ve just moved it into the house and made it less convenient. Make the phone test part of the deployment checklist, and watch how quickly the stack starts feeling like infrastructure instead of a project.