A mobile golf decision-support application built to replace guesswork about carry distance with a range a player can actually trust.
Source code is private. This repository is a public case study covering the problem, the product decisions, the build process, and the pilot.
Most golfers treat a club's carry distance as a single fixed number, and that number is almost always the best shot they have ever hit with it. In practice, playable carry is a range shaped by strike quality, clubhead speed, delivery, conditions, and shot intent, which means a single best-case figure produces bad gapping, poor club selection, and avoidable scoring mistakes.
The failure compounds. A player who believes a seven iron carries 165 because it did once will keep coming up short, and will then adjust by swinging harder, which degrades strike quality and widens the dispersion further. The number was never wrong in isolation. It was wrong as a planning input, and it was being used as a planning input.
Launch monitors have made data widely available, but availability is not the constraint. Serious amateurs, coaches, and fitters have more numbers than they had ten years ago and still make the same club selection errors, because the data arrives as a session report rather than as something usable standing over a ball. The gap CarryMap addresses is not a measurement gap, it is a translation gap between the data a player already has and the decision that player has to make.
CarryMap organizes a player's own performance data into decisions rather than into statistics.
Club profiles establish a playable stock carry window for each club rather than a single number. Bag mapping shows distance coverage and gaps across the non-putter clubs, which is where most gapping problems become visible for the first time. The wedge matrix builds a controlled scoring-zone plan across quarter, half, three-quarter, and stock setups, using stock to mean a controlled repeatable swing rather than a maximum effort one. Bag insights organize the underlying performance data into usable conclusions. Competition Mode disables the recommendation tools while preserving static player data, which keeps the application usable in settings where the rules do not permit assistance.
The application is organized around four sections covering home, bag, gaps, and wedges, and the workflows cover onboarding, bag setup, club management, gap review, and wedge planning.
Several decisions in this build were arguments with myself before they were features, and they are the ones most likely to be relevant to anyone assessing product judgment rather than golf knowledge.
The putter is excluded from bag mapping. Carry windows and gap analysis are meaningless for a club that is not being carried through the air, and including it would have made the visualization consistent at the cost of making it wrong.
The beta is local-first and manual. No backend was wired in, and data entry is deliberate rather than automatically imported. This was the decision I went back and forth on most, since automatic import from launch monitors is the obvious feature request and the obvious differentiator. I built it manually anyway, because the product logic and the user experience needed to be validated before infrastructure got added on top of assumptions that might not survive contact with a real bag. Building the integration first would have meant debugging an import pipeline for a data model I was not yet confident in.
Stock is used rather than full, throughout. The language matters more than it appears to, because a player who reads "full" will swing at maximum effort, which produces exactly the unreliable number the application exists to replace.
The audience is assumed to be knowledgeable. There are no beginner explanations of what carry distance means, because the intended users are serious players, coaches, fitters, and assistant professionals who find that kind of explanation condescending and will close the application rather than scroll past it.
The application is a cross-platform mobile build using React Native, Expo, and TypeScript, developed with Git-based version control, issue tracking on a Kanban board, and AI-assisted development workflows covering requirements, planning, review, debugging, and documentation.
Delivery ran from requirements through to an eight-user private pilot. That process included defining acceptance criteria before building, release planning, change tracking, structured collection of user feedback, and prioritized issue triage. Eight users is enough to surface usability problems and to find the places where my assumptions about how a golfer would use the tool were wrong. It is not enough to claim product-market fit, and no such claim is made here.
AI supported the development workflow for this product, covering requirements, planning, review, debugging, testing, and documentation. That is not the same thing as the product being AI-powered, and CarryMap is not marketed as such.
The defensible claim is that this is a data-informed golf decision-support product built using AI-assisted development practices. Describing it as an AI product because AI helped build it would be the kind of overstatement that falls apart the moment somebody asks a follow-up question, and the distinction seems worth holding even though the looser version would market better.
Source code, proprietary product logic, the calculation methods behind carry windows or gap analysis or the wedge matrix, real user data, and any configuration or infrastructure detail.
The problem, the reasoning, the product decisions, and the process are documented here. The implementation is not.
applied-ai-operating-system documents the governed multi-agent environment used to support this build.
Christopher D. Sheppard, Tee 2 Green Golf Labs LLC linkedin.com/in/christopherdsheppard