Earlier this year I spent a week exploring what was possible with Claude Code as my “engineering partner”. As someone with a design and product background I wanted to see how possible it would be for me to work with Claude to build a fully functional iOS app.
As a keen amateur cyclist, I have lots of data across Strava, Garmin and Zwift. Over the last few years I’ve tried various training platforms like TrainingPeaks, WKO5, Intervials.icu and Xert – but I found that none of them really gave me what I was looking for. I was looking for an experience closer to that of having a personal coach – someone who would help explain all the data to me – but without the commitment and cost – because, as I said at the start, I was a keen amateur cyclist!
So I set out with the goal of building an AI-based training coach. I called it Swanny – a “swanny” in cycling is the colloquial nickname for a soigneur. They are a non-riding support staff member who takes care of bicycle racers.

The app pulled in your rides from Strava and Zwift, figured out what’s actually holding your fitness back, and gave you a training plan and a weekly review in plain English instead of a wall of charts. The bet I was actually testing, on myself, was: could an LLM do enough of what a $100-300/month human coach does that it’s worth it for the huge pile of amateur riders who’ll never hire one?
I’ve ended up shelving it though. Not because the build didn’t work – it did. I used it myself for a while and even got as far as having some people sign up on a waiting list. Thanks for to those who expressed interest!
I’m shelving it because Strava themselves rolled out MCP access to everyone’s ride data this year, and that quietly wrecked the specific bet I made.
What it was
Three apps, one Turborepo: a Hono API, an Expo app for iOS/Android, Postgres behind Drizzle on Neon. Clerk for auth, Stripe for payments, Resend for email, Claude Sonnet 4 doing the actual coaching bit. Rides came in through Strava OAuth, Zwift, or a raw FIT upload if neither worked.
On top of that sat four things that the AI actually wrote:
- A rolling 7-day training plan (cached 24 hours so I wasn’t burning tokens every time I opened the app),
- a weekly review that’s meant to read like an email from an actual coach, and
- a per-ride assessment that fires right after a sync, and a race plan for pacing and fuelling.
If I’m honest, none of that list was the hard bit though. Wiring a call to Claude with a system prompt and some numbers was quick. What actually ate the most time was making it trustworthy enough that I’d take training advice from it – and I only found the places it wasn’t trustworthy because I was the user myself.
Why I actually stopped
I submitted the app to Strava for approval and to get the API limits lifted so I could open it up to my wait list. Days turned into weeks, weeks turned into months, and then finally I heard that Strava had decided to give every user MCP access to their own ride history.
This meant the thing I was thinking of trying to build a business around, “connect your data, get an AI to make sense of it,” was now something anyone could get by pointing a general assistant at their own account. Swanny’s edge was never really the AI. It was the plumbing that turned messy ride data into something an LLM could reason about without hallucinating half of it. And that plumbing was what just stopped being scarce, more or less overnight.
I don’t think it kills the whole category though – there’s real depth left in the sport-science side that a generic query won’t hand you for free: interval detection, zone modelling, periodisation, the trust guardrails above. But it kills the version I’d built, where “we plug into your data” was doing real work in the pitch.
I could have kept building anyway. I’d already put a time into it, the app worked, and it was tempting to just keep going because it existed. Instead, I looked at what the market had just done to my actual differentiation and called it, rather than defending a plan because I’d already started it.
What I actually took from it
Setting aside that I got an API, a mobile app, a schema, auth, payments and four working AI features out in about a week, with Claude as my partner – the part I’d genuinely stand behind is the judgment calls sitting underneath all of it.
Using the product myself, every day, helped me:
- Decide where the quality bar was,
- Decide what had to be non-negotiable, even when nobody’s asked for it yet,
- Notice a small domain detail before it quietly poisoned everything downstream of it,
- Understand the unit economics before getting attached to the idea.
None of that is specific to a cycling app though. It’s what good product judgment actually looks like in practice, in my opinion, and I was able to do it at a scale small enough that I could see every part of it myself.
