DEV Community: Super Funicular

Texas Just Opened a Privacy Investigation Into Meta's AI Glasses — and It Raises a Question Every Camera App Has to Answer

Super Funicular — Fri, 22 May 2026 08:05:41 +0000

On May 20, 2026, Texas Attorney General Ken Paxton opened a formal investigation into Meta's AI Glasses — the Ray-Ban and Oakley camera-equipped eyewear — over how the device records, processes, and stores facial geometry and ambient video. Two days earlier, the ACLU and 75 civil-liberties organizations sent Meta an open letter warning that the company's reported plan to ship facial recognition on the same glasses would "create serious risks for abuse victims, immigrants, LGBTQ+ people, protesters, [and] workers." The Texas AG's office described the central concern as the device's documented "always enabled" mode, in which the glasses continuously process video for Meta's AI products — with a recording-indicator LED that is "easily hidden" and "not active during the always-enabled mode."

This isn't a niche policy story. It's the second time in less than two years Texas has taken Meta to court over the same underlying issue: capturing biometric data from people who never consented. The previous round ended in 2024 with a $1.4 billion settlement.

If you build, ship, or even use a camera-bearing piece of consumer technology, this is a moment to look at your own surface area and ask the question Paxton is asking Meta: where does the video go, who can see it, and did anyone agree to that?

Why this is a watershed and not a one-off

The legal text matters less than the precedent. A state AG just declared that:

An "always enabled" recording mode, by itself, is a regulatable consumer-protection issue when the LED indicator isn't reliably visible.
Cloud-side processing of ambient video — even when framed as "AI features" — falls inside biometric-privacy law if facial geometry is derivable from it.
The 2024 Meta settlement was not a one-time event; future biometric capture is on the table again.

That last point is the structural shift. Until this week, the operating assumption inside most consumer-hardware roadmaps was that a 2024-style consent banner and a small LED indicator were enough. Texas just signaled that they aren't, at least when the device is wearable and the camera is on by default.

A wearable camera is not a unique animal. The question is whether the same logic applies to camera apps, dash cams, smart doorbells, and any other "always on" recording product. There is no obvious reason it wouldn't.

The architecture question every recording product now has to answer

The Texas filing is really a stress-test of three architectural choices that any product with a camera can be measured against:

1. Is recording opt-in per session, or always-on by default?
Meta's vulnerability here is "always enabled." The opposite end of the spectrum is "the user explicitly starts each recording, and there is a persistent on-screen indicator that the camera is active." The latter is the model a regulator can defend.

2. Where does the footage live — locally, in a vendor cloud, or fed into a model?
Cloud storage of camera footage isn't illegal. But it inverts the burden of proof. Once the footage is in your vendor's cloud, the vendor has to demonstrate it isn't being used for anything the user didn't consent to. Locally-stored footage carries no such burden — the user holds the only copy.

