Loading page…
A runner-focused app that lets family track a run and sends voice encouragement into the runner’s headphones while they move.
$33 proceeds in the last 24 hours · 0 conversions on the reported day because of an onboarding/authentication bug
The best feature came from a real annoyance: a runner cannot safely stop to read a text, but can hear a voice message while moving.
Fewer bars = easier, cheaper, or faster for an AI-assisted solo builder. Editorial judgments based on the case details.
CheerMyRun began with Iñigo Vazquez Ibarreche’s own endurance problem. He ran 12 marathons in 12 consecutive days dressed as Santa Claus. Friends and family sent messages while he ran, but reading them meant unlocking his phone and looking away from the route. Voice notes were better: he could press play and hear encouragement without stopping. He built CheerMyRun around that insight. A runner shares a link, friends and family track the run live, and they can send voice cheers that play automatically in the runner’s headphones. The first MVP launched at the end of September and was, by the founder’s own description, rough: poor UI, features that barely worked, and paid developers carrying the build because he does not code. The reported starting point was $16 MRR, with a target of $100K MRR in 60 days. A later snapshot showed $33 in proceeds over 24 hours and zero conversions that day because an OTP and onboarding failure made new usernames appear to be taken. The founder was testing influencers and a TikTok format while fixing reliability.
CheerMyRun has a natural first audience: runners who already share race goals with friends, family, and training groups. The founder’s story of 12 consecutive Santa marathons supplies a credible demonstration because the problem happened to him while running.
The quick-reference card — acquisition channels, replication playbook, risks & traps, and our verdict — is members-only.
Join the Unicorn Club — $5/moCancel anytime, in one clickPaste into Claude Code / Codex and get a working version of this product end-to-end.
Two production-grade prompts per idea — a full build spec and an SEO growth plan — plus 10 tailored build specs a week. Members only.
Join the Unicorn Club — $5/moCancel anytime, in one clickEvery claim traces back to a listed source — open any of them and check the number yourself. The exact words are quoted below, with a timestamp that jumps to the second each figure is said.
“This is the first video of the series of taking my app from $16 to 100k MRR.”
0:02 · hear it in the videoData credibility: Founder-reported build-in-public episode by Iñigo Vazquez Ibarreche. The app name, $16 MRR starting point, $33 proceeds in the last 24 hours, zero conversions on the reported day, 12-marathon origin story, developer arrangement, and onboarding bug all come from the founder’s narration. No payment dashboard, retention chart, pricing page, user count, or third-party analytics are shown in the transcript. The $100K MRR figure is a stated 60-day goal, not achieved revenue. The technical stack and margins are not disclosed.
CheerMyRun’s first observed money came from existing downloads rather than new conversions. The founder reported $33 in proceeds over the previous 24 hours while the conversion count was zero, because people who had already downloaded the app were still generating proceeds.
The product has a built-in social loop: one runner shares a link, several supporters open it, one of those supporters sends a voice cheer, and the runner has a reason to share the experience after the race.
The founder’s hardest stretch was not abstract silence; it was a rough MVP and a broken onboarding path. The first release had poor UI and features that barely worked.
CheerMyRun is a social running utility built around two roles. The runner broadcasts a live activity through a shared link. Supporters follow the route and send voice messages. Those messages are designed to play in the runner’s headphones automatically, removing the need to unlock a phone while running. The product is not just live tracking. Existing running apps already record distance, pace, and location. CheerMyRun adds a participation layer for people who cannot be physically present. The founder’s Santa-marathon story gives the feature a clear origin and demonstrates why text messages are inconvenient during a run. The early product was built with paid developers, and the founder says he does not code. He later tried an AI coding tool to investigate an authentication problem, but he did not understand the backend well enough to take ownership immediately. Our read: the wedge is emotional and situational. It will win only if audio starts reliably, location sharing feels safe, and supporters have a reason to return after one race. The MVP should therefore prioritize event reliability over a broad training dashboard.
The app already produces proceeds and tracks conversions, but the interview does not specify the exact price, billing cadence, or paid feature boundary. The commercial starting point is described as $16 MRR, with $33 in proceeds during one 24-hour snapshot despite zero new conversions that day. That suggests existing users can generate money after download, but it is not enough information to infer a stable subscription model. A sensible model for this product would charge for a race-support package or a recurring runner plan, with limits around active events, voice messages, replay history, or supporter seats. The first paid offer should preserve the emotional moment instead of charging for basic safety-critical tracking. A free event can prove the loop; a paid event can unlock more supporters, custom messages, or a saved race story. Our read: revenue quality will depend on repeat use. A one-time race purchase can work if acquisition is tied to event calendars, while a subscription needs training and multiple runs per month. Measure proceeds per activated runner, supporter-to-runner conversion, repeat event rate, and refunds before scaling the $100K MRR ambition.
The founder was testing influencers and a TikTok format after the app’s best month. That is a good fit because the product’s value is visual and audible: a creator can share a run, show supporters following the route, and capture the moment a voice cheer arrives. The 12-marathon Santa story gives the founder an unusual origin hook and makes the problem easy to remember. The next channels should stay close to running behavior. Partner with marathon and half-marathon creators, race organizers, training plans, running clubs, charity challenges, and family-oriented race content. Give each partner a tracked event page instead of a generic app-store link. A supporter who opens a link is a different stage from a runner who activates location and a buyer who pays, so report those stages separately. Personal content can compound if every daily update includes one test, one failure, and one user story. The founder’s planned 60-day series creates accountability and distribution, but it should point to a working onboarding flow before pushing more traffic.
The transcript confirms a mobile app, paid developers, an OTP and authentication flow, a backend that can time out during onboarding, live location, audio playback, and an AI coding tool the founder began testing while developers were unavailable. It does not provide the app framework, cloud provider, per-user infrastructure cost, or margin. Those unknowns matter because live location and audio can create variable costs and support obligations. The first cost decision is whether the founder can diagnose production issues without waiting for a developer. Add error tracking, structured logs, a replayable onboarding test, feature flags, and a clear incident channel before buying more acquisition. Keep location collection limited to an active run, encrypt supporter data, and make sharing revocable. Our read: the likely margin can be attractive if paid plans are priced above storage, notifications, maps, audio processing, and support, but consumer subscriptions are unforgiving. Use event-level cost reporting. If one race creates many viewers and voice clips, the team should know that cost before offering an unlimited free tier.
Copy the founder-led origin story and the narrow job-to-be-done. The app is easier to understand because it begins with a real running constraint: a person cannot safely read messages during a marathon. Copy the decision to work with influencers and publish the building process, but give each test an activation metric rather than judging it by views. Copy the discipline of describing a bad day honestly; the onboarding bug is more useful than a polished growth claim. Change the launch sequence by making reliability the marketing asset. Before expanding features, prove that a new runner can sign up, share a link, receive a supporter, hear a voice cheer, and finish a run without support intervention. Add privacy controls and race-day fallback instructions early. Our read: CheerMyRun is a promising consumer wedge, not yet a proven $100K MRR business. It suits a founder who can build community and manage mobile reliability. The durable advantage would be a dense network of race-specific supporters and emotional memories, not live maps alone.
The four founder playbooks — first customers, first dollar, the flywheel, the silent stretch — are in the Unicorn Club, on this idea and on all 1,435 others. The story, the numbers, the sources and every later section stay open to everyone.
Join the Unicorn Club — $5/moCancel anytime, in one click