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.