MyBlueBerry
The tracker app we used after our baby arrived needed seven taps and a network round trip to log one feeding. Offline it didn't work at all. And every entry about my kid was stored on someone else's server.
I'm a backend engineer. I've built distributed systems in big tech my whole career — and never shipped a single product of my own. No app with my name on it, no public writing. So I set two goals for my paternity leave, both firsts:
- Ship a product to real users.
- Write about it in public.
You're reading goal #2. Goal #1 is MyBlueBerry, live on the App Store. Making money was explicitly not a goal.
Why now
Three things lined up:
- The need. Too many taps per entry, no offline mode, no privacy story. I knew exactly what I wanted instead, because I was the user, at 3am, one-handed.
- The window. Ten weeks of paternity leave — the longest block of self-directed time I've had since college.
- The tooling. AI coding agents crossed a threshold. The question I wanted to answer was no longer "can it autocomplete a function" but "can one person plus an agent run an entire product team."
Why native iOS, and why Swift
The requirements were fixed before any technology discussion:
- Offline-first. Logging must work with zero connectivity and sync later.
- Private by default. Data stays on-device and syncs through the family's own iCloud (CloudKit). No sign-up beyond Sign in with Apple, no third-party analytics.
- One or two taps per entry, operable one-handed.
A web app fails the first requirement. React Native could get close, but the things I wanted — CloudKit sync, a Live Activity on the lock screen — are native APIs anyway. Native Swift was the straightforward answer.
I had never written a line of Swift or SwiftUI, and I'd never built a UX-heavy app of any kind — my career is backend. I kept Swift because I didn't know it. If the experiment was going to mean anything, it had to run where I couldn't fall back on experience. What I actually brought to the project: I'm the target user's parent, and I know how software gets built.
The experiment: every hat
The real question wasn't whether Claude can write Swift. It was whether one person and an agent can cover every role a product team has:
Research on what parents complain about in existing trackers; UX specs with tap budgets; product decisions about what ships and what waits; the architecture calls; all of the Swift; automated test suites plus manual testing; App Store screenshots and copy; and a pricing model I built mostly to learn how App Store monetization works.
The architect hat deserves a word, because it's the one that transferred straight from my day job. I couldn't write the Swift, but a career of backend systems meant I could reason about sync topologies, data ownership, and migration safety — and the project needed that repeatedly. I had Claude consolidate two persistence engines into one when co-parent sharing demanded CloudKit's native share machinery; tear out a QR-code invite system and rebuild invites around owner-held state; and re-root the whole family data model after device testing disproved the first sharing design. In the charts below that work files under Developer — architecture rides the same branches as the code that implements it — but the decisions weren't Swift knowledge. They were systems judgment.
I wanted to measure this, not just claim it. Every Claude Code transcript records which git branch the work happened on, and my branch names encode the role — feat/, fix/ and refactor/ are development, docs/ branches hold specs and validation plans, design/ is UX and research, site/ and the marketing branches are marketing, and so on. Classifying every transcript record by its branch gives a per-session picture of where the time went. It's in the charts below.
The numbers
I kept everything: the Claude transcripts, the git history, the CI logs. Every figure below comes from the JSON data block embedded in this page's source, which was in turn computed from those artifacts. One caveat up front: the first commit is May 8, but the preserved transcripts start June 11 — the first month of sessions wasn't kept, so every conversation stat undercounts the project.†
Commits per day
477 commits, May 8 – Jul 13. Empty slots are days with no commits.
What Claude actually did all day
4,404 tool calls across all sessions†
Which hat each session wore
Share of each session's transcript records, by branch role§
For every line of app code, a line of tests
Lines of Swift in the repo at launch
Who did the talking
12,077 model responses across all sessions†
CI told the truth the whole time
GitHub Actions runs, May 8 – Jul 13
| Workflow | Runs | Passed | Failed | Cancelled | Pass rate |
|---|---|---|---|---|---|
| iOS Test (unit + integration) | 525 | 373 | 118 | 34 | 71% |
| Nightly UI Tests | 34 | 2 | 32 | 0 | 6% |
| TestFlight deploy | 18 | 3 | 15 | 0 | 17% |
| Deploy site | 3 | 2 | 1 | 0 | 67% |
† Transcript-derived stats (sessions, records, model responses, tool calls, hats) cover Jun 11 – Jul 13. Git and CI stats cover the full project, May 8 – Jul 13.
‡ App-code lines = total Swift lines minus test lines.
§ Hat classification: each transcript record is attributed by the git branch it was recorded on; branch prefixes map to roles. Records on main (~29,000, mostly planning conversation and merges) can't be attributed and are excluded. "Other" = research, testing, release, and UX-design branches. Architecture work rides the same feat/ and refactor/ branches as implementation, so it files under Developer.
It shipped
MyBlueBerry is on the App Store: a one-handed baby tracker. Most entries are one or two taps. It works with no signal and syncs through your family's own iCloud. No account beyond your Apple ID, no analytics, no spinner between you and "the baby ate."
It's a small app, and that's deliberate — it does the specific thing I needed, the way I needed it. But a stranger can download it today, which is not something I could say about anything I built in my career before this.
Next in this series
- The bill. Exact token counts across the 1 GB of transcripts, cache behavior, and what this would have cost at API prices.
- The hats, one by one. What AI-assisted research, UX, development, and testing each looked like in practice — including where the agent failed and I had to take over.
- Can AI run the store? The post-launch experiment: wiring an agent to watch operations, reviews, and marketing.