Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hey Jared and Trevor,

BugReplay (http://www.bugreplay.com) is a bug reporting tool in the form of a browser extension that captures a screencast of the user’s actions synced with network traffic, javascript errors and other browser data.

What's the best way to grow your early user base? Ideally we'd like people who are going to use BugReplay at their jobs and open source endeavors, but we want to keep it relatively small until we feel like it's ready for the widest possible audience.



This kind of tool has the classic agent problem. There are two kinds of users: people filing bug reports and people receiving bug reports. The people receiving bug reports get the benefits, but the people filing the bug reports decide which tool to use and have to install something to use yours.

My guess is that the developers will have to encourage or require bug reporters to use it. Their site will have to say “Here’s how to report a bug: Step 1: install BugReplay. Step 2: …” So find out whether they’re willing to do that, and how to make it as painless as possible.

It’s reasonable to want to keep the initial user base small, but usually that happens by default. The important thing is to keep the initial user base smart, and on a path to the eventual large user base. Don’t make the mistake of pursuing users that aren't your eventual target market in order to keep things small at first.

PS, if you're appealing to web devs, you need first-rate website design. It currently has formatting problems: https://www.dropbox.com/s/4hethogee0d7zgt/Screenshot%202016-...


The kind of user you’re describing isn’t our focus right now and I agree it would be hard to get a user of a website such as Facebook or Twitter to go through all those steps.

We think potential users can be broken down into different groups. The first group would be people within the same organization (testers, design, other devs, marketing, support, etc). In that scenario, the company would subscribe to our service and everyone would use it internally, especially once they see how much easier it is.

The second group would be people who have a vested interest in a website working properly. For example, my friend has a clothing company and they sell online through Shopify. If she encountered a bug on Shopify and they told her this is the tool she should use, she would do that. I do agree however that for a casual user on a website, it would take a lot to get them to use our service. That’s why we are not focusing on that.

Thanks for pointing out that formatting problem. We use Instapage to make the marketing site (we’re bootstrapping) and it seems fine when I logged in- I’ll forward the screenshot to them to take a look.

As for the small user base, even if they’re really into it, it’s the kind of tool that someone uses only when they need it. So even if we have a committed user base, unless they have tons of buggy sites, we can’t expect to see tons of activity. That’s why we aren’t sure how to handle it.

Thanks for giving me an opportunity to clarify and for the feedback! It’s really appreciated.


It'd be worth trying to sell to website testing/QA as a service companies, like https://www.usertesting.com/. If they saw value in offering your better bug reports to their customers, it'd get you a lot of business fast.


We were contacted by a company like that with thousands of users and they expressed some interest in using or licensing our product. Initially I thought that would be too big of an undertaking for beta testing since we aren’t certain of our costs but now I’m rethinking it. I'm also not sure how we'd transition from free beta testing to a paid service in a situation like that. Thanks for the idea though, I’m definitely going to explore that further.


What is your target market? Developers & QA, right? Not end customers?

The copy on your site is technical + imho too long. I'm a tech lead so get it, but if I want to buy your product I'm going to have to convince a PHB that it's worth spending money on. They're going to run for the hills when the headline is "records screen usage javascript errors and network".

As a potential customer: if this could be self-hosted and runs on Windows then it's a very interesting product.

If I can deploy this, live, as part of my site, then it's more valuable for me. Again, it must be self-hosted (data protection!) - which is the reason I don't use the other tools. But giving my users the ability to record the process leading up to an error they see is fantastic.


Thanks for the feedback and for checking out our site.

We are not targeting end customers directly but hope that at some point it would be a service that a B2C would offer to their customers.

It’s really hard to describe our product without being technical but we will revisit it. Any ideas?

We are exploring how to run this self hosted, it is entirely possible but we haven't gotten there yet. As for data protection it's an issue we take very seriously. All network data is stored encrypted, and all reports are private unless explicitly set to public. We are also working on ways to obfuscate the traffic before it’s ever uploaded.


Problem: bug reports are crap.

"why rely on obscure text reports when bugreply can show you the problem: live!"

"bug reports for the youtube generation"

"take the pain out of bug reports - bugreply lets your QA|consultants|users record the steps leading up to their problems"

You really need to brainstorm this; first get the value prop clear for various target demographics, then iterate iterate iterate until you can get a few nice one-liners.

Then test them on someone who is clean (a potential customer).

Btw if you want any further feedback feel free to ping me on twitter; username is the same as my hn username. I'll DM you my gmail/hangouts address/linkedin.


I will definitely follow up with you- thank you for the ideas. I think in an effort to show how different we are from other screenshot and screencast tools we may have gotten too technical in our wording- but we definitely don't want to scare people off! Thanks again!


Have you looked a company like rainforest qa or any of the other crowdsourced testing companies? Your tool seems like an excellent fit to have their users use so bug submissions are better for developers.

That's the "easier" play, but with your tool/tech you might be in a good position to create your own crowdsourced QA company. I'm not sure how the economics look for the other crowdsourced qa companies, but I know from looking at them that there prices seem to be too high. Basically I could hire a full time QA person with their prices...so why would I use them.

If you could figure out a way to undercut those companies while providing on-demand crowdsourced qa using your tool...I bet you'd have a pretty nice business.


Thank you for the feedback. We have looked at Rainforest QA and could definitely see how our tool would work for them. I only know of a few crowdsourced testing companies but we should focus on researching that more. Your other idea of becoming a crowdsourced testing company is definitely interesting and one we never thought of. Our immediate goal is to get people using it regularly and we’ll take it from there. Thanks again!


Maybe you should target corporate software engineering and QA managers who lead the teams building their own commercial web applications. It should be fairly straightforward to target those people through conferences and online forums. Corporate QA groups waste a lot of time manually filling out bug report forms, and those often end up missing key data which prevents developers from reproducing the bug thus wasting even more time. If you can provide a tool that will accelerate QA cycle times and cut labor expenses through automation then corporate customers will be willing to pay for it, and go through the hassle of installing it on their testing computers.


Thanks for the feedback. We plan on targeting QA managers but haven’t figured out the best approach. I won’t pretend to be a QA expert but I think our service would be very valuable for exploratory/ad-hoc testing. We hope our service will save time for QA professionals when filling out bug reports so that they can spend that time providing value in other ways.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: