There's a project floating around V2EX that I keep thinking about: a builder made an Android TV app called 「节目单」 (a program list) for the elderly and kids. The story behind it is the part that sticks. He visited an uncle with mild Alzheimer's living alone, found the TV cold and the remote lost, because the menus were too much to operate. Then over summer his mother-in-law was minding his son, and the kid just sat through whatever the TV apps pushed — algorithmic short-video, one after another, with even a dedicated kids' app serving stuff nobody wanted. Two problems, one shape: make it dead simple to operate, and make the content fully controllable by a guardian.
His answer was the WebViewTV approach — a WebView opens a page, finds the video, jumps to fullscreen — wrapped so the TV boots straight into a tiny, hand-curated list. No recommendation feed. You add what you want on the screen, you delete what you don't. He even built a way to remotely add, remove, and edit the program URLs on a bound TV from his phone, whether or not the set is online at that moment. He defined a small markdown-ish protocol with `#JMD` (one-time import) and `#JMD+` (subscribe and append on next launch), and he was candid about the pain: the APK was effectively 300MB because the domestic Android TV ecosystem is so fragmented that he shipped three WebView kernels and deleted the unused ones on first run.
The signal worth pulling out
Strip away the hardware story and what's left is a pattern a lot of us keep rediscovering. The durable, valuable part of that app isn't the WebView shell — it's the idea that a guardian, not an algorithm, owns a short, explicit list of approved URLs, and can push changes to it from wherever they happen to be. That's a data-and-endpoint problem, not a device problem. And it lines up with a broader thread in the same evidence: non-programmers are shipping real things by describing intent to AI, learning the hard way that "good software comes from using it, not planning it" and that you version and roll back so a bad change can't sink you. The friction they hit is fragile shells and moving pieces, not the core logic.
So the interesting question for a builder is: which half of this can you rebuild on something you don't have to babysit across a dozen TV firmware versions?
What you can actually build on VicroCode
The durable half maps cleanly onto confirmed platform capabilities. The fragile half — device auto-launch, fullscreen takeover, TV remote handling, the three-kernel WebView packaging — does not, and I'll be straight about that boundary below.
Start with the ledger. The whole premise is a hand-curated whitelist of approved video URLs with a bit of metadata: title, category, and an optional timestamp so an episodic creator's videos sort oldest-to-newest instead of newest-first. That's a handful of columns, and it belongs in a small relational store you can open and correct by hand. A SQLite table (`url`, `title`, `category`, `added_at`, `sort_time`, `subscribed`) covers the original protocol's fields with room to spare, and being able to reach in with a SQLite editor to fix a bad title or reorder an episode matters more here than any fancy schema — the guardian is the algorithm, so the guardian needs to see and touch the rows.
Then the player. Instead of a native WebView, you build a plain HTML page that reads the whitelist and renders a large-tile, low-cognition list — the kind of thing where an uncle who lost the remote can still find CCTV-1. You can run HTML online while you iterate on layout and playback, and when it's ready you lean on the platform's web app hosting so there's a stable URL the TV's own browser can open. The page is the browser/player the original builder described — it just lives on a hosted page rather than inside a 300MB APK.
For the "add it from my phone while I'm bored at work" part, stand up a small API endpoint hosted in-platform that the guardian calls to insert or remove a URL in the SQLite whitelist. The player page reads that same table on load, which reproduces the useful bit of `#JMD+` — push a new link now, it shows up next time the screen refreshes — without needing the TV to be online at push time. One caution worth stating plainly: an endpoint that mutates a shared list needs an access control from day one, even a single shared secret or token check. An open write endpoint means anyone who guesses the URL can put anything on grandma's TV, which is the exact failure mode this whole project exists to prevent.
If you later want a helper that turns a creator's video page into a properly ordered playlist, that's a natural fit for online Python execution — a small script that fetches, parses, and writes rows into the whitelist. And if the list grows past a curated handful into something you actually want to search over, a knowledge base gives you somewhere to put that. But honestly, the strength of the original idea is that it stays small, so I'd resist scope creep here.
The boundary, stated honestly
What you cannot rebuild on the platform is the on-device experience: booting straight into fullscreen playback, capturing the TV remote, and the cross-firmware WebView packaging that made the original APK heavy. Those live on the device and stay outside these capabilities. What you get instead is the durable, portable half — a hosted player page, an editable URL ledger, and a guarded push endpoint — that keeps working even if you stop maintaining a native app. The original author made the same point about his own single-machine mode: the value survives because it's fundamentally just a page and a list. That's the part worth owning.
None of the elder-care or child-safety outcomes here are verified; they're one builder's account of his own family. Treat the pattern as the takeaway, not the results. If you're a solo builder or a small team, the reproducible move is modest and shippable: model the whitelist, host the player, guard the endpoint, and let a human stay the curator.