Super Funicular

Posted on Apr 30 • Edited on Jun 14

How I Built a Production Android App in 75+ AI Sessions (Updated June 2026)

#android #ai #buildinpublic #indiehacker

Updated June 2026. This post is the origin entry in an ongoing build-in-public series. One month after going public I added a fresh "Where things stand" section below, refreshed the competitive landscape (an open-source rival has since shipped), and linked the month-one recap. The original write-up is unchanged underneath.

The Experiment

What happens when a solo developer tries to build a production Android app using AI as the primary coder?

I've been building Background Camera RemoteStream — an Android app that records video in the background with the screen off and streams to YouTube Live — using Claude Code (Anthropic's AI coding tool) across 75+ Claude Code sessions spanning 6+ months.

The app is now live on Google Play. Here's what that journey looked like.

What the App Does

Background Camera RemoteStream solves a simple problem: recording video without destroying your battery.

Screen-off recording: The screen turns completely off while recording, giving you roughly 10x battery life compared to traditional camera apps that keep the display on.

Remote control: Control your phone's camera from any browser on the same WiFi network. No app needed on the viewing device — just open the IP address shown in the app.

YouTube streaming: Stream live to YouTube — even with the screen off. This is, as far as I can tell, the first app to offer screen-off YouTube streaming.

The AI Development Journey

Every line of code was written through conversation with Claude Code. The numbers:

75+ development sessions over 6 months
204 builds from first prototype to production release
Camera2 API: Low-level Android camera control (one of Android's most complex APIs)
Embedded Ktor web server: A full HTTP/WebSocket server running inside an Android app
YouTube Live integration: RTMP streaming, OAuth, live chat — all built through AI pair programming

Key Technical Challenges

1. Background recording without a visible preview

Android's Camera2 API normally requires a preview surface. We use a hidden SurfaceView technique to work around this, allowing the camera to record without anything visible on screen.

2. Screen-off operation

Foreground services with wake locks keep the camera and embedded web server running when the screen is off. Getting this reliable across different Android versions and manufacturers was one of the longest debugging efforts.

3. Portrait video streaming

YouTube's RTMP endpoint doesn't auto-rotate, so portrait video requires precise FFmpeg flag configuration to avoid sideways streams.

4. Embedded web server

A full Ktor CIO server running on port 8080 inside an Android app, with WebSocket real-time updates for camera status, recording state, and stream health.

What I Learned About AI-Assisted Development

The experience was genuinely different from traditional development. Some observations:

AI excels at boilerplate and API integration. Setting up Camera2, configuring Ktor routes, wiring up YouTube OAuth — these are well-documented patterns that AI handles efficiently.

AI struggles with cross-cutting concerns. When a change in the streaming module affected the recording module, which affected the UI state, AI needed very explicit guidance about the ripple effects.

The conversation history is your architecture document. 75 sessions of back-and-forth with Claude Code created an implicit design document. If I ever need to onboard someone, those transcripts contain every decision and its rationale.

You still need to understand the domain. AI wrote the code, but I needed to understand enough about Camera2, RTMP, and Android services to evaluate whether the code was correct. Pure delegation doesn't work.

Results

The app is live on Google Play with zero crashes and zero ANRs. Built by someone who isn't a professional Android developer, using AI as the coding engine.

Try it: Background Camera RemoteStream on Google Play

Website: superfunicular.com/backgroundcameraremotestream

Update — June 2026: Where Things Stand a Month Later

I started writing this in public, and I've kept at it. A few honest updates one month into the open build:

The documentation snowballed. What began as a single dev.to post has turned into an ongoing build-in-public log. I just published the month-one recap — the full numbers, what the channel-pivot experiment taught me, and the day a competitor shipped part of my moat: Build-in-Public Week 5 — Month 1 in Review. If you only read one follow-up, read that one.

A competitor validated the niche. When I wrote this post, screen-off / background recording with no account and no cloud felt like an unusual position to hold. Since then FadCam — an open-source, ad-free camera app — has shipped on Google Play with background recording, local-network streaming, and no data collection. That's good news and a reality check at the same time: "privacy-first" is becoming table stakes rather than a moat. My honest reframe is that the durable edge isn't just privacy — it's being the easiest path to a live, YouTube-streamable, browser-viewable Android camera with no account, no cloud, and a five-minute setup. Camera2 + an embedded Ktor server + RTMP is a meaningfully harder thing to assemble than local recording alone, and that's where I'm leaning in.

The "why local-only matters" thread kept getting more concrete. Over the month I dug into the economics and the failure modes of the subscription camera ecosystem, and several of those pieces have become the most-read in the catalog:

On the AI-development claim itself: a month of public scrutiny hasn't changed my core takeaway. AI was the coding engine, but the judgment about Camera2 lifecycle bugs, RTMP rotation, and foreground-service reliability across OEMs still had to come from me. If anything, the build-in-public process made that division of labor clearer: the model writes fast, but the domain understanding is what keeps it from writing fast in the wrong direction.