Clappy was one of the first products I built under Staybit, and one of the projects that taught me the most about product validation, positioning, and the danger of falling in love with a pivot too early.
The problem
Clappy started with a very specific frustration: I could not get my pull requests reviewed fast enough.
I had just joined Zendesk and I was still building trust with the team. I did not have the social context that makes someone stop what they are doing and review your code quickly. The work was ready, but I was blocked waiting for approval.
That was the first version of the idea. What if reviewing a pull request earned real recognition, not just more work?
The rewards idea
The original Clappy was not an analytics platform. It was a rewards system for teams. Every employee would receive a monthly balance of points they could give to teammates. You could earn points because someone wanted to recognize your work, and you could also earn points through integrations with tools the company already used.
GitHub could reward someone for reviewing a teammate’s pull request. Salesforce or HubSpot could reward someone for closing a sale. Other integrations could track the behaviors a company wanted to encourage. The points would become an internal currency employees could exchange for real things like company swag, gift cards, digital subscriptions, or other perks.
The idea was simple: make useful work more visible, make recognition easier, and give people a reason to help each other in the moments where work usually gets stuck.
The pivot
When I started building the GitHub integration, the product changed.
GitHub exposed a lot more than a signal that someone had reviewed a pull request. It had commits, pull requests, reviews, merged work, activity patterns, and contribution history across the team. I could pull stats from all users in a company and build a dashboard where a manager could see what was happening inside the engineering organization.
That pushed Clappy toward a different product: performance metrics for engineering teams.
Instead of being a rewards system, it became a developer analytics platform. The product was built around the idea that engineering managers could use GitHub data to understand team contributions and create a layer of gamification around software development.
The product was no longer about rewards. It was a leaderboard.
The launch
I launched Clappy on Product Hunt with the positioning “Performance metrics for engineering teams.” The launch worked as an attention moment. It received a lot of upvotes and won the number one product of the week in the developer tools category.
That felt like validation at first, but it was not the validation I needed.
People signed up, but they did not really use the product. Product Hunt was good for initial exposure, but most of the people discovering Clappy there were indie hackers looking for a cool app. The real buyer and user was an engineering team inside a company.
The product also was not ready to show its value quickly enough. It needed the right company context, the right GitHub data, and a clear path to the first useful insight. Without that, the sign-up was just a sign-up.
I improved the onboarding after the launch. I added a guided flow that explained how the product worked and tried to bring users to the first “aha” moment faster. That made the product better, but the launch window had already passed. The attention from Product Hunt had ended, and I struggled to get more users to sign up, let alone convert into customers.
Eventually, I decided to stop pushing Clappy and focus on solving a different problem with Staybit.
What I learned
Clappy taught me something I should have learned earlier in the process: measuring developer performance is difficult in a way that is easy to underestimate.
Metrics are not impact
You cannot reduce engineering work to commits, lines of code, or merged pull requests. Those numbers are easy to collect, but they are not the same thing as impact. A small review can prevent a large bug. A quiet refactor can make the next month of work faster. A developer can spend days unblocking other people without producing a clean metric that looks impressive on a leaderboard.
I also underestimated how personal those metrics can feel. Software teams do not always respond well to being scored against each other. Some roles are naturally competitive, like sales. Engineering has a different culture. Comparison can motivate, but it can also distort behavior and create pressure around the wrong incentives.
A pivot can happen too early
Clappy also taught me that a pivot can happen too early.
I moved away from the rewards system before I had properly validated it with real users. I assumed it was probably a nice-to-have for companies, and that engineering analytics would be more attractive because tech companies care about optimizing development teams.
That assumption might have been right. The problem is that I did not prove it.
The first problem still mattered
In retrospect, I wish I had stayed with the original hypothesis longer. The rewards idea was not just an idea I came up with in a vacuum. It came from a moment I had actually lived: I needed help from teammates, the help was valuable, and the system around us did not make that help easy to prioritize.
That problem did not disappear just because I pivoted away from it.
People still need code reviewed. Teammates still do work that saves everyone else time. A lot of that work is still invisible, unrewarded, and easy to postpone.
Clappy did not become the company I hoped it would become, but it left me with a lesson I still think about: a sharper-sounding market is not always a better problem. Sometimes the first, messier problem is the one worth sitting with longer.