<- Back to Blog

15 Months, 20k Visitors, and 0 Product-Market Fit

A 15-month retrospective on building a remote pair programming tool, technical and growth hurdles, future plans and unknowns

iason-p
Iason P. ·
15 Months, 20k Visitors, and 0 Product-Market Fit

Contents#

Intro#

For the last 15 months we've been trying to make the best OSS app for remote pair programming, reached the 1st place of HN, but we haven't found product-market fit and we believe it's a product issue. In this post I will share what isn't working and our plan to create the best screen-sharing app for devs.

Background#

In September 2024, Costa and I started building Hopp, an OSS remote pair programming app (you can read about our decision here).

TL;DR: We want to make an OSS alternative with the same quality as the proprietary tools in the market.

Both of us do this alongside our day jobs:

  • Costa is an engineer at Grafana.
  • I am a GPU Software Engineer at Arm, working on the Mali driver.

Since we started, we've spent almost all our nights and weekends working on this, and Costa has become the person I speak with the most during the week.

Timeline
Our timeline

Pair programming in the age of AI#

First, we know that building a pair programming app in the age of AI might be the wrong bet.

Programming is changing quickly, and many workflows we have now might be outdated by the end of the year. We are heading to a future where people will be prompting instead of manually typing each line of code.

I feel that entirely new categories of developer tools are being created now. People are letting agents work autonomously for days, and have sandboxes for testing them, like what Ramp did. Personally, I am not yet convinced this will replace human problem-solving, but I cannot rule it out with certainty.

In a world where agents do most of the work, the need to spend hours solving problems with a teammate may diminish.

If this is indeed the future, the mental model of programming will change. Being able to take full control and type on your teammate's machine might not be used at all.

If one programmer can do the job for more, then it might make more sense to work autonomously on different features/products instead of collaborating with other humans on the same.

Oversaturated market#

Something else that troubles us, is whether the market is oversaturated for yet another screen sharing app, made for developers. Before the pandemic the conventional tools weren't optimized for high quality screen sharing. Some still aren't, but others have improved. With zoom you can even have remote control nowadays, though in my opinion the UX can be improved a lot.

Furthermore since 2020, many purpose-built tools for developers have emerged, with varying degrees of success, but they exist. Developers nowadays have many options that work well enough, and pair programming is not popular among them. Therefore, we are afraid we have chosen the wrong market.

I understand why many devs don't like pair programming. To me, pairing is broader than the traditional definition. I consider it to be any time you jump into a call with a colleague to collaborate on fixing an issue or doing a review.

Decent traffic but no conversions#

Hopp hasn't had the growth we were hoping it would have. This is our traffic from the last 6 months.

Hopp's traffic
Hopp's traffic

The spikes are from posts that went semi-viral, including:

  • In October, we published our commentary on how to conduct programming interviews, which briefly reached the first place on HN.
  • This month, our rant on webkit was number one for the week on the javascript subreddit.

In the other months, the traffic was from blog posts we shared on Reddit and organic traffic from SEO. Also, in September, we did our open source launch.

Our results are the following:

Hopp's funnel
Hopp's funnel

The pattern is predictable. For example, in the last 30 days we've got:

  • 5k unique visitors.
  • 43 unique teams.
  • 37 with one user.
  • 6 made a call for the first time.

Low Traffic#

One of the debates we have with Costa is whether our traffic is low. His thinking is that with a small and inconsistent top-of-the-funnel the statistics are unreliable. I don't believe this and think that almost 20k unique visitors is a good sample to get insights into our funnel.

Funnel issues#

