GolfJoy · 2026 · Completed project-based engagement
From a product idea
to a working system.
I was the project lead and sole developer for the GolfJoy software described here, using AI tools while retaining responsibility for implementation, integrations, testing, and delivery. The work spans regional websites, venue operations, a native sensor app, and the content management system behind the storefronts.
My responsibility covered technical decisions, code review, integration, testing, and delivery. The products also depend on existing hardware, payment providers, content, and business operations. Product and source-code ownership remains with the respective owners.
Company letter ·
Engineering contribution,
documented by GolfJoy.
The company identifies Yuan Zhou as the primary project lead and sole developer responsible for technical implementation and production deployment of the five projects named in this letter.
Five projects documented in the letter
- GolfJoy China official website
- GolfJoy U.S. official website
- GolfJoy Play
- GolfJoy Play native application
- GolfJoy Content Management System (CMS)
The letter records delivery responsibility as of its date. The case study separately identifies the public preview and deployed product links available for review.
Read the original company letter ↗
01 / GolfJoy
Run the venue.
I connected booking, pricing, memberships, payments, and venue workflows in one system. Venue-specific rules remain attached to the location they belong to.
- Context
- A booking has to agree with the venue's opening hours, price rules, membership entitlements, and physical simulator setup.
- My role
- I implemented the customer and operator flows, backend integration, and delivery. Venue operations and payment providers remain separate responsibilities.
- Architecture
- Customer or operator → venue-scoped API → booking, pricing and membership records → payment and simulator integrations.
- Decision
- Keep venue identity and permissions in the backend contract. Resolve prices on the server so the browser is not the authority for a charge.
- Tradeoff
- Shared workflows reduce repeated implementation, but every operation must carry the correct venue context. Capability flags handle differences between locations.
- Validation & evidence
- The public booking interface and venue guide demonstrate the user flows. The guide contains test venues and sample records; it does not independently prove concurrency behavior or payment reconciliation.
Management screens: public venue guide, with test venues and sample records. Read the Play PDF ↗
02 / GolfJoy
Every swing. Live.
I connected a mobile interface to launch-monitor data through native integrations and a shared sensor protocol core.
- Context
- A player needs useful shot feedback while standing away from the phone, with hardware discovery and the data connection working together.
- My role
- I built the app experience and device integrations. The work uses existing launch-monitor hardware and its protocol; it does not claim ownership of the hardware.
- Architecture
- Bluetooth discovery → Wi-Fi data link → shared C++ protocol core → native Android/iOS bridge → live metrics and practice history.
- Decision
- Share protocol handling in C++ while keeping platform-specific connection work in Java and Swift. Present large landscape metrics and optional English shot readout.
- Tradeoff
- A shared protocol core avoids divergent decoding logic, but native bridges and device lifecycles still need platform-specific testing.
- Validation & evidence
- The store listing and official screenshots show the Android experience. Store screenshots include sample sensor values. Android availability does not establish an Apple App Store release.
Official Google Play screenshots. Live-metrics image uses sample sensor data.
03 / GolfJoy
Find it. Compare it. Build it.
I built product discovery, comparison, a simulator builder, content management, and checkout integration, with source-grounded AI product guidance.
- Context
- Simulator buyers need to connect room constraints and product specifications to a purchase, while the team needs to maintain the content.
- My role
- I designed and implemented the shopping experience, CMS workflows, integrations, and release process. Shopify handles the commerce services behind checkout.
- Architecture
- Managed product content → discovery and simulator builder → approved product mapping → Shopify checkout. AI guidance uses approved product sources.
- Decision
- Keep product and price authority outside model-generated text. Ground guidance in approved sources and use a controlled mapping into checkout.
- Tradeoff
- A bounded product catalog is easier to review but requires content and mappings to stay current. The assistant cannot safely improvise unsupported product facts.
- Validation & evidence
- The public preview exposes the product flows and the web engineering credit names Yuan Zhou. Screenshots show interface behavior, not sales impact or measured AI accuracy.
04 / GolfJoy
Built for China, too.
I built regional commerce and a release path that separates China delivery from cross-border content dependencies.
- Context
- Regional builds need the right content and payment environment without making every build depend on a live cross-border database connection.
- My role
- I implemented regional content and commerce integration, signed content releases, build validation, and rollout and rollback procedures.
- Architecture
- Regional CMS export → signed content snapshot → object storage → local verification and build → versioned deployment.
- Decision
- Use an immutable signed snapshot as the build input. Validate identity, integrity, freshness, and region before a build is allowed to proceed.
- Tradeoff
- A snapshot makes a release reproducible and independent of the live CMS, but publishing new content requires an explicit export and release. Signing keys and snapshot age need operational care.
- Validation & evidence
- The official storefront and its public credit support product and contribution attribution. The linked code lab is a separately written, sanitized reference implementation of release checks, not employer source code.
How AI fit into the work.
I use AI tools to accelerate implementation while retaining responsibility for problem decomposition, architecture, code review, testing, integrations, and release decisions. I stayed responsible for the interfaces between those tasks: data contracts, environment boundaries, failure cases, and release checks. The code lab makes one part of that engineering approach available to inspect and run.
Engineering explanations are my account of the implementation. Public links and screenshots support the specific product and attribution evidence described beside each area. No employer source code, customer records, or internal endpoints are published here.