Module 1
Scorecard
DeuceGC, Montclair Sports LLC · Case study
DeuceGC: Designing a practice loop for golf improvement
Evolving a broad golf app into a focused player-development system that helps serious golfers plan practice, log structured sessions, review evidence, and decide what to work on next.
Current product direction: a player-development system organized around planning focused work, practicing deliberately, reviewing progress, and returning to the next session with a clearer decision.
- Role
- Solo founder, product designer, full-stack implementer, and AI-orchestrated builder
- Company
- DeuceGC, Montclair Sports LLC
- Team
- Solo founder-led product with AI tools, MCPs, prompt engineering, and custom Codex skills as the execution and advisory layer
Scope
- Product strategy
- Information architecture
- Interaction design
- Design system direction
- Full-stack implementation
- Prompt engineering and MCP workflow design
- Analytics and launch-readiness planning
Labels
- Shipped
Summary
Executive summary
Problem
Golfers can collect round and practice data without a clear bridge to what they should practice next.
Approach
I narrowed DeuceGC from a broad golf product into a Plan -> Practice -> Improve -> Perform loop, while keeping Coach/NCAA pilot work and GPS/Terrain as controlled expansion surfaces.
Outcome
The product matured into a shipped web system with practice capture, scheduling, sessions and review, pricing and entitlements, analytics contracts, launch-readiness guardrails, Coach pilot surfaces, and incoming GPS/Terrain support.
Guided Flow
Move from intent to practice evidence
The core walkthrough follows one serious golfer from a practice priority into a drill, a live session, and a review state that points back to the next action.
Problem
Diagnosis
The useful design problem became clearer as the product moved from broad golf tracking toward next-practice decision support.
Git history
The original October 2025 implementation grouped a dashboard, course planner, round analyzer, and putting practice. The breadth was credible, but the product did not yet have a single improvement spine.
Research synthesis
Short-game research and category review suggested a gap between emotionally memorable misses, diagnostic evidence, and the next practice session.
Strategy docs
A May 2026 lean-canvas pass framed the product risk as expectation sprawl across rounds, practice, coaching, range, pricing, and recommendations.
Constraints
What was fixed
Practice happens outdoors and in motion
Setup, live logging, and review had to work for golfers at a putting green, short-game area, range bay, or post-round moment - not only in a desktop analytics session.
Trust comes before AI language
The system can use recommendation scaffolding, but the public case study avoids unproven improvement claims and keeps the focus on evidence, review, and next-action clarity.
Coach is upcoming pilot work
Coach is an upcoming pilot surface for team and NCAA workflows, while the near-term product focus remains getting the Core tier into more golfers' hands.
Terrain is incoming infrastructure
Terrain is the incoming GPS layer for spatial practice and range/course context. The story can name it without claiming validated GPS reliability or usage outcomes.
Founder-built means scope discipline
AI tools, MCPs, custom skills, and prompt engineering accelerated execution, but the hardest product decision was still what not to make central.
Principles
Design principles
01
Lead with the next action
The experience should answer 'what should I practice next?' before asking a golfer to interpret charts or configure a complex tracking setup.
02
Design for reps, not reports
Practice screens prioritize fast session start, make/miss capture, and review over dense analysis during the session itself.
03
Keep expansion surfaces honest
Coach/NCAA and GPS/Terrain show system ambition, but the main case-study story stays anchored on the Core practice loop and its evidence model.
Exploration
Concept exploration
The case study arc is product narrowing. DeuceGC moved through several defensible states before the practice-loop thesis became the clearest public story.
- Rejected as the main product story
Direction A
Broad golf app
The first implementation grouped dashboard, course planner, round analyzer, and putting practice. That breadth made the product feel complete, but it weakened the promise around what to practice next. - 1Dashboard
- 2Course planner
- 3Round analyzer
- 4Putting practice
- Useful breadth
- Weak next-practice spine
- Too many jobs competing for first-run attention
- Useful mid-state
Direction B
April beta surface
By spring 2026 the product had more serious beta infrastructure: practice, range, schedule, rounds, pricing, beta/admin, legal, and visual consistency. Capability increased, but the surface area still needed sharper hierarchy. - 1Landing
- 2Dashboard
- 3Practice module
- 4Schedule
- 5Range and rounds
- Beta maturity
- Commercial and access model emerging
- Surface-area risk still visible
- Chosen thesis
Direction C
Player-development loop
The strongest direction made Plan -> Practice -> Improve -> Perform the organizing model: start with intent, run a focused session, review the signal, and return with a clearer next decision. - 1Plan
- 2Practice
- 3Improve
- 4Perform
- Clearer promise
- Better mobile practice fit
- Expansion surfaces support the loop instead of replacing it
- Public promise: player-development system for committed golfers
- Dashboard priorities and Deuce Score as decision support
- Practice hub/module sheet as the bridge from intent to drill
- Setup screen reduces configuration before action
- Live logging captures reps quickly
- Session review closes the loop with a next action
- Coach/NCAA pilot and GPS/Terrain stay framed as controlled expansion surfaces
Decision
How we chose
| Option | Practice clarity | Portfolio credibility | Evidence support |
|---|---|---|---|
| All-in-one golf app | Medium | Low | High for the original state |
| GPS/Terrain layer | Medium | Medium | Useful as incoming feature, not main thesis |
| Practice-loop player-development system | High | High | High |
Recommendation
Lead with the practice-loop player-development thesis. It is the clearest design story and the best-supported product arc in the codebase history.
Outcome
What shipped
The verified outcome is product-system maturity and a clearer strategic spine, not a public claim of quantified business impact.
- Product arc
- Broad -> focused
- Core loop
- 4 stages
- Evidence boundary
- No public metrics
Git history shows the move from dashboard/planner/analyzer breadth into a practice-loop thesis.
Plan, Practice, Improve, and Perform now organize the product promise.
PostHog, Stripe, and private customer-feedback claims are intentionally excluded.
DeuceGC now has a shipped production presence, a focused public promise, implemented practice and review flows, commercial access infrastructure, analytics contracts, design-system documentation, a shareable Figma source-of-truth starter file, and launch-readiness standards. The honest next chapter is validation: Core tier adoption, Coach pilot learning, and Terrain/GPS reliability all need evidence before they become outcome claims.
Reflection
Looking back
The senior-design signal in this work is judgment under ambiguity: narrowing a founder-led product from many plausible golf surfaces into a coherent loop, while naming where evidence ends and future validation begins. The tempting move was to make the product feel bigger. The better move was to make the next practice decision clearer.
Available
Want to talk about a problem in this shape?
Best fit for platform UX, growth systems, internal tools, and teams that need a senior IC who can shape the problem and ship the details. I respond to most inbound within a day.