ViewPane is heading to Google Play and the App Store soon. Before a store listing goes live, we run a discipline we think every self-hosted product should be held to: every claim on this website gets verified against the shipping app. Not skimmed — verified. Each feature exercised on real hardware, each setup path in the docs run end-to-end, each sentence checked for precision.
The self-hosted crowd has been burned enough times by marketing pages that describe a roadmap instead of a product. We’d rather you be able to hold every word of this site against the app on your phone. Here’s what the verification pass looks like in practice.
Features get finished, then claimed
The camera grid now ships with a real 2- or 3-column layout setting, applied consistently across the standard camera view and Live Wall. Small feature, but it went through the full loop before it earned a sentence on the homepage: built, exercised on-device, added to the test checklist, then claimed.
That’s the standing order of operations. Roadmap features — and there are plenty we’re excited about — stay off this site until they’re in the build. When something new lands here, it exists.
Words get made precise
Video pipelines are full of claims that are technically true and practically misleading, and we refuse to trade on that gap. So the copy on this site is scoped to exactly what happens on your phone:
H.265 live playback is native. Clips are a different story on purpose: a 4K HEVC clip pushed straight through a phone’s video stack plays like a slideshow, so our push relay transcodes clips to 1080p H.264 before they reach the app. Smooth playback, deliberate engineering, and the site says precisely that instead of a bare “H.265 support” badge.
Pinch-to-zoom lives in fullscreen view — so that’s what the site says. Not “gesture controls everywhere,” not an implied feature surface bigger than the real one. Where a capability lives is part of the claim.
Docs get proven by running them
The docs section is now fully written — quick start, Frigate configuration, push relay, Tailscale, MQTT auth, FAQ, and troubleshooting. No placeholder chips, no “coming soon.”
But writing docs isn’t the discipline; running them is. Every setup path we document gets executed from scratch, because a documented path is a claim like any other. That policy paid for itself immediately: while verifying the Docker path for the push relay, we caught the container image missing a media dependency the systemd install gets from the host. Fixed and republished before a single user ever hit it. That’s the whole point of proving docs before launch instead of after — the happy path you run yourself never finds that bug.
The checklist keeps it honest over time
A one-time audit decays. So every feature claim on this site maps to an item on our device-test checklist, and the two grow together: when the app changes, the checklist gains entries; when the site changes, the new claims get verified before deploy. The site and the app aren’t allowed to drift, at launch or after.
Try the Demo mode when the app lands — it’s a full tour on sample data, no server required, so you can check our claims before pointing ViewPane at your own hardware. We built it for exactly that kind of skeptic. We’re that kind of skeptic too.