PingNow: Making it easier to get your golf group onto the course

Visit the site:pingnowgolf.com

TL;DR: I built PingNow, a group tee-time alert service for Bay Area golfers. Instead of just notifying individuals when a slot becomes available, PingNow helps an entire group find a time that works for everyone. Built with a technical teammate over four weeks, it grew into a live website and app covering around 40 public golf courses.

The problem wasn’t finding a tee time

I love playing golf. It’s my way of touching grass and keeping sane through otherwise busy weeks.

When I moved to San Francisco, I quickly discovered that getting a Saturday morning tee time at some of the Bay Area’s public courses was surprisingly difficult. At Presidio Golf Course, for example, the good slots could disappear within minutes of becoming available, and cancellations were often the only second chance.

But finding an available slot was only half the problem.

You still needed your group of golfers to agree on it. Someone would refresh a booking website, screenshot a handful of options, send them to the group chat, chase everyone for a response, and refresh again (can you guess who that was in my group?). By the time everyone agreed, the tee time was usually gone. Ugh.

It struck me that most existing solutions were addressing the wrong half of the problem. There were already services like RapidTee notifying individual golfers when tee times became available. But an alert is only useful if you can actually get your group onto the course.

The opportunity was to build around the group, not the individual.

Making the round the starting point

That became the central idea behind PingNow.

Instead of setting up individual alerts and coordinating over iMessage, you create a round with your friends, preferred courses, date and time window. PingNow monitors those courses and notifies everyone when a matching tee time becomes available.

The group then has a shared board of available options. Everyone marks the times that work for them, and once everyone agrees on a slot, someone can book directly through the course’s website.

Simple enough in theory! But there were interesting product decisions along the way.

The first version looked much like any other alert app: individual tee time watches, a separate alerts tab and a friends list. The group was there, but it wasn’t central to the experience: the alert told everyone that a tee time was available but it didn’t tell anyone whether the group could actually play. People still had to leave the app, discuss their availability in iMessage, and coordinate who would book. We had made it easier to find a tee time, but not much easier to organize a round.

So we rebuilt the product around a different concept: the round.

A round represents the group’s intention to play. It brings together what v1 kept apart (the watches, the alerts tab and the friends list), so the alert follows the round instead of living on its own. When a tee time opens up, it lands on the shared board described above, where everyone can mark whether it works.

The difference was that the coordination now happened inside the product. Instead of an alert being the end of the experience, it became the start of a shared decision.

It was a small conceptual shift that made a meaningful difference to how the product worked.

Building the infrastructure behind the alerts

PingNow started as a four-week sprint with a technical teammate (shoutout to Sihoon).

I led product, UI/UX, the website, frontend and parts of the backend. Sihoon focused on the crawler and underlying infrastructure.

We shipped as an installable web app rather than a native iOS application since it was the fastest way to get something onto people’s phones with push notifications without taking on the overhead of building and distributing a native app.

Once the user experience was mapped out, the frontend was relatively straightforward. The harder problem was getting reliable access to tee-time inventory. Our initial assumption was that we could crawl every public golf course without much difficulty; that turned out to be rather optimistic.

The 40 public courses we covered were spread across six booking vendors. Each had its own infrastructure and access requirements. Some exposed relatively straightforward endpoints and others required browser sessions or different handling.

We needed a crawling system that could adapt to each vendor. That meant using different access methods, tuning request frequency, maintaining sessions, and adjusting how often we checked each course. We also had to manage requests at the vendor level rather than treating every course independently. Multiple courses could share the same booking vendor, so aggressive requests to one could affect access to all the others.

The less glamorous part was making sure the system knew when something had gone wrong.

One particularly memorable incident involved a course that continued returning successful HTTP responses while quietly fetching the wrong date range. Our dashboard showed everything as healthy, but future tee-time inventory had effectively disappeared. We quickly learned that a successful request doesn’t necessarily mean a healthy system.

Over time, we built better checks around data completeness, freshness, and unexpected changes. By mid-July, we were tracking roughly 31,000 future tee times across the 40 courses we covered, with a 24-hour crawl success rate of around 97%.

The visible product was only a small part of what made the experience work. Behind every alert was a system that had to keep checking, interpreting, and validating data from a collection of very different booking platforms.

Lessons learned

Consumer products are built on trust, not just functionality

Most of my previous experience had been in B2B, where the dynamics of finding customers, building relationships and demonstrating value are quite different.

With PingNow, I became much more conscious of the importance of community.

It wasn’t enough to build something that worked. We needed golfers to trust us with something they cared about. They needed to feel that we understood the sport, shared their enthusiasm for it and would look after them.

Community building wasn’t just a distribution strategy…it was part of the product itself.

I also realized that the product’s growth loop came with an interesting challenge. Golf is typically played in foursomes, which means every round can bring new people onto the platform. But it also means that a signup isn’t necessarily an activated user. PingNow only really demonstrates its value when multiple people are coordinating inside the same round.

Getting someone to download an app is one thing. Getting their entire golf group to use it is another.

Knowing what to build less of is harder than it sounds

We also spent time designing things that never made it into the product.

For example, we explored a concierge booking feature that would let PingNow book tee times on behalf of users, as well as a potential freemium monetization model.

Both were interesting directions, but neither was necessary to test the central hypothesis.

I’d already been working through a similar lesson with Linchpin: a prototype should test a specific hypothesis, not try to become a complete product. But I didn’t fully apply that lesson here. We had a four-week sprint and a relatively small beta, yet still found ourselves building for possibilities well beyond what we needed to validate.

In hindsight, we could have tested the core idea with a much smaller product. It’s easy to confuse building more with making more progress. They’re not the same thing.

Getting two people moving in the same direction

This was my first time building a product so closely with a technical teammate. One thing that surprised me was how much we could get done with just two people by focusing on complementary workstreams. I could own the product and user experience while Sihoon focused on the crawler and infrastructure, allowing us to cover a lot of ground without stepping on each other’s toes.

But splitting responsibilities was only part of it. We spent enough time upfront aligning on what we were trying to build and, just as importantly, what a good user experience should feel like. That meant caring about everything from keeping the product simple to how quickly alerts arrived, how the in-app experience worked alongside push notifications, and the small details that made the whole thing feel considered. Having that shared quality bar meant we could develop independently while still pushing each other to make the product better.

Since PingNow started with a problem I personally cared about, I also felt responsible for bringing that enthusiasm into the collaboration. I wanted Sihoon to be just as excited about the problem as I was. That meant spending time together beyond dividing up tasks: talking through the problem, exploring ideas, and getting excited about what we could build. I came away thinking that when two people genuinely care about the problem they’re solving, the process of building becomes a lot more enjoyable.

Where things stand

PingNow has a live website and app, and golfers have used it to find and book tee times. The crawler is currently paused, so the monitoring that powered the alerts isn’t running at the moment.

For now, I’m happy to leave it as something real that we put into the world.