3. Is biometric inference happening, and if so, where?
On-device biometric inference (Face Unlock, Apple's Vision Pro hand-tracking) is broadly tolerated. Off-device biometric inference of third parties captured in your camera frame is the actual line Texas is drawing. If your product processes video in a remote system, you need an affirmative answer for what is and isn't being inferred from each frame, and what's being retained.

These three questions — Opt-in or always-on? Local or cloud? Inference on-device or off? — now form the baseline a state AG appears willing to enforce.

What this looks like in a phone-based camera

We build Background Camera RemoteStream, an Android app that turns the phone you already own into a security/monitoring camera. The architectural choices we made years ago map directly onto the three questions above, and they look very different from the Meta Glasses model:

No always-on mode. The user opens the app and starts the recording. The app does not auto-record, does not auto-start at boot, and does not capture anything unless the user has explicitly initiated a session.
Local-only storage. Recorded video is written to the phone's internal storage. There is no cloud upload, no off-device backup, and no vendor server holding a copy. We have no copy of your footage. We can't have one — the architecture doesn't support it.
No account, no tracking. The app does not require a Google or Meta or Super Funicular account. There's no sign-in screen. There's no analytics SDK shipping ambient telemetry. There's no advertising ID being attached to recordings.
YouTube Live streaming is user-initiated. If you want to stream to YouTube Live, you set it up yourself, using your own YouTube account and your own RTMP key. The stream goes from your phone directly to YouTube. We're not in the middle.
Screen-off recording is intentional, not covert. Recording continues when the screen is off because that's a battery and stealth-of-the-phone-itself feature (the phone looks idle to anyone glancing at it). The camera LED on the phone behaves the way Android requires.

The point isn't that we're better than Meta. The point is that the Texas filing makes "where does the video go" a question consumers can now expect to ask, and a product that can answer it crisply is in a different category from one that can't.

What developers should take from this

If you build anything that captures video, audio, or biometric-derivable data, three things are worth doing this week:

Audit your default state. Is recording opt-in or always-on? If always-on, what's the affirmative justification, and is the user indicator reliable and unconcealable?
Audit your storage boundary. Trace one frame of recorded video through your system. Where does it go, how long does it live, who has access, and what models touch it?
Audit your inference surface. What is your product deriving from camera input that the user didn't explicitly ask you to derive? Whatever that list is, decide whether it survives the question "what if the Texas AG asks."

The Meta Glasses investigation will take months to play out, and the legal outcome isn't the interesting part. The interesting part is that the architectural questions are now public. Camera products that can answer them honestly are going to find that the conversation has shifted in their favor.

If you want to see what a "no cloud, no account, no tracking" Android camera looks like in practice, Background Camera RemoteStream is the one we ship. Source on our positioning and how we think about privacy lives at superfunicular.com.

YouTube Live Now Streams Horizontal + Vertical at the Same Time — How an Old Android Phone Becomes a 24/7 Dual-Format Camera

Super Funicular — Wed, 20 May 2026 15:44:52 +0000

YouTube quietly shipped one of the biggest livestreaming changes in years this May: creators can now go live in horizontal and vertical formats simultaneously, from a single source, with a unified chat. The portrait version is auto-cropped from the center of your horizontal feed and routed straight into the Shorts surface, while the landscape version stays on your main channel. (YouTube Help — vertical live streams, Streamlabs guide)

If you've ever tried to reach both the traditional YouTube audience and the Shorts feed at the same time, you know the old answer involved running two encoders, a multistream relay, or paid software like Meld Studio or Restream. That tax is gone. For developers building anything that pushes RTMP into YouTube, this is a meaningful shift — and for anyone using a phone as a camera, it changes what your hardware can do.

What actually changed

Before this update, a YouTube Live stream was either landscape or portrait. If you wanted both, you ran two parallel streams, paid for a multistream service, or stitched together a Studio-side workflow that re-encoded the feed.

Now, when you set up a live event in YouTube's live control room, you can enable dual output. YouTube takes your single RTMP ingest, displays it as your normal horizontal stream on the channel page, and auto-generates a vertical crop that appears in the YouTube Shorts feed. Both feeds share a single chat, a single concurrency count, and a single set of analytics.

There are some caveats worth knowing:

The vertical crop is center-weighted. Anything important (faces, text, key motion) needs to live in the middle ~9:16 column of your horizontal frame, or it'll fall off the Shorts version.
The Shorts surface still has its own discovery rules — you don't bypass them by running dual format. You just stop having to re-upload clips.
YouTube will additionally identify "key moments" from your live stream and turn them into ready-to-share Shorts after the broadcast ends, which compounds the reach effect.

The net result: one stream, two distribution surfaces, zero additional encoder load on your end.

Why this matters for mobile streamers

For desktop streamers running OBS on a beefy machine, this is a nice convenience. For mobile streamers — anyone using a phone as the camera — it's a bigger deal, because mobile RTMP encoders have historically been the weakest link in a multi-format workflow.

A phone has limited thermal headroom. Asking it to encode two video streams at different aspect ratios simultaneously is the kind of thing that turns a livestream into a slideshow after twenty minutes. The new YouTube workflow moves the second encode (the vertical crop) server-side, which means the phone only has to encode one stream. The Shorts version comes for free.

That has a specific consequence: a single phone, plugged in and pointed at something interesting, can now feed two YouTube audiences continuously. A backyard bird feeder. A workshop bench. A puppy. A storefront. A 24-hour ambient stream. The hardware doesn't have to change. The streaming app doesn't even have to know about the vertical format — YouTube handles the crop.

The friction this removes

To appreciate the change, look at what the multi-format workflow used to require:

A phone running a mobile encoder (Larix, Streamlabs Mobile, or similar)
A way to RTMP into something that could split and re-encode (Restream, Meld Studio, a self-hosted nginx-rtmp)
Two YouTube destinations configured, one landscape and one portrait
Aspect-ratio handling on the encoder side, with all the cropping math
Two chats to monitor, two analytics dashboards, two thumbnails

That's a real setup. It's the kind of thing that takes a weekend to wire up and another weekend to debug. The new YouTube path collapses it to: configure one stream, check one box.

For indie developers building tools in this space, the implication is clear — the hard differentiator is no longer "do you support multistream?" It's "are you a reliable single-ingest RTMP source that runs unattended for days?"

Where a phone-as-camera setup fits in

This is the angle that pulled me into writing this piece. I build Background Camera RemoteStream — an Android app that turns a phone into a camera that records and live-streams with the screen off, locally, with no cloud account required. It has built-in YouTube Live support, so you can point a phone at something, lock the screen, and have it streaming for as long as the battery (or a USB cable) lasts.

The dual-format YouTube update changes what that workflow is good for. A few weeks ago, a phone-as-camera setup got you one audience: people who happened to find your horizontal stream. Today, the same setup — same phone, same RTMP key, same lock-screen behavior — also feeds the Shorts surface. The discovery profile of an always-on stream just doubled, and the encoder load did not.

That's a real product change that doesn't require any code on the app side. The thing that matters is reliability of the single ingest: does the phone keep streaming through screen-off, network blips, and the inevitable Android Doze-mode tantrums? If yes, the new YouTube workflow is free upside.

A practical setup (under five minutes)

If you want to try this with a phone you already own:

Install Background Camera RemoteStream from Google Play.
In the app, create a YouTube Live stream and paste the RTMP key. The app supports both screen-off recording and direct YouTube Live ingest, so you don't need a separate encoder.
In YouTube's live control room (on a desktop browser, ahead of time), enable dual horizontal + vertical output for the same live event.
Frame your shot center-weighted — assume a vertical 9:16 column down the middle is what Shorts viewers will see.
Lock the phone. The stream keeps running with the screen off; YouTube does the rest.

You now have one phone serving two YouTube surfaces continuously, with no second device, no laptop, and no monthly subscription to a multistream service.

The privacy footnote

One thing I keep coming back to with this whole category: most "phone as camera" apps in 2026 push your feed through their own cloud as a default. That's how they monetize, and it's why the Play Store reviews for the big-name competitors are full of complaints about subscriptions, account requirements, and "why is my camera asking for my email."

Background Camera RemoteStream stores everything locally on the device. No cloud account. No remote server in the loop unless you explicitly point it at YouTube Live (or another RTMP endpoint you control). No tracking, no telemetry, no off-device storage. The new YouTube dual-format feature works regardless, because the only thing leaving the device is the RTMP stream you configured.

If you're building anything that touches camera + privacy + livestreaming, the takeaway is: the user-side trust posture matters more than ever. YouTube just made the distribution side easier. The hard problem now is whether users trust the camera in their hand.

Closing

YouTube's dual-format livestreaming is one of those updates that sounds like a feature footnote and is actually a structural change. It removes a friction point that has been gating phone-as-camera setups from reaching the Shorts audience for years. The hardware you already own can now do more, without changing.

If you want to try the phone-as-camera side of this workflow, Background Camera RemoteStream is on Google Play. More about the project at superfunicular.com.

Sources:

YouTube Help: Watch & interact with vertical live streams
Streamlabs: How to multistream vertical and horizontal on YouTube
Meld Studio: Stream to YouTube + Shorts simultaneously
SocialBee: May 2026 YouTube updates

The Cloud-Bill Theory of Free Camera Apps: Why Some Are Local-Only and Some Have to Sell Your Data

Super Funicular — Wed, 20 May 2026 15:43:56 +0000

There are two kinds of free Android camera apps and they don't look alike under the hood. One kind runs a cloud relay — every frame your camera captures uploads to a server, sits there, and waits for the viewing-phone to pull it down. The other kind keeps every frame on the phone and serves it to your viewing device over local Wi-Fi only. Both can be free to the user. Only one of them has a built-in structural reason to monetize your data.

I want to walk through why that is, because it isn't a "good vendor / bad vendor" story. It's a recurring-cost story. The architecture forces the business model.

The cloud bill is real

Run the numbers for a hypothetical free cloud-backed camera app with 100,000 daily active users, each recording for a few hours a day. 720p H.264 video runs roughly 1 Mbps. A user recording 3 hours per day at 1 Mbps uploads ~1.4 GB/day. Inbound bandwidth at AWS list price is around $0.01–0.02 per GB (S3 PUT pricing is similar order-of-magnitude). At 100k DAUs:

Bandwidth: 100k × 1.4 GB = 140 TB/day inbound. ~$1,400–$2,800/day.
Storage: even at 7-day retention, you're holding ~1 PB. S3 Standard at $0.023/GB/month is roughly $700k/year for the cold copy alone.
Egress (when viewing-phone pulls the stream): same order of magnitude as inbound, sometimes higher.

So this hypothetical app has a baseline cloud bill of roughly $1–2 million per year per 100k DAUs before any of the actual product engineering. That bill scales linearly with usage. It does not go to zero on quiet days. It does not get cheaper as the company grows — it gets more expensive.

Someone has to pay that bill. There are four candidates: the user, an advertiser, a data buyer, or the developer's own savings until those savings run out.

The four ways to pay it

1. The user pays directly. Subscription model — AlfredCamera Premium, Nest, Ring, the cloud-backed paid tier of Reolink. This is the cleanest version. The vendor's incentive is to keep churn low, which means treating users well. The price the user pays for honesty is the price of the subscription, which is real money over time. AlfredCamera's free-tier squeeze in 2026 — from unlimited cameras down to a 2-camera/24-hour-retention cap — was exactly this dynamic visible from the outside. The cloud bill grew; somebody had to cover it; the company decided to move that burden onto paid users instead of onto data buyers.

2. An advertiser pays. The vendor sells display ads inside the app. This is honest if disclosed — the user sees the ads, they know the deal. The complication is that the ad-tech stack is opaque. Even a well-intentioned vendor using Google AdMob is, in practice, leaking device identifiers, rough location, and install-graph signals to the ad broker. The vendor isn't selling your data on purpose; the SDK is doing it as a side effect of asking for an ad to display. Trust depends on whether the vendor knows that and whether they care.

3. A data buyer pays. The vendor's value isn't the camera app itself — it's the user telemetry harvested by the app. Sold to data brokers (LiveRamp, Acxiom, Epsilon, the long tail of GPS-data marketplaces) and to enterprise customers shopping for "mobile device intent signals." The signals that buyers pay for are well known: precise location, install graph, network identity, device fingerprint, foreground app dwell time, and (for cameras specifically) ambient audio metadata, scene classification, time-of-day usage patterns. The privacy policy clause that authorizes this in the marketplace is almost always some variant of "We may share aggregate data with our partners to improve our service." The "may" does heavy lifting.

4. The developer pays from savings. This is what happens between launch and one of the three above. It is not sustainable. Every cloud-backed free app eventually picks one of (1), (2), or (3) — there are no other options.

If the app you're using has been free for several years, the cloud bill has been paid by someone, and you can usually read the privacy policy and figure out which one. It's almost always (2) or (3), and they often shade into each other.

What changes if there's no cloud bill

Now consider the alternative architecture: the camera-phone runs an embedded HTTP server (or RTSP server, or WebRTC peer) over local Wi-Fi. The viewing device opens a browser tab and connects directly to the camera-phone over LAN. No frame ever leaves the network. Storage is on the camera-phone's flash. Bandwidth is whatever your home router can already do for free.

What does this architecture cost the developer to operate, per active user, per day?

Zero.

The developer doesn't pay any per-user cost because there's no per-user resource being consumed on their side. The user's own hardware and the user's own bandwidth do all the work. The developer's only ongoing cost is the Play Store hosting fee (effectively zero), occasional infrastructure for crash reporting and update delivery, and engineering time for maintenance.

The structural property of this architecture is the developer has no incentive to monetize the user's data, because there's no recurring bill that has to be paid. The free tier can stay free forever. Optional paid features (one-time purchases for advanced functionality) can fund maintenance without needing to find a buyer for telemetry.

This is the architectural property that makes "local-only" apps trustworthy as a category, not as a vendor. It's not that the developer is necessarily a saint. It's that the structural incentive to monetize your data isn't there.

How to tell which camp an app lives in, in two minutes

Settings → Network & internet → Data usage → [the camera app].

A local-only app, running 24/7 with the camera active the whole time, should consume under 50 MB of cellular/Wi-Fi data per day — and most of that is just OS background pings, not the camera itself. The video frames stay on the phone; only the embedded-server LAN traffic uses Wi-Fi (which doesn't count as data on this counter because it never hits your home router's WAN port).

A cloud-backed app, running the same way, will consume between 1 GB and 8 GB per day, because every frame uploads. Even at 720p with aggressive compression, the bandwidth bill is real and the counter shows it.

Megabytes don't lie. The data-usage view is the single most diagnostic check you can do on whether your video is staying home or going on a trip.

What I ship

I build Background Camera RemoteStream — Android, free, no account. It's in the no-cloud-bill camp.

The trust model is structural, not promissory. The architecture is the privacy policy: every frame your camera captures sits on your phone's flash storage. To view the live feed, you open any browser tab on any device on the same Wi-Fi — there's an embedded HTTP server on the camera-phone serving MJPEG frames over LAN. The viewer device doesn't need to install anything. No account, no signup, no cloud relay. We don't ask for Location, Contacts, Accessibility, Phone, or SMS permissions because the architecture doesn't need them.

The optional paid feature is YouTube Live streaming, which uses your YouTube channel directly — Super Funicular LLC is not in the middle of the stream. It's a one-time Pro purchase, not a subscription, because we don't have a recurring server cost we're trying to amortize.

The honest tradeoffs:

No motion alerts — we don't run an ML inference pipeline because that's where most data leaks happen. If motion alerts are non-negotiable, AlfredCamera Premium charges $5.99/month and pays its cloud bill honorably. Worth the money if you need the feature.
No two-way audio — same reason. Cloud relay is the easiest implementation; we don't have one.
LAN-bound by default for off-site viewing — to watch from outside the home, either set up a VPN to your home network (Tailscale and WireGuard both work fine) or use the YouTube Live Pro option.

If those tradeoffs are acceptable, the free tier stays free forever. If they're not, the apps that pay their cloud bill with subscriptions are the honest second-choice.

A few other apps in the same architectural camp

For comparison purposes, these all live in the no-cloud-bill camp and they're all worth knowing about:

IP Webcam (Pavel Khlebovich) — the long-running gold standard since 2011. Free. Less polished UI; same architectural soundness. The two-app comparison most people end up doing is IP Webcam vs Background Camera RemoteStream — full breakdown: Best Free Security Camera Apps for Android (2026).
Haven (Guardian Project) — open-source tripwire/perimeter detection. Different use case (entry detection, not continuous monitoring), but same trust model.
tinyCam Monitor (free Android edition) — pairs nicely on a two-phone setup. RemoteStream serves the LAN stream from the camera-phone; tinyCam runs on the viewing-phone and layers motion alerts on top.

If you want the comparison oriented around the baby-monitor use case specifically — which is the case where the trust model matters most because the camera is pointed at a sleeping infant in a private room — that's here: Best Android Baby Monitor Apps — No Cloud, No Subscriptions (2026).

The single sentence

Free is not a price. Free is a question about who's actually paying.

If the app has a cloud bill, somebody is paying it. The architecture tells you who.

I'm an indie Android developer at Super Funicular LLC. Background Camera RemoteStream is on Google Play here: play.google.com/store/apps/details?id=com.superfunicular.digicam. The website is superfunicular.com. If you want to talk architecture, I'm on dev.to @superfunicular.

This week on @Digital_Nomad_Media — 13 new clips (2026-W20)

Super Funicular — Sun, 17 May 2026 14:03:31 +0000

Quick weekly digest from my YouTube channel — every clip below is fresh in the last 7 days.

Dog consultant

21s

Never F#@k'in Mind 🤣✌️

11s

Was that a UFO? ✌️🎅

Just peel it quick! ✌️🤠

16s

Welcome Back! Dog Park America ✌️🤠

74s

I say, I say young dog! ✌️🤠

194s

Belleville Illinois invaded by ICE monster named Digi Nomad

247s

I couldn't bear to stop him so I just gave him the truck ✌️🤠

18s

It's a Dog Gone adventure we're on

220s

Me and my dogs were STRANDED on this island for five years ✌️🤠

258s

All hail Buddy Rowe

273s

On the trail of ???? ✌️🤠

325s

Changing transmission fluid in a 2013 Ford C-Max #cmax #c-max #ford #hybrid ✌️🤠

I also built an app — DigiCam

I also made DigiCam, listed as Background Camera RemoteStream on Google Play. It's the world's first screen-off YouTube live streaming app: stream live with the screen off for ~10× the battery life, plus background recording, remote web console control, file-based YouTube Live, and playlists. Privacy-first, all local storage. Free with ads or Pro for the full feature set:
https://play.google.com/store/apps/details?id=com.superfunicular.digicam

Watch the full channel: @Digital_Nomad_Media

Tags: #SuperFunicular #DigiCam #LadyThePitbull #DigiNomad #YouTubeShorts #ContentCreator #dogpark #dogs #travelvlog #puppies

Texas Says 'Netflix Watches You' — Why I Built My Camera App to Be Structurally Incapable of It

Super Funicular — Fri, 15 May 2026 08:06:09 +0000

On May 11, the Texas Attorney General filed suit against Netflix. The complaint's core accusation, in plain English: Netflix has been quietly building advertising profiles from what users watch, pause, rewind, and search — including children — while telling the public it does not. The lawsuit specifically cites Reed Hastings's 2020 statement that Netflix "doesn't collect anything" and points to the company's pivot to ad-tech as evidence the public was misled. Coverage: Time, CNBC, Variety, Malwarebytes.

I'm not writing this to dunk on Netflix. I'm writing it because the lawsuit names the exact structural failure mode I tried to design my way out of when I built Background Camera RemoteStream.

The architectural diagnosis hiding inside this lawsuit

Cloud-by-default products collect by default. That isn't a policy choice that can be paper-over with a privacy page — it's a property of the architecture. The moment a stream of user behavior crosses the network to a vendor-owned server, three things become technically inevitable: the data exists somewhere outside the user's control, it can be joined with other data on that server, and it can be repackaged for advertising whenever the business model demands it.

The Texas complaint reads like an architecture review. It says Netflix tracks "viewing activity, searches, location data, pauses, rewinds, and other behavior" to build profiles "shared across the broader ad-tech ecosystem." Note what is missing from that sentence: any specific malicious decision by an engineer. Each of those signals is generated as a side effect of running a streaming product whose backend has to know what the player is doing in order to keep playing it. Once they're on a server, they're collected, whether or not anyone intended to collect them in the consumer-protection sense. Opt-out flows are a UI fiction layered on top of that fact.

This is the trap I wanted to avoid for a camera app — because of all the categories of data on a phone, "what does the camera see and hear" is the worst possible thing to architect around a cloud.

Why I made the design call to keep everything local

Background Camera RemoteStream is a background-recording, screen-off-streaming Android camera. It records when the phone is locked, streams to a local network or to YouTube Live, and never asks for a cloud account.

The architecture is deliberately uncomfortable for any future business model that depends on selling user behavior:

No account system. The app does not have a sign-up flow. There is no userId for analytics to key off of, because there are no users in the database sense — there is only a phone, holding a file.
No cloud storage. Every recorded clip is written to the device. The app does not upload, mirror, or sync. If you uninstall it, your footage is wherever Android's MediaStore put it.
No third-party analytics SDK. Most "free" apps fund themselves by sending behavior to Firebase, Mixpanel, Amplitude, AppsFlyer, or some combination. We don't. There is no analytics endpoint to disable, because there is no analytics endpoint.
Streaming is peer-to-peer. When the app streams over the local network it serves frames directly from an embedded Ktor server on the phone — so the receiver is a browser on your laptop, not a relay in our datacenter. When it streams to YouTube Live, the frames go to YouTube; they do not pass through a Super Funicular intermediary.
The crash logs are sparse and on-device. Diagnostic info that exists at all is what Android's stock crash mechanism keeps locally. We don't ship telemetry off the phone.

Some of these are not "best practice" by any 2020s indie-dev playbook. The conventional wisdom is "you can't grow without analytics." But the moment you accept analytics, you accept a server that knows what users do. And the moment you have a server that knows what users do, you have written the first line of a complaint a state AG can file against you in 2030.

What the Texas lawsuit makes easier to say

I have been pitching the local-only architecture for almost a year, and the most common reaction from non-technical users is some version of "surely they all do that?" — "all" being the cloud cameras, the smart doorbells, the social streaming apps. There has been a quiet consumer assumption that the collection is fine, because the brand on the box is trustworthy.

The Texas filing is going to make that assumption harder to hold. The lawsuit is not against an obscure ad-tech company; it's against the household-name streaming service whose CEO publicly said it didn't do this. The complaint alleges $10,000-per-violation penalties under the Texas Deceptive Trade Practices Act and asks the court to require Netflix to delete data and disable autoplay for children's accounts by default.

For builders, the message embedded in that filing is simple: the privacy promises you make on the marketing page are now legally interesting. If you say you don't collect, your architecture had better not collect. If your architecture collects, the marketing-page promise is the lawsuit-ready evidence the AG will cite.

The way out of that exposure is not a better privacy policy. It is to not be able to collect the thing in the first place — to put it on the device, leave it on the device, and stay out of the network path. You cannot be subpoenaed for what you don't have.

What I'd tell another indie builder

Pick one piece of user data your product touches and ask: if this ever gets cited in a complaint, what would I want my architecture to look like? That's the design constraint. Then work backwards from it. Most apps can't take this all the way to "no cloud" because they need server-side features, but almost every app can reduce its collection surface meaningfully. The local-only choice I made for camera footage is the strictest version, available because cameras are a category where the phone is genuinely capable of doing the whole job.

I built the app on this thesis. The Texas lawsuit reads, to me, like a 65-page validation of it.

If you want to see what a privacy-first Android camera looks like when the architecture matches the marketing, Background Camera RemoteStream is free on Google Play — and the project's home is at superfunicular.com.

1.1 Million Baby Monitors Were Watchable by Anyone — Here's the Architectural Mistake Behind It

Super Funicular — Tue, 12 May 2026 08:04:32 +0000

On May 11, 2026, The Verge and PetaPixel reported that researcher Sammy Azdoufal had remotely accessed roughly 1.1 million network-connected baby monitors and security cameras made by Chinese white-label vendor Meari Technology — across 118 countries, by extracting a single key from the company's Android app.

"Just by inspecting the Android app, Azdoufal says he was able to extract a single key that gave him access to devices across 118 countries."
— The Verge via PetaPixel

Photos from those cameras were stored on Chinese Alibaba servers with public web addresses and no protection. The same backend infrastructure is reportedly used by 378 different brands sold under different names on Amazon and at retailers like Leroy Merlin. The primary hole has been patched. The architectural mistake that produced it has not.

I build an Android app called Background Camera RemoteStream (superfunicular.com). It is a structural alternative to the cloud-camera model that just failed for the millionth time. I want to talk about why this keeps happening, because "another IoT camera got hacked" is not a useful framing — and neither is "buy a more expensive one."

What actually broke

Three things, stacked:

A shared key inside a public client. The Android app ships with credentials that authenticate against a central broker. If you have the app, you have the key. Reverse-engineering an APK is not hard. Researchers do this for breakfast.
An MQTT broker that trusts the key. Once you have it, you can subscribe to message topics belonging to devices that aren't yours. Meari's spokesperson described it carefully: "Under specific technical conditions, attackers may intercept all messages transmitted via the EMQX IoT platform without user authorization." Translation: the broker authenticated the app, not the user.
Cloud-side photo storage with public URLs. Saved snapshots lived on Alibaba object storage with predictable, unprotected addresses. Per-photo authorization wasn't enforced; knowing the URL was the access control.

Each layer is fixable in isolation. What is not fixable in isolation is the structural decision underneath all three: the device is a thin client, and the cloud is the camera. Every byte of the video, every snapshot, every event has to go to a vendor-controlled backend so the vendor's app can pull it back down. That backend becomes a single point of compromise for every device that ships under every one of the 378 brand names that resells the same firmware.

This is not unique to Meari. The same researcher pulled the same trick on 7,000 DJI robot vacuums in February of this year. It is the predictable failure mode of "cheap IoT camera that streams to an app." The bug bounty changes; the architecture doesn't.

The thing the architecture is optimizing for

Cloud-relay cameras exist because they solve a real product problem: you want to see the feed when you're not on the same Wi-Fi as the camera. NAT, dynamic IPs, mobile network restrictions — punching through all of that with a vendor-run relay is genuinely easier than asking users to configure port forwarding.

The cost is that the vendor must store, decrypt-or-not, and route everyone's video, forever. The vendor's employees can in principle look at your living room. The vendor's API keys can be extracted from the public app. The vendor's backend can be breached. The vendor can be acquired or shut down or pressured by a government.

If you only ever needed your own feed on your own network, you paid the entire cost of a centralized backend so the vendor could give you back the thing you started with.

What "local-only" actually looks like

Background Camera RemoteStream takes the other branch:

No vendor cloud. Recordings are stored locally on the Android device acting as the camera. There is no Meari-style backend that proxies your video. There is nothing for me, the developer, to leak — because nothing of yours ever reaches me.
No account. There is no email, no password, no shared key against a central broker. There is no database of users for an attacker to dump.
No third-party hardware vendor. The "camera" is an old Android phone you already own. The supply chain ends at your drawer.
Streaming, when you want it, is YouTube Live on your channel. If you want a remote feed, you authenticate to your Google account and stream to your YouTube channel — same auth surface as the rest of your YouTube use, controlled by you, revocable by you, gone the moment you stop the stream. There is no superfunicular.com relay between you and the viewer. Even I cannot watch it without your channel link.
Screen-off recording. The camera phone runs with the display off so it can sit on a shelf for days without burning the screen — the local-only model has no extra cost here.

This isn't a marketing checklist. It is a different threat model. The Meari breach exists because there is a server that can be breached. We do not run that server.

What this does not solve

A local-only camera does not protect you from:

Someone on your home Wi-Fi who already has device access. If an attacker is already inside your LAN, neither architecture saves you. Network hygiene still matters.
Physical access to the camera phone. If someone walks off with the device, the recordings on it are theirs.
Misconfigured streaming. If you start a YouTube Live and make the link public, the feed is public. That is a property of the choice to broadcast, not the architecture.

I'm not claiming the local-only model is invulnerable. I'm claiming it does not have the specific failure mode that just exposed 1.1 million homes through a single extracted key, because there is no central server to extract a key against.

The 378-brand problem

The most uncomfortable detail in the report is that 378 different camera brands sit on top of the same Meari backend. Consumers buying a "different" camera at a retailer were buying the same vulnerability. The brand name on the box told them nothing about what their feed was traveling through.

When the architecture is centralized and white-labeled, the brand on the box is decorative. The relevant question is "whose servers does this talk to," and the box almost never tells you. With a local-only Android app, the answer is: only your device, plus whatever streaming destination you explicitly point it at. That is auditable in a way that a stack of unnamed Chinese MQTT brokers is not.

If you have a Meari-derived camera right now

Per The Verge's reporting, the primary vulnerability has been patched, but Meari has not disclosed which brands are affected or whether the Chinese server with ~220,000 still-exposed users has been fully closed. Practical steps:

Check whether your camera's app routes through Meari or one of the related rebrands. The companion app name and developer-of-record on Google Play is often the easiest tell.
Rotate any credentials you've reused across IoT apps. Shared-key extractions tend to publicly cluster after disclosure.
If you don't strictly need remote access from outside your home, consider an LAN-only or local-only setup. If you do need remote access, prefer architectures where you hold the relay keys (e.g., your own YouTube channel, your own VPN) over architectures where a vendor does.

That last point is the whole pitch. Background Camera RemoteStream is on Google Play, free, no account, local-only by default, optional YouTube Live to your own channel. If the Meari story made you uncomfortable, that discomfort is a signal worth following — not toward a more expensive camera, but toward a smaller blast radius.

Google Just Turned On Binary Transparency for Android — Why Privacy-First Indies Should Cheer

Super Funicular — Sun, 10 May 2026 08:03:25 +0000

On May 1, 2026, Google quietly flipped a switch that will reshape how the Android software supply chain is trusted. Every Google-published Android app released after that date now has a corresponding cryptographic entry on a public, append-only ledger — a system called Android Binary Transparency. The Hacker News and Help Net Security covered the rollout this week, and Google's own Android Developers Blog confirmed the company is "actively working to extend Binary Transparency to third-party developers."

For users, this is great news. For independent privacy-first developers like us at Super Funicular, it's even better — and here's why.

What Binary Transparency actually does

A digital signature has always told you who signed an app. Binary Transparency tells you what was signed, when, and lets anyone in the world verify it after the fact.

The mechanism comes straight out of the Certificate Transparency playbook the web uses to catch rogue HTTPS certificates. Every binary Google ships is hashed, the hash is published to a public Merkle-tree log, and the log is append-only — you cannot quietly remove or rewrite an entry. If a Google account were ever compromised and a malicious build were pushed under a legitimate signing key, the rogue binary's hash would still have to land in the public log, where independent monitors would spot it within minutes.

That's the whole point. Signatures prove origin. Transparency proves intent. The two together make a stealth supply-chain attack — the kind that has plagued npm, PyPI, and the broader open-source ecosystem for years — dramatically harder to pull off.

Source: Google's Android Apps Get Public Verification to Stop Supply Chain Attacks (The Hacker News, May 2026) · Google expands Android Binary Transparency to counter supply chain attacks (Help Net Security, May 6, 2026)

Why the timing matters

Google didn't roll this out in a vacuum. The last six months on Android have been rough:

PromptSpy — the first known Android malware that abused on-device generative AI to read a victim's screen, distributed as a fake banking app (ESET, February 2026).
Keenadu — a backdoor baked into the core software of certain Android tablets, loading itself into every app launched on the device (Kaspersky; >13,700 victims across Russia, Germany, Japan, and Brazil).
The McAfee Play Store sweep — over 50 malicious apps with a combined 2.3M+ installs, slipping past Google's initial review and shipping rootkits that overwrote system libraries.

Each one is a reminder that "I downloaded it from the Play Store" is no longer a sufficient guarantee of safety. Binary Transparency is Google's structural answer: even if the review process misses something, the public ledger gives security researchers an audit trail they can interrogate forever.

Why privacy-first indies especially benefit

Here's the part the trade-press coverage has mostly missed.

When the trust signal for Android shifts from "this app is on the Play Store" to "this app's binary is on a public, verifiable ledger," the playing field tilts toward developers who have nothing to hide in the binary itself. That favors small, independent, privacy-first apps for three reasons:

Smaller surface area to verify. A 12 MB camera app with no third-party SDKs, no analytics, and no ad networks is dramatically easier for an outside reviewer to reproduce, compare against the published hash, and vouch for than a 200 MB app with a tangled web of bundled libraries. Indie privacy apps tend to ship lean binaries on purpose — that turns out to be a verification superpower.
No remote-config trickery. The most pernicious supply-chain attacks involve apps that look benign on first install and then fetch malicious code or configs after the fact. Apps that store everything locally and don't phone home don't have that attack surface to begin with.
The ledger is forever. When a privacy-first dev publishes a clean build, that record is permanently public. Over time, a long history of clean entries becomes a portable reputation no platform can take away from you.

For us, this aligns almost too perfectly with what we've been building. Our Android app, Background Camera RemoteStream, was designed from day one around the principle that the app shouldn't see, store, or transmit anything the user didn't explicitly ask it to:

Recordings live locally on the device. There is no cloud bucket, no developer S3 we could be subpoenaed for, no telemetry pipeline.
No account required. No email, no signup, no identifier we couldn't lose if we wanted to.
No third-party trackers. What goes in the APK is what runs.
Optional YouTube Live streaming for users who explicitly want a remote feed — the default is private and offline.

When binary transparency expands to third-party developers (Google has signaled this is the intent), an app like ours has a very simple story to tell a verifier: "Here's the hash. Here's the source-equivalent build. Compare them. There's nothing in between."

You can install Background Camera RemoteStream from the Play Store here: play.google.com/store/apps/details?id=com.superfunicular.digicam

What to watch next

A few things worth keeping an eye on over the next 90 days:

September 2026 enforcement. Google has separately announced that, starting in September, apps in select regions must be registered by a verified developer to be installed on certified Android devices. Verification + transparency are the two halves of the same trust model.
Third-party rollout timeline. The Android Developers Blog has confirmed the intent to extend Binary Transparency to non-Google apps, but the timeline isn't public yet. When it lands, expect a meaningful divide between developers who opt in early and those who drag their feet.
Independent monitors. The web's certificate-transparency ecosystem only became useful once third parties started running their own monitors. The Android version will only be as strong as the watchers who watch the log.

The bigger picture

For years, "privacy-first" has been treated as a marketing claim — a vibe, a developer's promise. Binary Transparency starts to make it auditable. That's a quietly enormous shift, and it favors exactly the kind of small, independent, no-tracker, no-cloud apps that have been the unsung good actors of the Android ecosystem all along.

We'll take it.

Best Apps to Turn Your Old Phone Into a Doorbell Camera in 2026 (Free, Privacy-First, No Subscription)

Super Funicular — Sun, 10 May 2026 06:10:00 +0000

A video doorbell is one of the easiest cases to argue for a smart-home upgrade — you want to know who is at the door, you want a clip when something arrives, and you want to be able to look at the porch from your phone without driving home. The hardware industry has answered with a Cambrian explosion of brands: Ring, Nest, Eufy, Aqara, Reolink, Arlo, Wyze, Blink, and a hundred white-label clones on Amazon. Almost all of them want $80–$250 up front and $30–$100/year for cloud video storage.

If you have an old Android phone in a drawer — and most of us do — you already own a better doorbell than what Amazon will ship you. That phone has a 12 MP camera, a microphone, dual-band Wi-Fi, USB-C continuous power, and a CPU that is roughly six times more powerful than the SoC in a $200 Ring. The thing it does not have is doorbell software. That is what this article is about.

Below is a real, honest comparison of the five Android apps that can credibly turn that drawer phone into a doorbell. The apps differ on four axes that matter for a doorbell specifically: continuous recording with the screen off, local-only storage, the cost of a "ring" notification, and how the app handles the live feed when you're at work. We rank them in that order, and the verdict is at the bottom.

Heads-up before we start: every Play Store link in this article uses the correct package id com.superfunicular.digicam for our app — we'll come back to why that matters in the privacy section.

What "doorbell" actually requires

Before the comparison, let me be specific about what a doorbell-mode app needs to do. A doorbell is a recording device with three jobs:

Stay on continuously while plugged in. The most common phone-cam failure mode is screen-on requirement — the moment you tap home or the screen times out, the camera stops. A doorbell that stops the moment the screen sleeps is just an annoying selfie cam.
Capture motion at the door, not the entire neighborhood. Most phone-camera apps point a 27 mm equivalent lens at the door from 18 inches away — that gives you a good enough frame, but you need to know that the recording is actually happening without picking up the phone every five minutes.
Show you the feed without exposing your home network or selling your video to the cloud. This is the part Ring is bad at.

Apps that fail on (1) — screen-off continuous recording — are out of contention. Two of the apps below pass and three fail. Apps that fail on (2) — recording without a manual tap — are also disqualified for this use case. And apps that fail on (3) — sending the doorbell stream to a third-party cloud — are technically useful but introduce a privacy tax that defeats the point of using your old phone in the first place.

#1 — Background Camera RemoteStream (Super Funicular LLC)

Free. No subscription. Local-only. No account.

Background Camera RemoteStream is the only app on this list that was built specifically around the screen-off recording case. It records continuously while plugged in, with the display fully off, while a foreground service notification keeps Android's Doze and App Standby modes from suspending the camera pipeline. That is the single most important capability for a doorbell — and it is the one most repurposed phone-cam apps either don't ship or charge for behind a paywall.

Three things specifically matter for the doorbell case:

Screen-off continuous recording. You can mount the phone face-out at the door, press the lock button, and the camera keeps recording. No flicker, no preview wasted on the screen, no battery drain from the display. The signature feature.

Local web server for viewing. The app runs a small embedded HTTP server (Ktor) on the phone's Wi-Fi network. You open http://<phone-ip>:8080 from any browser on your home Wi-Fi — your laptop, your work phone, a Raspberry Pi, anything with a browser — and you see the live doorbell feed. Because the server only listens on the LAN, the video never leaves your home. This is what "no cloud" actually means in practice; the data path is phone → router → laptop, full stop.

Optional YouTube Live for remote viewing. If you want to watch the doorbell from a coffee shop, you can flip the YouTube Live switch and the stream goes out to YouTube as a private/unlisted stream. You're using YouTube's CDN as your remote-viewing pipe instead of paying $30/month to Ring. (See Best Apps to Stream YouTube Live From Your Android Phone in 2026 for the YouTube setup details.) The feed never lives on Super Funicular's servers because Super Funicular doesn't have any.

Pros

Truly free (not free-with-ads, not free-tier-with-paywall)
Records with the screen off — the default mode is the doorbell mode
Local-only by design; no account required, no email, no signup
Embedded web server for any-browser viewing on the LAN
YouTube Live for remote viewing if you want it
All recordings stored on the phone's own SD card / internal storage
Open-ended use — can be re-pointed at a pet bowl, a workshop bench, a baby crib without unlocking a different "mode"

Cons

No motion-trigger event log out of the box. The doorbell records continuously rather than capturing 30-second motion clips like Ring does. (Honest tradeoff: continuous recording is more reliable, but it is more storage and more video to scrub through.)
No two-way audio (the phone's mic records, but there is no live "speak through the doorbell" feature). If you need to actually answer the door from your phone, that is a limitation.
No motion-zone configuration. The whole frame is the recording area.

Verdict: If you mostly want continuous video of who came to the door and an easy live view from your laptop, this is the only app on the list that gets all three doorbell jobs right with no asterisks. Get it on Google Play: Background Camera RemoteStream.

#2 — Alfred Camera

Free with ads + paid Premium tier ($30/year).

Alfred Camera is the most popular phone-as-security-camera app on the Play Store, and for good reason — it has been around for years, the team behind it ships consistently, and the basic experience is polished. As a doorbell, however, it asks for a tax that the others on this list don't.

What works: The setup is the smoothest of any app in this comparison. Install on the doorbell phone, install on your viewing phone, sign in with the same account, and you have a paired feed within ninety seconds. Motion detection triggers a clip and a push notification, which is closer to the Ring experience than what Background Camera RemoteStream offers out of the box.

What doesn't: Alfred Camera is fundamentally a cloud product. The clips and motion events are routed through Alfred's servers. The free tier is ad-supported (you'll see ads in the viewer app), recording resolution is throttled (HD is paywall), motion-zone configuration is paywall, and clip storage is limited. It is not "free" in the way that costs you nothing; it is "free enough that most people don't bother to upgrade."

Pros

Polished, low-friction setup
Motion detection + push notification on the free tier
Cross-platform viewer (iOS + Android + browser)
Active developer presence

Cons

Cloud-based (your doorbell video is on Alfred's servers, not yours)
Free tier has ads in the viewer
Most useful features (HD, zones, longer clip retention) are behind a $30/year paywall
Account required — you cannot use it without signing up
Pulls regular telemetry; not the right pick if you care about privacy on a porch camera

Verdict: A reasonable choice if you don't mind cloud storage and an account. Less of a fit if "no subscription, no signup" is what you came here for.

#3 — AtHome Camera

Free with ads + paid tier (no subscription, one-time $4.99 unlocks).

AtHome Camera is the closest functional analog to Alfred Camera but with a slightly different business model and a slightly stripped-down feature set. It is a paired app: install AtHome Camera on the doorbell phone, install the AtHome Video Streamer companion on your viewing phone, link them with a code, and you have a feed.

What works: No mandatory subscription. The motion-detection feature is on the free tier with a usable clip retention window. There is a cross-platform Windows/macOS viewer, which is helpful if you want a permanent monitor at a desk PC. Setup is reasonably straightforward.

What doesn't: The viewer app pushes ads pretty aggressively on the free tier. The video relay is cloud-routed even though clip storage is local-ish, which means the feed travels through AtHome's relay servers — privacy-equivalent to Alfred. Account setup is required. App stability has been hit-or-miss in long-running configurations (the doorbell case is exactly a long-running configuration).

Pros

One-time payment instead of monthly subscription
Desktop viewer available
Reasonable free tier

Cons

Cloud relay for the live feed
Heavy ads on free tier
Account required
Long-running stability less reliable than Alfred or our app

Verdict: A middle ground. If you specifically want a desktop viewer and you're willing to spend $5 once, it has a niche. As a privacy-first doorbell, no.

#4 — IP Webcam (Pavel Khlebovich)

Free. No account. Local-only. Old-school.

IP Webcam is the spiritual ancestor of every "phone as IP camera" app and is genuinely free, no signup, with a local-only HTTP stream. It has been around for over a decade and has earned a real fan base among people who run home automation setups.

What works: Like Background Camera RemoteStream, IP Webcam exposes a local web server with the live feed and recordings — the architecture is similar. It has been the go-to for "I want to see my Android camera in Home Assistant" use cases for years.

What doesn't: The screen-off recording case is where IP Webcam has historically been weak. The default behavior on modern Android (12+) is for the camera to stop or degrade quality when the screen is off, because IP Webcam was designed before Android's foreground-service / Doze rules tightened. There are workarounds (battery optimization disable, foreground service options) but they are not the default setup, and a doorbell needs to work from defaults if a non-developer is going to set it up. The UI is also showing its age — it looks like an Android 4 app and it is hard to find settings.

Pros

Free, local-only, no account — the right values
Decade of stability for the basic use case
Strong Home Assistant / DIY home-automation integration

Cons

Screen-off recording requires manual configuration on modern Android; not the default
Aging UI
Reportedly higher battery use than newer purpose-built apps
No YouTube Live built-in
Less actively developed than the leaders

Verdict: For a homelab user who wants a Home Assistant-friendly local-only stream, IP Webcam is fine. For a doorbell that needs to "just work" with the screen off when a non-technical household member sets it up, the screen-off gap is the dealbreaker.

#5 — WardenCam

Free with ads + paid tier ($24.99/year).

WardenCam is a polished phone-pair security camera app with a Google Drive integration that lets you store motion clips in your own Drive instead of the developer's cloud. It has a small but loyal user base and the developer is responsive.

What works: The Google Drive integration is genuinely interesting — it sidesteps the "trust the app developer's cloud" problem by letting you put the clips in storage you already control. Motion detection works, the viewer app is decent, and the free tier is functional.

What doesn't: Like Alfred and AtHome, WardenCam routes the live feed through a relay. Like everything except #1 and #4, it requires an account. The free tier is ad-supported and the feature gates are aggressive enough that the practical experience pushes you toward the $25/year tier. Battery efficiency in continuous mode is mediocre.

Pros

Clip storage in your own Google Drive (the most novel choice on this list)
Reasonable, affordable paid tier
Cross-platform viewer

Cons

Cloud-relayed live feed
Account required
Ads on free tier
Aggressive paywalls on the experience-improving features

Verdict: If you specifically want motion clips in Google Drive and you don't mind the relay, this has an angle no one else has. As a privacy-first option, no.

Side-by-side comparison

App	Cost	Records w/ screen off (default)	Local-only feed	Account required	Motion detection	YouTube Live	Privacy verdict
Background Camera RemoteStream	Free	Yes	Yes	No	Continuous (no event log)	Yes	Best
Alfred Camera	Free / $30/yr	No (relays through cloud)	No	Yes	Yes	No	Cloud
AtHome Camera	Free / $4.99 once	Partial	No	Yes	Yes	No	Cloud relay
IP Webcam	Free	Manual config required	Yes	No	Yes (motion logging)	No	Local but old
WardenCam	Free / $24.99/yr	Partial	No (relays)	Yes	Yes	No	Cloud relay (Drive for clips)

Why the local-only architecture matters for a doorbell specifically

A doorbell is the camera with the worst privacy properties of any camera in your home. Every visitor — the mail carrier, your neighbor, a delivery driver, a kid selling cookies, a date — is captured by it. A nanny cam in a closed bedroom captures three people; a doorbell captures three thousand a year.

If that camera is cloud-relayed, every one of those captures traverses someone else's server. The 2024-2025 wave of camera-cloud breaches (Wyze cross-account video exposure in 2024, Ring's law-enforcement-handover policy reversal, the Be Prime breach we covered in When the Camera Cloud Becomes the Attack Surface) is the practical demonstration of the architecture failure: cloud-managed camera fleets create a pooled target. Every additional camera on the platform increases the value of breaching the platform once.

A local-only doorbell — the kind Background Camera RemoteStream and IP Webcam make possible — does not have that property. The video never leaves the LAN. Even if the developer of the app is breached, your doorbell footage is not in the breach because the developer never had it. The blast radius of a compromise is your one phone, not a million phones.

That is the privacy argument, and for a doorbell specifically it is sharp because the doorbell sees more strangers than any other camera you own.

Practical doorbell setup — the part the comparison doesn't tell you

Once you've picked an app, the configuration questions are the same regardless of which one you used. A few of them are non-obvious:

Power. A doorbell phone needs to be plugged in 24/7. If you keep the battery at 100% with USB-C continuous power for a year, you will degrade the battery aggressively (lithium-ion batteries hate being kept at 100%). The fix is to set a charge limit at 80% in Android's battery settings (most modern Android phones support this; check Settings → Battery → Charging optimization). This is the same trick we covered in Why Your "Old Phone Security Camera" Dies After 4 Hours (And How to Fix It on Modern Android) — a doorbell shares the battery-management problem with any 24/7 phone-camera setup.

Lens position. A 12 MP phone camera at 18 inches from the door produces a wider frame than a 27 mm-equivalent doorbell, but a slightly worse low-light frame. If your porch is dim at night, the trick is the porch light (5–10 lumens of warm light is enough to give a phone camera a usable frame; "smart" doorbells use IR LEDs because they don't have any other choice). A constant porch light is a cheaper IR-equivalent than the HDR sensor in a Ring.

Mounting. A 3D-printed phone mount, a strong magnetic mount, or a low-tech adhesive mount on the inside of a window all work. The window mount is by far the easiest because it eliminates the weather sealing problem entirely — the phone is on the inside of the glass and gets a clean view of the porch without any environmental exposure. We have not yet seen a phone-as-doorbell setup that goes outdoor without weather-sealing it, and we recommend not trying.

Audio consent. If your doorbell records audio (and most of these apps do by default), check your jurisdiction's two-party consent rule for audio. In some U.S. states (California, Florida, Pennsylvania, Washington, plus several others) recording audio of a conversation requires both parties' consent. Most home-doorbell videography is fine because there is no conversation happening, but a doorbell that picks up sidewalk conversation is a different question. If you are worried, mute the audio in the app (Background Camera RemoteStream lets you turn audio off without losing video).

Verdict

For "old Android phone → doorbell, free, no subscription, no signup, no cloud," the honest stack ranks like this:

Background Camera RemoteStream — the only app with screen-off continuous recording as the default, local-only feed, no account, and YouTube Live as an optional escape hatch. The doorbell case is what it was designed for.
IP Webcam — local-only and free, but the screen-off case is a manual-config problem.
Alfred Camera — the polished cloud option, fine if cloud is fine for you.
WardenCam — the Google-Drive-storage option, niche.
AtHome Camera — middle of the pack, fewer reasons to pick it.

If you want to stop renting your porch surveillance from a hardware company, install Background Camera RemoteStream from Google Play on the phone in your drawer, point it at the door, plug it in, and that is your doorbell. We have written about how to mount and configure an old phone as a free home security camera if you want a full setup walkthrough; that piece is the prequel to this one.

The hardware to make a doorbell already exists in your house. The software to make it actually work is free.

Background Camera RemoteStream is built by Super Funicular LLC. Free on Google Play. No account, no subscription, no cloud.

Build-in-Public Week 1 — 35 Articles, 185 Views, First Bookmark, First Bluesky Follower, and the Pareto in a Flat Chart

Super Funicular — Sat, 09 May 2026 07:12:06 +0000

Build-in-Public Week 1 — 35 Articles, 185 Views, First Bookmark, First Bluesky Follower, and the Pareto in a Flat Chart

This is the Friday field report for Week 1 of public marketing on Background Camera RemoteStream — a privacy-first Android camera app that records with the screen off, streams to YouTube Live, and never phones home. Three days ago I posted Part 2 of the build-in-public series — the philosophical month-one retrospective. This post is the boring tactical sibling. The data, the experiments, what is queued for Week 2, and what I am no longer doing.

If you are an indie hacker keeping a public scoreboard, this is the format I have settled on.

The Friday-of-Friday scoreboard

The cumulative numbers as of this morning, sourced from the actual dashboards (no rounding, no projection):

Channel	Volume	Engagement
dev.to	35 articles	185 cumulative views, 2 reactions, first ever bookmark today, 4 followers
X / Twitter	~59 tweets	0 followers, blue-check active, first verified-account reply chain today
Bluesky	33 posts	4 cumulative likes, first ever follower today (mutual)
Quora	15 answers	First-position SERP slot today, 1 organic follower captured this week
LinkedIn	Profile only	0 posts shipped
Reddit	Account only	API approval still pending

The headline reading: the flow is moving in the right direction even when the flat numbers look like nothing. Three "first ever" milestones landed in a single day this week. None of them showed up in the article-view chart, because they happened on platforms that are not dev.to.

The Week 1 ship log

Every dev.to article published this week, in order, with archetype and the day's gate:

Date	Archetype	Title (abbrev)	id	Gate / fate
May 2 (Sat)	A	Best Free Nanny Cam Apps for Android in 2026	3598582	+20 views in the 24h after publish — caught a feed wave
May 2 (Sat)	NJ	ClayRat Trojan — Privacy-First Camera Architecture	3599501	Day-1: 0 — first newsjack to hit the ceiling
May 2 (Sat)	C	Why Your Old Phone Security Camera Dies After 4 Hours	3601469	Day-1: 1 — confirmed C archetype is structurally weak
May 2 (Sat)	NJ	NoVoice Rootkit Hit 2.3M Android Devices	3601479	Day-1: 0 — second newsjack ceiling
May 3 (Sun)	D	Monitor Your Dog While You Are at Work for Free	3602874	Day-1: 6 — D archetype average held
May 3 (Sun)	NJ	When the Camera Cloud Becomes the Attack Surface — Be Prime	3603034	Day-1: 1 — third newsjack ceiling, throttle confirmed
May 4–5 (Mon/Tue)	—	DEV.TO PUBLISHING THROTTLE	—	Hard pause — no new posts
May 6 (Wed)	E	How I Built a Production Android App — Part 2	3619147	Day-2 verdict: still throttled (0 views @ 48h)
May 6 (Wed)	C	The Architecture Behind a $0 Security Camera	3619879	Day-2 verdict: still throttled (0 views @ 48h)
May 7 (Thu)	aux	Weekly clip post (Digital Nomad Media)	3623990	Out of main publish cadence

The most important entry on the ship log is the row that says DEV.TO PUBLISHING THROTTLE. I will get to it.

Cumulative dev.to footprint as of this morning: 35 articles, 185 cumulative views, 2 reactions, 1 bookmark (the first one ever, landed today), 4 followers. The first reaction landed on id 3590177, a build-in-public sibling post from late April. The first bookmark landed today, on the same archetype family. Both signal-bearing engagements in the catalog have come from build-in-public posts. That is not random.

The 24-hour doubling — and the flat 48 that followed

The single most counterintuitive number from this week: dev.to total views went from 67 → 133 in a 24-hour window between May 2 and May 3, then climbed steadily to 185 by May 7, then went flat for the next 48 hours. The catalog roughly tripled its lifetime view count in five days, then stalled.

Crucially, the May 2–3 growth did not come from new posts. The pieces published in that window (the two newsjacks and the use-case sequel) added roughly 0–6 views each. The growth came from the existing catalog:

id 3592937 ("Best Apps to Stream YouTube Live") +20 views in 24h
id 3598582 ("Best Free Nanny Cam Apps for Android") +20 views in 24h
id 3590206 ("Turn Your Old Android Phone Into a Free Security Camera") +22 views over the week, +10 more in a single 24h window mid-week
id 3592840 (a comparison-list piece) +10 views in a single 24h window

These are 4–7 day old pieces finally getting feed pickup or organic search hits. They are working precisely because they are no longer new. The lesson: dev.to view curves on this account are bimodal — a small day-1 burst, then a 4–7 day gap, then a second wave. If I had judged any of these pieces by day-1 views I would have killed all of them.

The pattern is now baked into the calendar: every archetype gets at least 72 hours before being judged, and 7 days before being demoted.

The archetype Pareto, after a full week

Tagging every piece with its archetype turned out to be the highest-leverage thing I started doing in week one. The averages have stabilized enough to publish:

Archetype	Pieces	Cumulative views	Avg / piece
Build-in-Public (E)	2	~35	17.5
Use Case Showcase (D)	6	33	5.5
Comparison List (A)	13	60	4.62
Newsjack (NJ)	4	1	0.25
Technical Deep-Dive (C)	8	4	0.5
Dramatic Story (B)	1	n/a	n/a (not validated)

Build-in-Public is averaging 35× the views of Technical Deep-Dive despite being the cheaper format to write. Comparison Lists looked like the worst-performing archetype 24 hours after publish (1.6 avg) and tripled to 4.62 by day three — saved from being demoted by the bimodal-distribution rule above. Build-in-Public is also the only archetype that has produced both reactions in the catalog and the first bookmark.

The operational consequence: the Week 2 calendar adds +1 E and +1 D in weekday slots, keeps Comparison Lists on weekend slots for the 72-hour SERP runway, and quietly drops Technical Deep-Dive from any standalone slot until it earns its way back. Newsjacks are paused until Monday May 11.

The newsjack throttle — and why it has not lifted

Three consecutive newsjacks (ClayRat, NoVoice, Be Prime) hit identical 0–2 view ceilings inside 48 hours, while four-day-old articles continued to rack up views. The most parsimonious explanation: dev.to has a per-account feed-volume throttle, and I tripped it by publishing 30+ articles in under 96 hours.

Diagnostic test: existing catalog still surfaces (proof: the +20s above), but new pieces don't get feed pickup. Conclusion: this is a velocity problem, not a quality problem.

The remediation, as planned:

Stop publishing for 48–72 hours. Mon and Tue (May 4–5) went dark on dev.to.
Resume with a single high-value sequel to one of the top performers, not another newsjack. (The Wednesday May 6 build-in-public Part 2.)
Re-evaluate feed pickup on the resumed piece before reintroducing daily volume.

What actually happened: the Wednesday resume piece (id 3619147, Part 2) and the architectural sibling piece (id 3619879) both hit 0 views at the 48-hour mark, just like the newsjacks before them. That is the May 7 verdict, and it is the May 8 verdict, and as of this morning it is the May 9 verdict. The throttle has not lifted on a five-day pause. The Thursday May 8 D-sequel I had drafted was therefore deferred to Monday May 12, after the planned Hacker News submission window — better to land a sequel into a fresh discovery surface than dump it onto a still-throttled feed.

If you publish for a living on dev.to and you are pushing more than five posts per week, watch your day-1 numbers across multiple posts. If three in a row hit a 0-view ceiling while older pieces continue to gain, you are throttled, not unlucky. And if your "resume" post is also throttled, the cooldown is longer than 48–72 hours — you may be looking at a full week or more, depending on the size of the burst that triggered it.

The newsjack archetype is hard-capped at 2/week going forward, regardless of how good the news is. Next newsjack window opens Monday May 11.

Off-dev.to: where the surprising data lives

The dev.to view chart is the headline, but the most informative single data points this week — and the three "first ever" milestones — were all elsewhere.

Quora. Monthly content views nearly doubled — 34 → 66 (+94%) in the first half of the week. The answer count climbed from 11 to 15 published answers by Friday morning, a +36% week-over-week increase. The 14th answer (a SimpliSafe-comparison piece) was algorithmically surfaced into a first-position SERP slot. The 15th (a dashcam GEO-targeted answer) was published this morning and is also pulling SERP rank. The first organic Quora follower captured this account has ever recorded landed early in the week. Quora is the closest thing to a working channel this account has, and it costs me ~10 minutes per answer.

Bluesky. Two milestones today, both first-evers: a third-party like landed earlier in the week from @zip358com, and the first ever follower landed this morning — Liv Well (@olivination.bsky.social, 2.1K followers, vegan/wellness audience). The follow came in via a #dogs hashtag overlap on a pet-monitoring post, and the follow-back established a mutual. One follower in 33 posts is a 3% follower-conversion-per-post on a cold-start graph — not zero, but not enough to call Bluesky a working channel. The conclusion I am drawing: Bluesky's cold-start tax is brutal, and audience overlap on hashtags can produce a follower out of a community you did not target. The next Bluesky experiment is intentional follower acquisition through neighbor topics (privacy, dogs, indie dev), not more posts into a 0-graph.

X / Twitter. ~59 tweets, 0 followers, but two structural wins this week: (1) the @superfunicular blue-check verification went live, which raises baseline reply-boost weight on the algorithm; (2) the first verified-account reply chain landed this morning, a back-and-forth with Mahere (@Mahere_Fluxera, founder of appxpose.app Privacy Scanner — a privacy-adjacent founder, the right kind of audience overlap). The reply chain extended past the first exchange, which is the actual signal — verified founders rarely engage on cold accounts unless the content is being read.

The single most useful artifact of last week was a reply on a 51,500-view tweet that was actively recommending a competitor (AlfredCamera). The reply named three concrete differentiators in 280 characters and linked the Play Store. I cannot prove it produced installs, but I would not trade it for the 58 standalone tweets that preceded it. The new operational rule: one reply per day on a saved search, logged with parent-tweet view count, capped to avoid rate limits.

LinkedIn. Profile is up. Nothing has shipped yet beyond the bio. Week 2 will change this — the first long-form post is queued (this article's contrarian "deep-dive is the worst archetype" angle, adapted).

Reddit. Account created, API access pending approval. Week 1 was blocked on this. r/AlfredCamera surfaced three active pain threads this week (hardware burnout, notification delay, doxx incident) that map cleanly to our differentiators. The moment API access lands, the queue is full.

What is queued for Week 2

The decisions made this week, all of them justified by the data above:

Hacker News Show HN submission of id 3589467 on Tuesday May 12 at ~08:00 PT. It is the highest per-piece efficiency archetype I have, the family that produced both reactions and the only bookmark, and the parent piece is now four weeks old — old enough to look real. Submission window is locked.
Comparison List re-promoted from HOLD to SCALE. Day-one views had us pointing at the exit; the 72-hour indexation pattern saved it. Week 2 carries an A piece on Mon May 12 (al

This week on @Digital_Nomad_Media — 2 new clips (2026-W19)

Super Funicular — Thu, 07 May 2026 03:31:41 +0000

Quick weekly digest from my YouTube channel — every clip below is fresh in the last 7 days.

Some roads lead to toads ✌️🤠

42s

Don't get behind the slow driver ✌️🤠

84s

I also built an app — DigiCam

Want the under-the-hood version? I wrote up the architecture behind a $0 security camera and a 2026 comparison of apps to stream YouTube Live from an Android phone — DigiCam's a useful starting point if you've ever wanted a phone-only studio.

Watch the full channel: @Digital_Nomad_Media

SuperFunicular #DigiCam #DigiNomad #YouTubeShorts #ContentCreator

The Architecture Behind a $0 Security Camera — How an Old Android Phone Replaces Ring Without the Cloud

Super Funicular — Wed, 06 May 2026 09:11:56 +0000

Why This Is a Companion Piece

A few days ago I wrote Turn Your Old Android Phone Into a Free Security Camera (No Subscription Required) — a step-by-step guide to repurposing a drawer phone as a continuous-recording security camera with no cloud, no account, and no monthly fees.

That post answered "how." This one answers "why it works at all."

If you're an Android developer, the question that should be bothering you is: if a drawer phone is hardware-equivalent or hardware-superior to a $300 security camera, why doesn't every Android phone already do this? The answer is software, and it's interesting.

The Three Things Stock Android Won't Do

Out of the box, an Android phone is unusable as a security camera for three specific reasons:

The camera surface is destroyed when the screen turns off. This is a battery decision, not a hardware limitation. The OS assumes that a user-facing app cannot be doing useful work when the display is off, so it tears down the Camera2 session.
There is no built-in remote viewer. A handheld phone has no UX surface for "let other devices on my network connect to me and watch what my camera sees."
OEM dozing kills long-running services. MIUI, OneUI, ColorOS, and friends each have their own aggressive battery-optimization layers on top of stock Android's Doze mode. A naïvely written background-camera app gets killed within an hour on most non-Pixel devices.

A real "old phone as security camera" app has to solve all three. Each one is a different sub-problem.

Problem 1: Surviving Screen-Off

The textbook solution is a foreground service holding a partial wakelock, plus a Camera2 capture session that's owned by the service rather than an Activity.

class CameraRecordingService : Service() {
    private val wakeLock by lazy {
        (getSystemService(POWER_SERVICE) as PowerManager)
            .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "BgCam::recording")
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        startForeground(NOTIF_ID, buildPersistentNotification())
        wakeLock.acquire(8 * 60 * 60 * 1000L /* 8h cap */)
        startCamera2Session()
        return START_STICKY
    }

    override fun onDestroy() {
        if (wakeLock.isHeld) wakeLock.release()
        super.onDestroy()
    }
}

Three details that took me weeks to get right:

The notification has to actually exist before startForeground is called. Android 12+ kills services that call startForeground from a non-foreground context unless the notification channel is already registered.
The wakelock has a max duration — acquire(timeout) with a finite timeout is safer than acquire() with no argument, because it bounds the worst case if your stop logic crashes.
START_STICKY matters. If the system kills your service for memory pressure, you want it restarted automatically. The Activity that started the service may be long gone.

Problem 2: The Local Web Server

The interesting design choice is that the camera should serve itself — directly, over the LAN, to any browser. No companion app on the viewing device. No cloud relay.

This is where Ktor on Android earns its keep:

embeddedServer(Netty, port = 8080) {
    install(CORS) { anyHost() }
    routing {
        get("/stream") {
            call.respondBytes(
                contentType = ContentType("multipart", "x-mixed-replace; boundary=frame"),
                bytes = mjpegFrameStream()
            )
        }
        get("/snapshot") {
            call.respondBytes(latestJpegFrame(), ContentType.Image.JPEG)
        }
        get("/") { call.respondHtml(controlPanelHtml()) }
    }
}.start(wait = false)

Three architectural payoffs from this pattern:

Zero install on the viewing device. Any browser on the same WiFi can hit http://192.168.1.x:8080/ and see the feed. Laptops, tablets, smart TVs with browsers, anything.
No relay infrastructure. Cloud-camera companies need datacenter scale to relay every customer's video stream. We don't need any of it because the bytes never leave the LAN.
No third-party data exposure. This is the privacy claim's actual technical foundation. There is no "we got breached" failure mode because there is no "we" — the server runs on your phone.

Things to know about putting Ktor on Android:

Use Netty, not the OkHttp engine. Netty is more battery-friendly for long-running idle servers.
Don't try to bind to port 80 — Android won't let unprivileged apps. Pick something high (8080, 8443).
For HTTPS on the LAN, generate a self-signed cert at first launch and accept the browser warning. There is no clean Let's Encrypt path for a host-on-LAN device with a private IP.

Problem 3: OEM Doze

This is the part nobody's article warns you about. You can do everything above correctly and still have your service murdered after 30 minutes on a Xiaomi Redmi. (For users facing this from the consumer side rather than the developer side, see Why Your "Old Phone Security Camera" Dies After 4 Hours.)

The mitigations, in order of how much they help:

Request REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. This handles stock Doze.
Detect the OEM and link the user directly into the manufacturer's whitelist screen. MIUI has a separate "Battery saver" whitelist. OneUI has "Sleeping apps." ColorOS has "Auto-launch." Each is a different intent target. Detecting Build.MANUFACTURER and routing the user there adds about 40 lines and saves about 80% of OEM-doze killings in my logs.
Heartbeat from the foreground service notification. A periodic notification update (once every 5 minutes) keeps the service "interesting" to certain OEM watchdogs.
Don't use WorkManager for the camera loop. WorkManager is fine for periodic tasks but it's the wrong tool for "stay running for 8 hours without interruption" — it batches work and is subject to all the same OEM-doze constraints you're trying to escape.

What the Architecture Costs

The only feature this architecture can't easily replicate from a Ring/Nest is push notifications when motion is detected and you're not on your home WiFi. Solving that requires either a relay (which destroys the privacy claim) or a self-hosted notification service (which is a non-trivial follow-on project).

For continuous monitoring on the LAN — driveway, baby crib, pet area, garage — the architecture is strictly superior to a cloud camera. (For a side-by-side of the consumer apps that implement variants of this architecture, see Best Free Security Camera Apps for Android in 2026.) Better hardware, no rent, no breach surface, no vendor lock-in.

What This Means for the Industry

Cloud-camera companies sell hardware at near-cost and earn on subscriptions. The drawer-phone architecture undercuts both legs of that business model — the hardware is free because you already own it, and the subscription is gone because the cloud isn't in the picture.

The reason this isn't more widespread isn't technical. The Android APIs to do all of this have been stable since Camera2 landed in Android 5.0 (2014). It's a marketing-distribution gap: Ring spends more on advertising in a quarter than the entire indie-Android-camera-app category will ever see in a decade.

If you're an Android developer reading this, the takeaway is: there's a category of "rent-extracting consumer hardware" — security cameras, baby monitors, pet cams, dashcams — where the underlying technical problem is solved and the business model is held in place by marketing budget. The wedge for indie apps is that you don't need to outspend Ring; you just need to be the answer that comes up when someone Googles "free alternative to Ring."

How We Apply All of This

Background Camera RemoteStream is the implementation of every architecture decision in this article. Free version covers screen-off recording and OEM-doze survival. Pro version adds the embedded Ktor web server for browser-based viewing.

If you're building something adjacent — a different sensor type on a phone, a different content-server pattern over LAN — I'd love to compare notes in the comments. Camera2 quirks specifically are an underdocumented area and every Android dev I talk to has at least one war story — I covered the development arc itself in How I Built a Production Android App in 75+ AI Sessions — Part 2.

Companion to: Turn Your Old Android Phone Into a Free Security Camera (No Subscription Required).

How I Built a Production Android App in 75+ AI Sessions — Part 2: What the First Month of Public Metrics Taught Me

Super Funicular — Wed, 06 May 2026 07:08:00 +0000

How I Built a Production Android App in 75+ AI Sessions — Part 2: What the First Month of Public Metrics Taught Me

A month ago I published a build-in-public post about shipping a production Android app using Claude Code as the primary developer. The app — Background Camera RemoteStream — was already on the Play Store open testing track at the time. Since then it has hit production, the YouTube Live API quota expansion has been approved, AdMob is live, and I have spent four weeks trying to do something even harder than building it: getting other humans to know it exists.

This is the unglamorous Part 2.

It is the post about the marketing month, not the building month. About what it actually feels like to publish 32 articles, 59 tweets, 33 Bluesky posts, and 13 Quora answers, and watch most of them land in the void. About the one reaction I got. About the article that did 40× the floor and the one archetype that quietly outperforms everything else 7×. About the feed-volume throttle that made me sit on this post for three days.

If you are an indie hacker, a solo founder, or a developer who finally shipped the thing and is now looking at a flat analytics chart wondering whether you broke marketing, this one is for you.

The headline numbers (real, not rounded up)

Here is the dashboard, as of May 5, 2026, for the @superfunicular footprint:

dev.to: 32 articles published, 175 cumulative views (+21 in the past 48 hours, all from the existing catalog — see Lesson 6), 1 reaction, 0 comments
Twitter / X: ~59 tweets, 0 followers (yes, still zero), blue check live as of two days ago, 1 reply on a 51,500-view tweet that was actively recommending a competitor
Bluesky: 33 posts, 0 followers, 4 cumulative likes, 0 reposts
Quora: 13 answers, 13 followers, 66 monthly content views (up from 34 the week before); first algorithmically-surfaced "Question for You" routed to the profile this week
LinkedIn: profile, but nothing has shipped yet beyond the bio
Reddit: account created, API access pending; posting blocked
Indie Hackers / Uneed.best / Pitch Wall / SideProjectors / Launching Next: product pages live or in queue; no measurable referral traffic yet

If your reaction to that list is "that is depressing," that is a healthy reaction. It is also wrong.

The sentence that took me a month to internalize is this: the headline numbers are noise; the distribution is the signal. Your one-month flat-line chart is hiding a Pareto, and the Pareto is your real product strategy.

Here is what I mean.

Lesson 1 — Pareto is the only metric that matters in month one

Of those 32 dev.to articles, 5 of them produced 100% of the views that broke the floor. The other 27 are within rounding distance of zero. The single best piece — a comparison list titled "Best Apps to Stream YouTube Live" (id 3592937) — is at 40 views. The top five, in order, are:

id 3592937 — "Best Apps to Stream YouTube Live" — 40 views (Comparison list)
id 3590206 — "Turn Your Old Android Phone Into a Free Security Camera" — 22 views (Use case)
id 3589467 — "How I Built a Production Android App in 75+ AI Sessions" (Part 1, this article's parent) — 20 views (Build-in-public)
id 3590177 — Build-in-Public sibling post — got the only reaction in the entire catalog
id 3598582 — "Best Free Nanny Cam Apps for Android" — gained +20 views in a single 24-hour window four days after publish (Comparison list)

Everything else is at single digits. Some of it is at zero.

The temptation in month one is to look at the average — 175 views ÷ 32 articles ≈ 5.5 views per piece — and conclude that you have a "low-engagement problem." You don't. You have a discovery problem. Five pieces work, and the rest are scaffolding. The right move is not to publish more scaffolding. The right move is to figure out why those five worked and write the sequels.

That is exactly what next week's content calendar does. The piece directly above the one you are reading is the sequel to id 3589467. Thursday's piece is the sequel to id 3590206. Saturday's piece is the doorbell-camera comparison sister to id 3592937.

Lesson 2 — Archetypes outperform topics

Inside that Pareto is a second pattern. I have been categorizing every article by "archetype" — Comparison List, Dramatic Story, Technical Deep-Dive, Use Case Showcase, Build-in-Public, Story Compilation, SEO Refresh. After 32 articles, the archetype averages tell a story the topic-by-topic view does not:

Archetype	Avg views/piece	Notes
Build-in-Public (E)	17.5	Highest per-piece efficiency; only archetype to land a reaction
Comparison List (A)	4.62	Slow start, 3× growth after 24-72h indexation
Use Case Showcase (D)	5.5	Steady performer; sequels compound
Technical Deep-Dive (C)	0.5	Worst performer despite the most effort per piece
Newsjacks (NJ)	0–2 (capped)	Three consecutive 0-view ceilings; see Lesson 6

This was the most expensive lesson of the month. I came in assuming Technical Deep-Dive would be the engine — developers love deep dives, dev.to is a developer site, Q.E.D. It is the worst-performing archetype I have. The Camera2 API explainers, the Ktor server walkthroughs, the foreground service architecture posts — they got read by approximately nobody. Build-in-public got read by 35× as many people on average.

What I think is happening: deep-dive content competes against an enormous backlog of evergreen tutorials. Build-in-public competes against almost nothing, because almost nobody is willing to publish their real numbers. Scarcity is a moat.

If you are about to write your first ten developer-blog posts about your indie product, the archetype mix matters more than the topics. Write the build-in-public first. Write the use-case piece second. Write the deep-dive last, and only when you have something genuinely surprising to say — not when you want to prove you are smart.

Lesson 3 — The averages lie until day three

The most operationally useful thing I learned in week one was almost a strategic mistake. After 24 hours, my comparison list (A) archetype was averaging 1.6 views per piece. I almost demoted the entire archetype out of the calendar. Then I waited three days.

Between publish-day and day-three of indexation, comparison-list pieces tripled their per-piece average — from 1.6 to 4.62. The piece I had nearly written off (id 3592937) climbed from 5 views on day one to 40 views by the end of week two.

The lesson: dev.to (and any SEO-driven channel) takes 48–72 hours to surface a piece. Your day-one analytics are not telling you whether the piece worked; they are telling you whether your followers showed up. Those are different questions, and the second one matters less than you think for a brand-new account with no followers.

Operationally, this means: wait three days before judging an archetype, and a week before judging a topic. The lag is real, and "it didn't pop on day one" is not the signal you think it is.

Lesson 4 — The first reaction is structurally meaningful

For the first three weeks, I had zero reactions across the entire dev.to catalog. Last week, the first reaction landed on a build-in-public post (id 3590177).

I do not believe this is a coincidence. The articles that produce reactions are not the ones with the most views — they are the ones that produce identification. Build-in-public posts say "I am like you and here is what is hard." A comparison list says "here are five products." Identification scales further than information, in social-proof economies.

If you are publishing into the void and have not produced a single reaction yet, write something that names a hard thing honestly. Then publish it. Then wait three days.

Lesson 5 — Your 0-follower X account can still produce one good placement

X is the channel where I have been most reluctantly impressed. The @superfunicular account has zero followers. It has produced one (1) genuinely useful artifact in a month: a single reply to a 51,500-view tweet from another account that was actively recommending a competing camera app. That tweet had 497 bookmarks at the time of the reply. My reply named three concrete differentiators (no account, no cloud, free) in 280 characters and linked the Play Store.

I cannot prove this reply produced any installs. The attribution is bad and X does not give me the impression count for a single reply on a 0-follower account. But I would not trade it for any of the 58 standalone tweets that preceded it.

The mechanism is straightforward: a high-view tweet in your category is a discovery surface. It is full of people who, by virtue of having read the parent tweet, are already qualified for your product. You do not need followers to reply. You need a saved search and discipline.

The discipline is to stay under one reply per day on the same query. (Mine is ("old phone" OR "spare phone") "security camera" on the Latest tab.) More than that and you will trip rate limits and look like spam.

Lesson 6 — There is a feed-volume throttle and you will hit it

Here is the operational footnote that almost broke this article — literally. The piece you are reading is being published on May 6, three days after the last article in the catalog and two days after the date stamped in its directory. The reason is that I tripped dev.to's feed-volume throttle.

What I observed: I published 30+ articles in under 96 hours. Three consecutive newsjack pieces (ClayRat trojan, NoVoice rootkit, Be Prime breach — ids 3599501, 3601479, 3603034) hit a 0–2 view ceiling that did not move. Meanwhile, articles I had published four to seven days earlier continued to accumulate views normally — id 3592937 added +20, id 3598582 added +20, id 3590206 added +22 in the same window.

The diagnosis: my existing catalog still indexes and surfaces through search and topic feeds. New posts were not getting picked up by the dev.to "feed" for a few days. The simplest explanation is a per-account volume throttle, not a per-article quality issue.

If you are a developer and your instinct is "they probably have a soft cap on publish frequency," that instinct is correct. The fix is not to fight it. The fix is to slow down and let the existing pieces breathe. I held publishing for three days and resumed with a single high-value sequel — the post you are reading. We will see whether that resets the surface.

The deeper lesson is that publishing volume is not the metric. Surface velocity is. If you double your output and feed pickup halves, you have made yourself busier and not better-distributed.

Lesson 7 — The Bluesky chart will demoralize you. Read it anyway.

After 33 Bluesky posts: 0 followers, 4 likes, 0 reposts. Compared to my dev.to numbers, this is the single most demoralizing line in the dashboard.

I am keeping it because Bluesky is the only place where I have a public, queryable, untrustworthy-vendor-free measurement of what "0 distribution" actually looks like. It is the control group. Every post is well-formed, includes a direct link, and is original prose. None of them have produced anything.

The conclusion I am drawing — tentatively — is that on a small platform with no follow graph, posting into the void produces zero compounding even when the content is fine. It is a graph problem, not a content problem. To make Bluesky work, the next experiment has to be follower acquisition (replies on developer accounts, follower-trains, mutual follows from indie-dev lists), not more posting. Posting more into 0-follower territory is not a strategy. It is a metric.

I will keep posting because it costs nothing and the day Bluesky's algorithm starts surfacing strangers, having a 60-post backlog is better than having a 6-post one. But I am not learning anything from the chart, and that is itself a lesson.

What is changing in month two

The operational changes for the next 30 days, all of them justified by the data above:

Build-in-public sequels. This post and three more like it before June. The reaction-rate is the highest in the catalog and the topic costs me nothing to write — it is just my real life.
Comparison-list scaling. I had nearly killed the archetype after day one. Now it is on weekend slots through May because the 72-hour indexation pattern is real and the SERP wins are slow but real.
Use-case sequels. id 3590206's "doorbell, pet cam, garage-watch" follow-up ships next Thursday.
Newsjacks paused. Hard cap at 2/week; window reopens May 11.
X reply discipline. One reply per day on the saved search, logged with timestamp and parent-tweet view count, so we can see whether the heygurisingh placement was a fluke or a repeatable pattern.
Reddit unblocked the moment API access lands. The r/AlfredCamera surface alone has surfaced three pain threads this week that map directly to differentiators.

Six months from now, if you are reading this and the chart has gone vertical, it will be because we did the unglamorous, non-cute, slow-compounding work above. If it hasn't, I will publish Part 3 and tell you what I got wrong.

Try the app, or don't

If you are looking for a privacy-first Android camera that does not phone home, that records with the screen off, and that streams to YouTube Live without an account-based middleman: Background Camera RemoteStream is on Google Play here, and the project lives at superfunicular.com.

If you are not — that is fine too. Subscribe, ignore, or come back in 30 days for Part 3. The only commitment I am making is that the numbers will be real.

DEV Community: Super Funicular

Texas Just Opened a Privacy Investigation Into Meta's AI Glasses — and It Raises a Question Every Camera App Has to Answer

Why this is a watershed and not a one-off

The architecture question every recording product now has to answer

What this looks like in a phone-based camera

What developers should take from this

YouTube Live Now Streams Horizontal + Vertical at the Same Time — How an Old Android Phone Becomes a 24/7 Dual-Format Camera

What actually changed

Why this matters for mobile streamers

The friction this removes

Where a phone-as-camera setup fits in

A practical setup (under five minutes)

The privacy footnote

Closing

The Cloud-Bill Theory of Free Camera Apps: Why Some Are Local-Only and Some Have to Sell Your Data

The cloud bill is real

The four ways to pay it

What changes if there's no cloud bill

How to tell which camp an app lives in, in two minutes

What I ship

A few other apps in the same architectural camp

The single sentence

This week on @Digital_Nomad_Media — 13 new clips (2026-W20)

I also built an app — DigiCam

Texas Says 'Netflix Watches You' — Why I Built My Camera App to Be Structurally Incapable of It

The architectural diagnosis hiding inside this lawsuit

Why I made the design call to keep everything local

What the Texas lawsuit makes easier to say

What I'd tell another indie builder

Related reading on this architecture

1.1 Million Baby Monitors Were Watchable by Anyone — Here's the Architectural Mistake Behind It

What actually broke

The thing the architecture is optimizing for

What "local-only" actually looks like

What this does not solve

The 378-brand problem

If you have a Meari-derived camera right now

Related reading on local-only camera architecture

Google Just Turned On Binary Transparency for Android — Why Privacy-First Indies Should Cheer

What Binary Transparency actually does

Why the timing matters

Why privacy-first indies especially benefit

What to watch next

The bigger picture

Related reading

Best Apps to Turn Your Old Phone Into a Doorbell Camera in 2026 (Free, Privacy-First, No Subscription)

What "doorbell" actually requires

#1 — Background Camera RemoteStream (Super Funicular LLC)

#2 — Alfred Camera

#3 — AtHome Camera

#4 — IP Webcam (Pavel Khlebovich)

#5 — WardenCam

Side-by-side comparison

Why the local-only architecture matters for a doorbell specifically

Practical doorbell setup — the part the comparison doesn't tell you

Verdict

Build-in-Public Week 1 — 35 Articles, 185 Views, First Bookmark, First Bluesky Follower, and the Pareto in a Flat Chart

Build-in-Public Week 1 — 35 Articles, 185 Views, First Bookmark, First Bluesky Follower, and the Pareto in a Flat Chart

The Friday-of-Friday scoreboard

The Week 1 ship log

The 24-hour doubling — and the flat 48 that followed

The archetype Pareto, after a full week

The newsjack throttle — and why it has not lifted

Off-dev.to: where the surprising data lives

What is queued for Week 2

This week on @Digital_Nomad_Media — 2 new clips (2026-W19)

I also built an app — DigiCam

SuperFunicular #DigiCam #DigiNomad #YouTubeShorts #ContentCreator

The Architecture Behind a $0 Security Camera — How an Old Android Phone Replaces Ring Without the Cloud

Why This Is a Companion Piece

The Three Things Stock Android Won't Do

Problem 1: Surviving Screen-Off

Problem 2: The Local Web Server

Problem 3: OEM Doze

What the Architecture Costs

What This Means for the Industry

How We Apply All of This

How I Built a Production Android App in 75+ AI Sessions — Part 2: What the First Month of Public Metrics Taught Me

How I Built a Production Android App in 75+ AI Sessions — Part 2: What the First Month of Public Metrics Taught Me

The headline numbers (real, not rounded up)