A one-person software studio operated entirely from a phone over Telegram. The Mac Mini, the bridge, the agents, and the tools that let real shipping work happen without a laptop session.
The most distinctive thing about Synodic Studio is not any particular app. It is that the studio runs without a desk. There is a Mac Mini in another room of the house. Everything else (builds, tests, deployments, code review, AI work, the writing of this very page) is driven from a phone over Telegram. The rule that everything has to be operable from a phone is not a limitation I am working around. It is the design constraint that shapes every tool in the stack.
This page is the architecture writeup. The product-level details for individual pieces are at /patchbay/, /synodic-kit/, /inline-relay/, /macro-kiwi/, and /fanta/. What follows is how those pieces compose into a working studio.
The constraint
I do not work from a laptop. The reasons are personal and not particularly interesting (mostly: I want to be away from a desk most of the day and I like working from anywhere with a charged phone). The interesting question is whether you can actually ship production work this way. The answer turns out to be yes, but it requires that every workflow, every tool, and every automation be designed around the constraint instead of around it.
The phone-first rule looks like this in practice:
- A new feature starts with a sentence in a Telegram thread.
- The Mac Mini reads that sentence, executes against it, runs tests, commits, and pushes.
- Outputs that need review (artifacts, screenshots, build links) come back as files or links in the thread.
- Anything I would normally do in a browser (App Store Connect, GitHub issues, calendar, email triage, knowledge search) is automated or fronted by an agent that runs on the Mac.
Operating this way breaks any tool that assumes a developer at a keyboard. Most of the engineering in the studio is the work of replacing those tools with phone-operable equivalents, and the result is a handful of open-source pieces that other people can run too.
The hardware
A single Apple Silicon Mac Mini, always on, accessible from anywhere over Tailscale. mosh handles long-lived shell sessions when I need raw access. The shared filesystem (notes, daily journals, agent state) is an Obsidian vault synced through a headless ob daemon under launchd, which replaced the GUI Obsidian app once I needed sync without a logged-in interactive session.
There is no other machine in the loop. No build farm, no CI, no remote runner. Builds run on the Mac Mini, tests run on the Mac Mini, signing and notarization run on the Mac Mini. The discipline of “one box, no escape hatches” forces every flake and every “well it works on my laptop” failure into the open.
The bridge
The piece that turns Telegram into a development surface is Patchbay Relay, an MIT-licensed Python service that maps Telegram threads to AI coding agents. Each thread is a project. The relay receives a message, picks the right working directory, spawns or resumes a session on the right harness (the Claude Agent SDK, the SDK with MOP filtering, or pi) pointed at that directory, and streams the agent’s responses back into the thread. Crash recovery, agent identity loading, and queue management are built in.
The clever part is not the bridge itself; bridges are not hard. The clever part is that Telegram threads are first-class project channels. The same thread holds the conversation, the bot’s responses, the build artifacts, the screenshots, and the audit trail of every change. There is no second app to consult.
The agents
On top of the bridge sits Fanta, a personal multi-agent system written for Claude Code. Each agent is a directory with five markdown files (soul, identity, operating manual, memory, heartbeat) plus a heartbeat.py script that the unified scheduler runs every fifteen minutes via launchd. Agents include an email triage bot, a strength-training coach, an ornithology assistant that listens for rare-bird alerts, an attention manager that routes outbound communications, an infrastructure monitor that watches the Mac Mini’s services, a podcast archivist that ingests YouTube transcripts and runs RAG queries, and a job-search coordinator. The agents talk to each other through inboxes and a small Agent Mail server, not through me.
The point of the agent system is not the cleverness of any individual agent. It is that boring background work (triaging email, monitoring services, prepping daily briefings) happens autonomously while I am away from the phone. When I open Telegram, the work has already been done and the only message waiting for me is the one that needs a decision.
The toolchain
A handful of supporting pieces make the rest of the system possible:
- synodic-kit is the Claude Code plugin that hosts the skills, hooks, and the safety layer. It is the substrate under every agent and every coding session. Everything else here loads through it.
- inline-relay is a code-review surface where review threads live inside source files as comment blocks instead of in a web UI. Reviews happen in the same Claude Code session that wrote the code, with no browser context switch.
- macro-kiwi is a multi-provider gen-AI skill (a self-contained CLI) for image generation, editing, and vision. It is what lets an agent ask “what does this screenshot show” or “generate marketing artwork” without me opening a separate tool.
All of these are MIT-licensed. Several started as private utilities and were extracted out once they were stable enough to live on their own.
What it ships
The proof that this works is the output. Gravity Well is a realtime Metal image-processing exhibit running unattended in five science museum installations. DeskDays is a privacy-first iOS and watchOS app, built and shipped to the App Store through this pipeline. Podcast Pusher is a live web product. The studio website you are reading right now is built and deployed by an agent.
For deeper engineering writeups, see the Gravity Well case study and the DeskDays case study.
Why this is interesting
Most demonstrations of AI agents are demonstrations. They run for a session, they look impressive, and then nobody uses them again. The interesting question is whether you can compose agents into a working system that ships actual products under actual constraints, with actual users.
The headless-studio model is one answer. The constraints are not optional, the tools are open source, and the products are real. The studio runs from a phone because it has to, and the engineering rigor that “has to” forces is the reason any of it works.