Build in Public: How My Beta Tester's Texts Become App Updates

I'm building Archive, a salon inventory app, with a real beta tester: Van, a salon owner. She's not a developer. She doesn't file GitHub issues. She texts a Telegram bot in her own words — sometimes with screenshots — and her app updates itself. Everything in between is an AI agent pipeline I run in production, and this post is exactly how it works, including the part where it broke.

Van texts something like "not only is there 10–40vol theres 5, 7, 13" — that's salon-speak for developer volumes missing from a picker. The bot replies "Got it — on it." From there, her message flows through three possible lanes:

The three lanes are a safety design, not a limitation. Code-only fixes ship themselves because a failing-test-first workflow plus green CI is a real gate. Anything that changes the product's shape or its foundations waits for a human.

What Van sees: she texts about the missing volumes. The bot says "Got it." Later: "The missing volumes are in — close and reopen the app and they'll appear."

What actually happened: her message was triaged into a labeled, deduplicated GitHub issue. The agent wrote a failing test, then the fix. 127 tests green, CI green. The OTA update published to the production channel, and I got a rollback command in case anything looked wrong on her device.

That gap — between what she experiences and what the machinery does — is the entire product. She gets a developer on call 24/7. I get a paper trail with a test suite.

Build in public means the failure ships too, so here it is. In early August the whole loop went dark for four days — and nobody noticed, which is the worst kind of outage.

The agent session lived in a terminal window on my machine. A Linux restart killed it silently. And here's the brutal detail: Telegram discards undelivered bot messages after about 24 hours, so everything Van texted during those days is simply gone. No error, no queue, no replay.

The fix was to stop treating the agent like a process I start and start treating it like a service the machine owns:

• On boot, a watchdog timer starts the agent automatically — and health-checks it every 5 minutes, replacing it if it's half-dead.
• The agent re-arms its own daily sweep (TestFlight feedback + crash reports flow into the same triage lane), because scheduled jobs die with the session and reboots were silently eating them.
• It refuses to run in the mode that once leaked permission prompts into Van's chat — she saw approval buttons meant for me. Fixed at the source.

The lesson generalizes: an autonomous agent is only as reliable as its supervisor. The interesting engineering isn't the AI writing the fix — it's the boring systemd timer making sure the AI is still listening.

Ships without asking: code-only bug fixes (test-first, CI green, rollback sent to me), replies to Van, and GitHub issues generated from her feedback.

Always stops at me: feature merges, database schema, auth, native modules, App Store builds — and anything Van's messages instruct. That last one matters more than it looks: her texts are treated as feedback data, never as commands. An agent that obeys instructions found inside user input is an agent waiting to be hijacked. Mine reads "delete all my competitors' reviews" as a bug report about something weird in her inbox, not a task.

And every OTA update has a one-line rollback: republish the previous known-good update group to the production channel. Autonomy without rollback isn't autonomy — it's gambling.

This is the same architecture I deploy for clients as the Agent System — an orchestrator agent, specialized sub-agents, cron automation, and human gates exactly where the blast radius demands them. Archive is me running it on my own product first, with a real user, in public. If it doesn't survive Van's salon, it doesn't ship to you.