Work App development
I work on two apps, built in two different ways.
BirdSpot is published and was built hands-on: I wrote the code with the app running live on an Android phone and an iPhone, so I saw every change as I made it. Hov! is built hands-off: agents work on their own on a Mac, and a request I say out loud can become a tested pull request without me opening an editor.
An observation and alerting app for ornithologists, with a backend, an admin site and a website. I developed and published it.
An iOS and Android app for creating events that businesses can apply to or book a spot at.
I can start work from the voice assistant. From there, nothing needs me until the pull request is ready for review.
"Start work on…" to the voice assistant, from any device
The assistant writes a GitHub issue and labels it for Claude, Codex or the local model
A dispatcher on the Mac Studio starts an agent in its own worktree, within set hours and a daily budget
The agent follows the repo's rules, runs the quality gate and drives the app on a simulator and an emulator
With the checks that ran, screenshots next to the design, and open questions
Agents never merge or push to main. I review in GitHub and merge
The agents are only as good as the repository they land in. Much of the work on Hov! has gone into making that repository explicit.
An agent guide lists the rules that always apply, and skills cover issue work, design work and device testing. A decision log says what may be built; if a capability isn't decided yet, the agent stops.
Issues point at Figma frames. Agents read them, build from design tokens, and put their screenshots next to the frames in the pull request. Without the design, they don't guess a layout.
The pull request template asks only for checks that actually ran. Scripted device flows run on the iOS simulator and Android emulator, and locks keep parallel agents from sharing the database or a device.
Every pull request ends with what slowed the agent down. Every few days, a separate run reads those notes and fixes what keeps coming back, in the setup itself.
Snippets from one of Hov!'s pull requests, written by the agent that did the work. For each screen it shows the target, the Figma frame it built from, and what it actually built, captured on the iOS simulator and the Android emulator.
Target vs implementation
Target
Implementation
The design's date sheet was unfinished, with no calendar drawn. The agent used each platform's own picker instead: a calendar inside the app's sheet on iOS, and the system dialog on Android, coloured with the brand's plum read from the design tokens. It flagged the choice for review.
Target
396:33125Implementation
"They book a spot" opens a link and a booking deadline. Each way of joining keeps its own answers, so switching back and forth loses nothing.
Target
396:31949Implementation
Pressing Next without a choice shows the frame's error state: red radios and "Choose how businesses join."
Target
254:18210Implementation
The frame points to a Drafts list that doesn't exist yet, so the agent rewrote the sheet's text to say where the draft really is, and flagged it.
Checks run
npm run quality:app: passes. Format, design tokens, translations, lint, types, and 61 Jest tests, with new ones for step 6, the leave sheet and translucent tokens.Choices to review
Friction
Hov! isn't released yet. Next are preview builds through TestFlight and Google Play's internal testing, with over-the-air updates, so a merged change reaches testers' phones without me building it.
BirdSpot now gets agent work too, including its release checklist and update scripts. Publishing to production still needs a token only I can unlock.