Beto: My first iOS app with ~40 daily active users
I turned one narrow frustration into a focused iPhone and Apple Watch product, then used real behaviour and user feedback to make the second release more precise, more reliable and multilingual.
- Users · TelemetryDeck
- 257
- Sessions · TelemetryDeck
- 1,163
- Runs started · TelemetryDeck
- 709
- Runs completed · TelemetryDeck
- 139
- Lifetime downloads · App Store Connect
- 470
- Countries represented · TelemetryDeck
- 12
Users · TelemetryDeck
Sessions · TelemetryDeck
Runs started · TelemetryDeck
Runs completed · TelemetryDeck
Lifetime downloads · App Store Connect
Countries represented · TelemetryDeck
The brief
I run without music. I wanted to hear my breath and footsteps, but I kept drifting from a target cadence five minutes in. The obvious fix was a metronome I could set to 170 SPM and forget.
Most alternatives I found were musician-first, crowded with controls or gated behind subscriptions. Running is the wrong moment to manage software. I needed one number, one action and a beat I could still trust after the phone went back into my pocket.
How might I help a runner hold cadence without asking them to keep looking at a screen?
- Role
- Product design and implementation
- Team
- Solo
- Platforms
- iPhone and Apple Watch
- Timeline
- Two weekends to v1; follow-up release after two months
- Responsibilities
- Problem framing, interaction and visual design, specification, implementation, QA, App Store launch, analytics and iteration
Four constraints kept it focused
01
Start in seconds
The frequent path never becomes a setup flow.
02
Work eyes-free
Audio and haptics carry the experience after setup.
03
One product, two devices
Share durable state; respect each device's job.
04
Native before novel
Customise only where it improves the runner's task.
The most important design-system decision was not making one. I used Apple’s native components, semantic colours, materials and familiar control patterns, then spent custom design effort only on the beat, cadence and cross-device experience.
That was a speed decision and a product decision. Familiarity reduces attention cost, which matters more when someone is moving than when they are sitting at a desk.
The product is small; the state space is not
Onboarding asks one useful question—how do you run?—and turns the answer into a sensible starting cadence. It avoids a tutorial while still preventing a blank, generic first run.
Free Run owns the common path. Presets handle warm-up, tempo and cooldown segments without turning the default experience into a workout builder. Empty, signed-out and configured states were designed as first-class parts of the product rather than cleanup.
The Watch is not a miniaturised phone. It prioritises glanceable cadence, elapsed time, large transport controls and precise wrist adjustments. Playback is independent, so either device can own a run; durable settings, presets, language and idle cadence stay in sync.
From intent to implementation
Cursor accelerated implementation; it did not decide the product. I worked in the same loop I use with engineering teams, only the handoff happened inside the same person.
- 1
Specify behaviour, not a feature name
I described snap rules, countdown states, interruptions, accent patterns and what a second tap should do.
- 2
Build the smallest complete path
Cursor drafted the implementation while native platform components carried the baseline interaction quality.
- 3
Test on the actual devices
Simulator audio and haptics are not physical feedback. Runs on phone and Watch exposed problems static review did not.
- 4
Diagnose precisely and iterate
“It feels off” became “the haptic and the countdown number are not firing on the same beat.”
AI made the code cheaper. Product judgment—what to ask for, what felt wrong and what not to build—remained the scarce part.
Intent
Cadence · accent · session
Shared clock
Sample-addressed beat onsets
Outputs
Audio frames · Watch haptic cursor
The reliability work became more important than another screen. A shared, sample-addressed audio clock derives each beat from the audio engine frame counter instead of a wall-clock timer. The test suite covers 30-minute runs across 101 tempos, three sounds and seven accent modes: 2,121 combinations checking every onset and cumulative phase drift.
Sync gets the same treatment. Phone and Watch exchange versioned snapshots, acknowledge commands, retry when delivery fails and reject stale state. That is invisible in a screenshot, but it is the difference between a companion experience and two screens that merely look related.
The release users shaped
Beto sat untouched for two months while work got busy. Then a user emailed about a real Watch bug, complimented the design and offered to help translate the app to Chinese. Around the same time, an App Store review asked for exact tempo instead of jumps of five.
That changed the framing. These were not hypothetical users; real people were depending on the tool. I carved out a Sunday and worked through the evidence.
A review asked for exact tempo
Precision mattered, but a 101-step drag would be cumbersome.
Shipped: Coarse slider movement with ±1 precision controls.
A user offered Chinese translation
Demand was already crossing the launch language.
Shipped: System, English and Simplified Chinese across phone and Watch.
Watch audio failed in the background
The core promise broke exactly when the screen went away.
Shipped: Background playback and recovery hardened on Watch.
Longer runs exposed beat drift
Timing reliability mattered more than another visible feature.
Shipped: A sample-addressed audio clock plus exhaustive long-run tests.
Early traction, not vanity scale
App Store Connect reports 78% Day 1 retention and 33% Day 7 retention, both above its 75th-percentile benchmark. The cohort is still small, so I read these as encouraging signals rather than a conclusion.
The stronger outcome is behavioural: people cared enough to report a broken core promise, request finer control and offer a translation. That moved the roadmap from ideas I could imagine to problems the product had earned.
What changed in my practice
The strongest design decision was not the coral visual language. It was keeping the product small enough that its main task stayed obvious while the system expanded across devices, languages and more reliable audio behaviour.
I now model cross-device state earlier, test physical behaviours on real hardware sooner, instrument products from launch and treat shipping as the beginning of research rather than the end.
Building Beto also narrowed the gap between the product I can articulate and the product I can make real. That does not replace engineering partnership. It makes my specifications, trade-offs and conversations with engineers better grounded.