I recently put together strava-coach, a small repository for experimenting with a Strava-focused Custom GPT.
Strava Coach does a surprisingly good job of analyzing workouts with additional context like injuries and rehab protocols, which the default Strava/Fitness trainer apps usually do not represent well:

What stood out, though, was how much bigger the surrounding boilerplate is than the actual meat of the project.
For something like this, the genuinely interesting pieces are pretty limited:
- the connection to Strava
- the system prompt
- the OpenAPI spec for the action
- the privacy policy required to make the flow acceptable to ChatGPT
That is not a lot of “application logic”. In a normal codebase, those parts would be the center of attention.
With Custom GPTs, though, those parts are surrounded by a much larger layer of setup friction.
ChatGPT ClickOps Link to heading
One reason I kept the repo around is that ChatGPT essentially forces us into ClickOps copy&paste workflows.
The prompt goes into a web form. The action schema gets pasted into another UI. OAuth setup happens through screens that are not especially ergonomic. Various URLs have to exist publicly. There does not seem to be a clean “connect this GPT to a repository” model where the configuration simply flows from source control. Wrapping even the bare minimum of CI around the repository balloons the effort tremendously:
- preparing public documents
- hosting the privacy policy somewhere stable
- shaping an OpenAPI document to satisfy the platform
- wiring OAuth correctly
- re-entering configuration by hand in ChatGPT’s UI
For such a small idea, that is a disproportionate amount of scaffolding. The repository helps, but mostly as an external memory aid/documentation for a system that still expects manual assembly.
ChatGPT Flakiness Link to heading
The platform behavior was not especially confidence-inspiring either.
At one point the GPT worked, then stopped working for a few days because the OAuth flow to Strava was failing with 500 errors somewhere on ChatGPT’s side. I had not made a meaningful change that explained the breakage. Recreating the GPT from scratch eventually made it work again, apparently by magic.
That kind of failure mode is frustrating because telemetry and debugging are limited. When something breaks, it is not obvious whether the problem is your prompt, your OpenAPI spec, your OAuth configuration, or just the platform itself having a bad week.
That is manageable for a toy, but it is hard to feel serious about as an engineering surface.
Custom GPT Sharing Woes Link to heading
The most deflating part is that this particular GPT cannot be published or shared as-is.
ChatGPT flags it under usage-policy restrictions with this message:
“May contain content that requires previous authorization, such as brand names, trademarks, or copyrighted content. Authorized users can verify their domain.”

As far as I can tell, that means a Strava-branded GPT is not broadly publishable, despite not collecting any data. There is also no official Strava integration available that would make this feel like a first-class supported path.
We could imagine working around that by pointing the Custom GPT at a proxy we control, or by turning the whole thing into a standalone service instead of a Custom GPT. However, at that point the implementation effort rises quickly, and for a tiny toy the cost/benefit starts looking pretty bad. It is not even obvious to me that every possible workaround would fit comfortably within the spirit of the ChatGPT platform terms.
Closing Link to heading
strava-coach was still a useful experiment, and it’s actually quite good at analyzing workouts. Compared to the workout analysis built into the Strava/Zwift/Wahoo/etc. apps, it can easily take into account additional context like injuries and rehab protocols. Just, everybody has to set up their own GPT.
That does not make projects like this worthless. It just makes them feel less like software you build and more like software you assemble inside someone else’s product.
If you have ideas for alternative “no-code” approaches, let me know in the comments!