Based on the rules of thumb from The SaaS Playbook, we should have a visitor to trial conversion of 5-10% (as we don't require a credit card), which means we should have 900-1800 teams created. But our conversion is closer to 1%. A note there says

Traffic to your blog, which often contains top-of-funnel content, will convert at much lower rates than below.

So let's say that 1% is healthy.

It's fine
It's fine

Clearly, our biggest issue is that 70% of the signed-up users never invite anyone. We've tried to improve this, by changing our sign-up workflow and suggesting inviting someone straight after sign-up, but it didn't result in more invites. We also send a few automated emails to remind people to invite someone, but they don't seem to work. In particular, we send:

  • One after one week.
  • One after 3 weeks.
  • One a few days before the trial expires.

Product issues#

The second issue is that users who have at least one call don't convert. Currently, our conversion rate for users who had at least one call is 6%. I believe this is lower than it should be, and it clearly indicates that the product needs further refinement.

Known issues#

We are aware of a few issues and are actively working on them:

  • Drawing support: We lost a few potential customers because we were missing drawing support (now we have added beta support).
  • Audio quality: Our current audio performance is inconsistent due to WebKit limitations. To resolve this, we are migrating audio capturing and playback to our Rust backend.
  • General stability: There were minor bugs that were affecting the user experience.

User expectations#

A large portion of the people trying our product are seeking a more affordable alternative to the established competitors. While our lower price is part of our value proposition, there is still a quality gap. Users often expect the same level of polish as our competitors, which we don't have yet.

Our goal is to reach their quality, but it will take a few more months.

Talking to devs#

Both Costa and I are engineers, so we chose to sell to developers because it's an audience we understand and care about. The problem is that talking to developers is hard.

Getting Feedback#

One advantage of working with developers is that they provide amazing bug reports, when something doesn't work, they provide clear instructions and are willing to help with debugging. However, the hard part is to get feedback in the first place.

We try to contact everyone who had a Hopp session. To keep it personal, we handwrite each message. Despite this, a small percentage replies. For example, from the last 6 teams who had a call, only one responded with feedback.

Often, we don't even get a reply to the simple question.

No
No

To improve this, we've added a feedback window after a call ends. This has helped slightly, and now we know that almost every user experiences audio issues.

Marketing to devs#

Marketing to developers feels tough. We've managed to generate traffic from a few blog posts, but these are targeting a broad developer audience and not our niche. So far we've tried:

  • Posting on Reddit/HN: This has driven the most traffic, but the audience is not sufficiently targeted.
  • Cold outreach: We've tried emailing folks who work at remote companies and do pair programming. Out of 200 emails, we got 2 trials. In my opinion, the ROI is poor. It takes me at least 15 minutes to find each lead. Furthermore, I don't want to automate this method, as I find spamming people to be ethically questionable. I hate receiving these myself, so I don't want to do the same to others.
  • Newsletter sponsorships: We sponsored two newsletters this month, and now we are waiting for the results.
  • Influencer affiliation: We contacted a few influencers for partnerships but failed to make a deal. I think it's too early for this strategy.

Currently, blog posts are the only channel bringing traffic, though this traffic does not always translate into sign-ups.

Future plans#

We know the experience with Hopp is good but not great and we want to change this. We want our users to feel they are using a tool that truly enhances their productivity and makes their calls more enjoyable.

Product#

Roadmap
Roadmap

We want to be proud of what we've built. Our goal is to create the best screen-sharing app specifically for developers. We envision a product that:

  • Has crystal clear and low latency screen sharing.
  • Has crystal clear audio.
  • Is intuitive to use, with key bindings.
  • Is cross-platform.

We are far from there now, but we have a plan.

  1. Make windows support alpha, so we can focus on macOS for now.
  2. Move everything WebRTC related from WebKit to our Rust backend (currently in progress).
    • Migrate audio.
    • Migrate the screen sharing window view.
    • Migrate camera support.
  3. Add more integrations, currently we have only slack integration, teams, raycast and more are coming.
  4. Implement dynamic codec selection and adaptive streaming resolution.
  5. Add key bindings.
  6. Re introduce windows.
  7. Support linux.

This process will take time, but we hope to reach alpha Linux support by the summer of this year.

Marketing#

In the meantime, we will continue marketing Hopp. We have decided to focus solely on the strategies that we enjoy, writing blog posts for developers. Our content will focus on:

  • Lessons we have learned during development.
  • The technical decisions we make.
  • Rants about the tools and limitations that make our lives harder.

Summary#

Hopp isn't where we want it to be, and we're not hiding that. I don't know if we'll ever find product-market fit, but we're going to build the best version of this product that we can.

If you're going through similar struggles or have insights to share, feel free to reach out at X/twitter or email me directly at iason at gethopp dot app.

If you liked what we are doing, consider giving us a star on GitHub and signing up to try Hopp for your next call.

product-market-fit
remote-pair-programming
OSS
GET STARTED

Pair program like you're in the same room

Built for developers who refuse to compromise. Open-source, affordable, and fast enough to keep you in flow.