Birdie

Birdie started close to home. Growing up around the sport, with my dad and brother both regulars at the course, I had a front-row seat to how competitive club golf actually gets arranged. The WhatsApp threads, the manual scorecards, the prize pools settled informally after the round. A rich competitive culture held together with workarounds.

A typical competitive round looked something like this. Someone floats a brawl over WhatsApp. Confirmations trickle in across a thread buried in forty other messages. Scoring gets set up manually on a third-party app. Results land in a Google Sheet. Handicaps get updated separately, from player input and periodic club syncs, with no validation between them. One miskeyed score or missed update could shift a player's index enough to change their brawl eligibility or flip the net result of a round that already had prize money on it.

Every part of that loop works. None of it is connected. And in a community where these games are taken seriously, that kind of error doesn't just affect a spreadsheet. It affects trust.

That observation needed validation before it became a product. A survey of 50 active golfers at one course in India confirmed it was a shared experience across ages, play frequencies, and competitive levels. That became the foundation Birdie was built on.

The study surveyed 50 golfers at one course in India. Not a broad sample, just an honest picture of one active community and how they actually play.

• Who they wereRegular, committed players ranging from weekend hobbyists to near-daily competitors. Almost everyone participates in tournaments and the majority play monetized competitive games multiple times a week. This is a community that already takes the game seriously.
• How they managed it todayEntirely fragmented. Coordination happens over WhatsApp, bookings go through the club website, and scoring runs on a third-party app. Tournament news travels through club management or word of mouth. Multiple tools, multiple contexts, nothing joined up.
• What they wantedLive scoring and leaderboards were the clear priorities. Most players also wanted better performance tracking and easier ways to set up and manage competitive games. The appetite for a more complete tool was there. A product that connected all of it simply wasn't.
• The finding that shaped the designNot everyone wanted the same depth of experience. Some players wanted live stats and real-time comparisons at every hole. Others just wanted to play and see the result at the end. One app had to serve both without forcing either. That became the core design challenge.
• From findings to playersThe data pointed to four distinct player types, each with different expectations of what an app should do for them. Rather than design for an average user that didn't exist, Birdie was built around all four.

Not everything that was designed made it into the prototype, and that was a deliberate call rather than an oversight. Here is an honest account of where things landed.

• Built & TestedThe core competitive loop end to end. Brawl creation and scheduling, hole by hole scoring, handicap tracking with WHS 2024 compliance and custom club rules, handicap based eligibility for brawls, prize pool automation and splits, live leaderboards, social profiles and friend connections, XP progression and achievements, and wind data visualisation with custom course graphics.
• Designed, Not BuiltGame bookings. The flow was fully designed but not implemented for testing. It requires direct authorisation from the course to go live, so it was deliberately parked rather than shipped half finished.
• Future VisionInteractive shot prediction using wind data, green speeds, course layout, and club selection. The wind visualisation already in the app was designed with this in mind, the groundwork is there, but the feature itself needs a dedicated build phase and richer course data to do it properly.
• StalledPhase 2 of testing was planned around an actual tournament being held at the course, a real competitive event that would have put the full system under genuine pressure. Running it properly needed physical presence in Vadodara and a full time commitment that wasn't possible while finishing my masters at KTH in Stockholm. It remains the most significant thing left on the table.

Phase 1 ran with 18 players at the course in Vadodara. The core competitive loop, brawl creation, live scoring, handicap tracking, prize splits, and leaderboards, was well received across the board. Players engaged with the gamification layer and the brawl management flow held up for casual and competitive use alike.

The feedback that came back wasn't about what was broken. It was about what the app needed to handle the full complexity of how this community actually plays.

• Scorecard ScanningPlayers wanted to photograph a physical scorecard and have scores automatically detected and filled in, useful for rounds that start without the app open or for catching up mid-round.
• More Host ControlThe existing flow required all participants to input their own scores and confirmations. In practice that isn't always realistic. Hosts needed more direct control to process rounds and move things forward without waiting on every player.
• Flexible Prize PoolsEvery brawl runs differently. Some use ranking based splits, some are winner takes all, some have side pots. Players wanted the prize system configurable enough to handle any format without manual workarounds.
• WhatsApp IntegrationScheduling still lives in WhatsApp for most players. Connecting the app directly for game alerts, brawl invites, and tournament notifications would remove the biggest remaining friction point.
• Interactive Hole Maps & Shot TrackingPlayers wanted the hole graphics to go further, syncing with GPS or health tracking devices to enable shot trails and pre-round shot planning. This would realistically need a dedicated iOS or Android app rather than a PWA to work properly.

Birdie was the first project where I designed and built something end to end on my own, with AI as a collaborator rather than a shortcut. Using Cursor to vibe-code the architecture as the UX took shape pushed me to understand how the tech stack actually works in depth, not just what it could do in theory but where its limits were and what was realistically buildable. That constraint turned out to be a useful design filter. It kept the project grounded in something real rather than a fancy idea that looked good in Figma but fell apart in production.

The process was faster and more iterative than designing and handing off separately, but it also meant some decisions got made in code before they were fully thought through. In hindsight, spending more time on the information architecture before touching the builder would have saved several rebuild cycles, particularly around the brawl management flow which went through the most iteration during testing.

The other thing I underestimated was the operational side. Getting 18 players to test a prototype is straightforward. Running a full tournament through the app, with real stakes and real prize money, is a different commitment entirely. Phase 2 made that clear quickly. A project like this needs physical presence and dedicated time, neither of which I had while finishing my masters at KTH in Stockholm.

What I would build next, informed directly by what players asked for:

• Scorecard Scanning
• Expanded Host & Admin Controls for Brawls
• Brawl and Tournaments Prize Mechanics and Models
• WhatsApp Integration
• Published On-Device Application rather than Web App