Gary Murray – Product Lead

  • Swanny – an AI-based cycling training app I built with Claude, and then stopped

    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.

  • Dynamic Pricing Has a Moral Problem

    Same hotel. Same room type. Same number of guests. One weekend apart. The listing on the left is €2,540 per night; the one on the right is €168 at the Raddison Hotel in Dublin City centre. Whatever combination of demand, events, occupancy forecasts, and algorithmic enthusiasm produced the higher figure, it raises a bigger question than whether one room was overpriced on one particular weekend.

    It asks whether dynamic pricing, as currently practised, still has any meaningful ethical boundary.

    The standard defence

    The argument is familiar:

    • Supply tightens, demand increases, prices rise
    • Hotels, airlines, taxis, and ticketing platforms all use this logic
    • It’s presented as neutral, efficient, even inevitable
    • The market moves; prices follow.

    But that description hides something important. Dynamic pricing isn’t simply a mirror reflecting reality. It’s a choice about how aggressively a business responds to scarcity. And like any choice, it can be made with restraint — or without it.

    Where the discomfort starts

    Most people don’t object to prices changing. They object to prices becoming unmoored from any ordinary sense of proportion.

    A moderate increase feels annoying but understandable
    A 15x markup on the same room one weekend later feels different — it doesn’t suggest healthy market responsiveness, it suggests a business has decided that urgency, limited alternatives, and customer need are opportunities to be fully exploited

    The defenders of this kind of pricing tend to retreat into narrow economic logic: if someone will pay it, the price is justified. But willingness isn’t the same thing as fairness.

    A person may pay because they’re stranded, under pressure, attending an important family event, or left with no viable alternative. The transaction may be voluntary in theory while feeling coercive in practice.

    Markets are very good at discovering what people can be made to pay. They’re less good at determining what ought to be charged.

    The real issue: indifference

    Ethical business behaviour has always required more than technical market efficiency. It requires judgement — recognising that the most profitable option isn’t always the most legitimate one. Reputation, trust, and basic decency should impose limits that an algorithm never will on its own.

    And that’s the real problem with dynamic pricing in its most extreme form. It’s not merely that it’s expensive — it’s that it’s indifferent.

    No person has to stand over the number and defend it. No one has to say, publicly, that a hotel room available for €168 next weekend is worth €2,540 this weekend because the software says demand is high enough. The machine produces the number, and the business takes cover behind the language of “optimisation.”

    Customers aren’t fooled by this arrangement. They may not know the formula, but they know the feeling: this company charged the maximum it believed the situation would bear.

    That may be smart revenue management. It may also be a slow erosion of trust.

    So where does that leave us?

    Dynamic pricing isn’t going away. Nor should it — there are sensible and defensible uses for it. But businesses that rely on it should stop pretending that every market-clearing price is automatically a morally respectable one.

    A society that accepts this logic without question eventually ends up treating urgency as a luxury good.

    And that’s a far more troubling price than anything on a hotel website.

  • Stop building museum pieces

    There’s a pattern I keep seeing in product teams: we aim for the “right” version of something, and in doing so, we never actually ship the useful version.

    Nobody wakes up intending to slow things down. It happens gradually:

    • We add one more abstraction “because we’ll need it later,”
    • We align the design system,
    • We make it extensible from day one,
    • We wait for the other team to catch up, and
    • Suddenly the customer has… nothing.

    So this is a post about resisting that pull and a few principles you can use when you feel the work drifting away from real users.

    1. Perfect is usually optimized for us, not for customers

    When teams say “let’s do it properly,” they’re almost always talking about internal satisfaction: elegant code, unified UI, one way of doing things, future-proofing.

    Customers do not care.

    Customers care about:

    • Can I do the thing?
    • Are the numbers right?
    • Is it faster than the way I do it today?

    If the answer to those three is “not yet, we’re still designing the framework,” that’s a smell. That’s when “perfect” has won on the inside and “useful” has lost on the outside.

    Principle: if the work looks impressive in a demo to your colleagues but invisible to a customer, you’re optimizing the wrong audience.

    1. Momentum > completeness

    A lot of products get stuck because they try to do two hard things at once:

    • Replace or clean up the old way, and
    • Introduce a better, new way.

    Doing both simultaneously sounds responsible, but in practice it doubles the surface area, doubles decisions, and makes it harder to declare anything “done.”

    It’s almost always better to pick one axis:

    • either: “We’re cleaning up what exists, no new scope.”
    • or: “We’re adding net-new value, we’ll redo the old thing later.”

    Trying to do both is how you end up with PM notes like “blocked on design direction” for weeks.

    Principle: reduce simultaneity. Ship on one dimension at a time.

    1. The hidden tax of “doing it right”

    “Let’s do it right” sounds mature, but it has a hidden cost:

    • It introduces new dependencies (on platform, on design systems, on other teams),
    • It raises the minimum viable release to something non-minimal,
    • It makes it harder to test with real users because nothing is small anymore.
    • What people call “right” is often just “more coordinated.”

    Coordination is good. But coordination is not value.

    Principle: don’t let “future-proof” outvote “presently useful.”

    1. Ship the observable thing first

    You can’t learn from a Figma file. You can’t learn from an architecture diagram. You can only learn from something a real person used, even briefly.

    So a good forcing question is:

    “What is the smallest version of this work that a real user can see and tell us something about?”

    It’s not:

    • “What’s the smallest version that makes the system elegant”, or
    • “What’s the smallest version that supports every extension”, or
    • “What’s the smallest version that marketing can make a full launch page for.”

    Just: can someone use it and react?

    Principle: if you can’t put it in front of 3 users this week, it’s too big.

    1. Defer platformization

    Teams love to build for “everyone who might use this later.” That’s how you end up with general-purpose, no-purpose features.

    There’s a better order:

    • Build the thing for you (your current use case),
    • Let it prove itself,
    • Then harden it for others.

    This feels backwards to some people and you may hear some shouting: “We’ll have to refactor!” But, refactoring a working, used feature is always easier than resurrecting an unused, overbuilt one.

    Principle: make it useful, then make it reusable.

    1. Say what you’re not doing

    A lot of scope creep is just unspoken anxiety.

    • Design worries: “Will we have to redo this for mobile?”
    • Engineering worries: “Will this scale when we add X?”
    • Product worries: “Will partners be angry we didn’t make it extensible?”

    If you don’t name the boundaries, people will quietly build for the biggest possible future.

    So write it down, for example:

    • This version is web-first.
    • This version is for internal data only.
    • This version is not extensible.
    • This version is about visibility, not automation.
    • This version is for 1–2 key personas.

    When you do that, it becomes much easier to ship something small without everyone feeling like they failed the imaginary final state.

    Principle: constraints make shipping emotionally safe.

    1. Lead with the commercial / outcome story

    One more thing that helps: tie the smaller, shippable version to an outcome that leadership cares about.

    Examples:

    • “Shipping this thin slice unblocks real-user feedback in the same quarter.”
    • “Getting this out gives us retention / activation data we can’t get from mocks.”
    • “A narrow v1 reduces migration/support until we know merchants actually want it.”

    When there’s a clear business reason to ship small, it’s much harder for “let’s just make it perfect” to win the argument.

    Principle: small releases need a big why.

    1. How to spot you’re drifting into perfectionism

    You can almost diagnose it from meetings:

    • “Let’s wait until the component library is ready.”
    • “Let’s not show it to users until we can tell the whole story.”
    • “Let’s solve this for all products / all regions / all payment methods.”
    • “Let’s figure out the long-term IA first.”
    • “Let’s make it consistent with the future experience.”

    None of those are bad sentences. But if they appear before anyone has seen a working version, you’re in danger territory.

    Principle: if future concerns show up before present value, you’re drifting.

    1. The stance

    If I had to compress this into one stance, it’s this:

    Shipping is how we find out. Perfect is how we postpone finding out.

    You don’t discover reality by thinking harder. You discover it by putting something small, slightly embarrassing, slightly incomplete in front of the people you’re actually building for.

    If it lands, great, you’ve earned the right to make it nicer.
    If it doesn’t, great, you found out early and have not over invested.

    Either way, you’ve learned from real world feedback, from your customers who pay to use your product.

  • AI as a Consumer Advocate

    Let me preface all of this by saying I’m not a lawyer.

    I’m just someone who bought something (a fairly expensive thing at that)…and then a safety recall on a part of that product turned that shiny new purchase into something I couldn’t use a few months later.

    What followed was a maze: the seller of the product pointed one way, the manufacturer of the recalled parts another, I got different case numbers, mixed shipping instructions, and at one point there weren’t even boxes available to send the part in for inspection.

    Meanwhile, my new product was for all intents and purposes rendered unusable unless I was willing to incur additional costs to make it temporarily usable.

    The turning point in my experience wasn’t a magic phone call. It was opening ChatGPT and saying, “Here’s my issue, explain my rights like I’m five, and help me ask for the right fix if there is one.”

    The TL;DR on what I faced

    • Mixed messages between seller and manufacturer
    • Confusing “send it here / no, send it there” instructions
    • Logistics issues (even simple packaging became a blocker)
    • Weeks of waiting with an unusable product

    I didn’t want drama; I wanted a safe, working product, without incurring extra costs or having to deal with very unclear timeframes.

    How ChatGPT actually helped me

    ChatGPT helped point out that the part manufacturer in this case offered only one solution which came with significant inconvenience.

    ChatGPT helped me understand that legally this was not correct, and further to this, that legally, the seller was actually obliged to fix it free of charge, within a reasonable time, and without significant inconvenience; and when it’s a recall, consumers should have a real choice of remedies (if repair isn’t possible, that usually means replacement or refund).

    This meant that I could actually contact the seller of the product (who at this point was trying to quietly stay out of things) and ask for a solution.

    ChatGPT helped write the emails I’d probably have spent ages trying to write – keeping them short, calm and specific. It helped me:

    • Summarise my timeline
    • Ask for practical outcomes (safe replacement or refund)
    • Include logistics (collection, packaging, fitting)
    • Set a clear, short deadline

    And maybe more importantly, it kept my tone steady, even when the first response I got from the supplier was pretty patronising and had me getting even more frustrated!

    But, with ChatGPT, there were no rants. Just a consistent “Here’s the problem, here’s what the rules say, here’s what I’m asking for.”

    It also gave me a backup of an escalation map. If things stalled, I knew the next steps (consumer mediation, small-claims-style routes). Just knowing that made me more confident in my communications with both the seller and manufacturer.

    The key rights that mattered (EU-flavoured, in plain English)

    • Seller responsibility: Your contract is with the seller. They’re on the hook to make it right free of charge, as quickly as reasonably possible, and without major hassle for you—collection, packaging, and fitting included.
    • Recall remedies: In a recall, you should get a genuine choice (often replacement or refund if repair isn’t feasible). If it drags on or becomes a pain, you can push for a refund.
    • No extra costs: You shouldn’t pay to fix a safety problem with something you already bought.

    Note: this is a practical summary. It’s not legal advice.

    The playbook I used (steal this if you want!)

    1. Write a timeline. Dates, who said what, any blockers (routing mistakes, no packaging, etc.).
    2. Ask ChatGPT for a checklist of your rights tailored to your situation.
    3. Send a calm, clear email to the seller (cc the manufacturer if helpful):
      • “The product is unusable due to a safety issue.”
      • “Please provide a safe replacement or an adequate refund.”
      • “Cover the logistics and fitting.”
      • “Please confirm by [specific date].”
    4. Don’t confuse goodwill with the fix. The seller tried this, but reimbursing small costs is nice; it’s not the remedy.
    5. Follow up on your deadline with the same message—polite and persistent.
    6. Escalate if needed. Knowing you have options keeps things moving.

    How it ended

    After a few firm, well-structured exchanges, I got a free replacement within a week that solved the safety issue and made the product usable again. Not instant, but once the requests were precise and grounded in the right standards, things clicked.

    Why this matters

    Most of us don’t speak “legal.” We shouldn’t have to.

    ChatGPT didn’t argue in court; it helped me ask for the right thing, the right way, at the right time. That alone turned a frustrating recall into a manageable process, and a better outcome (for me at least).

    Prompts you can copy/paste

    “Explain my rights in the EU when a product I bought is affected by a safety recall. Keep it plain English and actionable.”

    “Draft a short, polite email to the seller asking for a remedy within a reasonable time and without significant inconvenience. Include collection/packaging/fitting and a deadline.”

    “Turn this timeline into a concise email with dates.”

    “If the manufacturer only offers replacement, when can I ask for a refund? Keep it brief.”

    “Write a firm but friendly follow-up if I don’t have tracking/ETA by [date].”

    Legal disclaimer

    This was one person’s experience (mine), and as such is not legal advice. But if you’re stuck in a similar mess, this approach may help you move from confusion to resolution—without needing a law degree.

  • If your design only works in colour, it doesn’t work

    Over the weekend, I signed up for a product that asked me to create a password:

    Said signup form…

    Simple enough, right?

    Except the form showed which rules I’d met with little red and green dots. No text, no icons, no context. Just colors.

    Guess what? If you’re one of the 300 million people worldwide with colour blindness, that signup form might as well be written in invisible ink.

    And let’s be clear: this isn’t just bad design. It’s exclusion.

    The Ugly Truth About Color-Only Design

    When you rely on colour alone, you’re silently telling 8% of men and 0.5% of women this product wasn’t built for you.

    That’s thousands of potential customers bouncing at the very first step because they can’t tell which requirement they failed. Imagine investing in ads, marketing, onboarding flows…and then losing users because you couldn’t be bothered to add an icon or a line of text.

    This isn’t just an accessibility issue. It’s a conversion killer.

    Why We Should All Care

    Accessibility isn’t niche. If your product scales, color blind users aren’t “edge cases” — they’re paying customers.

    It’s lazy design. Adding an icon or some microcopy is hardly expensive, yet it prevents real exclusion.

    We’re all one bad design choice away from alienating people who would love to use what we’ve built.

    And honestly? It’s 2025. We should know better by now.

    What Good Looks Like

    Here’s the bare minimum we owe our users:

    ✔️ Pair color with symbols (✔️ / ✖️ or clear icons)
    ✔️ Add short text (“Needs a special character”)
    ✔️ Test your work with color-blindness simulators
    ✔️ Follow WCAG – they’ve been telling us this for years

    Accessibility isn’t rocket science. It’s empathy in interface form.

    A Call-Out to Our Industry

    The next time you design a flow and reach for green = good, red = bad… STOP!

    Ask yourself:

    • What happens if someone can’t see the difference?
    • Would they still understand what to do?
    • Would they still feel welcome here?

    If the answer’s no, you’ve just built a gate that keeps people out.

    And that’s on you — not them.

    Let’s Do Better

    Every time we ignore accessibility, we exclude real people. People trying to give us their money, time, and trust.

    Design isn’t just about aesthetics. It’s about inclusion.
    And exclusion, whether intentional or not, is always bad design.