We’ve achieved an important milestone last month — Bugsee joined the One Comma Club, as more than 1,000 companies had signed up for Bugsee since our start just this April. Coincidentally, we believe we’re ready to graduate from a free product to a paid service.

When we’ve started, our goal was always to make the service as frictionless as possible. It manifests itself in the vast feature set Bugsee delivers to our customers by adding just one line of code. You don’t need to think ahead of time what info you might need when you debug the next bug or crash.

Therefore, we didn’t want the lingering thought of payment to be prohibitive for developers to try a new and yet untested product. So we’ve decided to roll out a fully functional service with no strings or dollars attached.

Oh boy, it was a right decision. We’ve learned so much in the process, we could’ve never imagined. So before I go any further, I wish, once again, to thank our existing customers. Thank you for your trust, patience and support during our early months. As a small token of our appreciation, you all received a special free tier.

Pricing Exploration

When we started discussing our pricing strategy, we’ve underestimated how difficult it’ll be to come up with the right plan. It probably took us good 6–8 weeks of deliberation to converge on the current model.

The first business model we’ve eliminated from the get-go was to have a free product and sell the collected user behaviour information through other channels. We didn’t believe it’s the right approach for us, as we care about our customers’ data and privacy. We do not sell our customers’ data to 3rd parties. Period.

Our number one goal was to make our pricing structure to be super simple and easy to understand. We did not want to have feature matrices that are often too complex to comb through, figure out which features you actually need and whether they are worth the extra price tag.

We also wanted to ensure we have a fully functional free tier if you’re just interested in trying Bugsee out, as well as if you’re at the very beginning of your product development and you’re not ready to pay for any tools yet.

We used Atlassian’s pricing page for Jira as our guiding North Star and tried to model after it.

Then the question came — what do we tie our pricing to? In case of Jira, it is the number of team members that have access to their dashboard. We didn’t feel it would be correct for us to do the same.

There’re two main reasons for that:

• Size of the organization does not always properly reflect its stage in product development. There are many small businesses/startups that have a dozen-sized teams with no product yet, or their product simply lacks a meaningful traction yet. On the other end of the spectrum— WhatsApp had only 55 employees supporting hundreds of millions of users when FB acquired them for $19B.
• Charging per team-member also meant that adding a new teammate to Bugsee would be potentially met with hesitation — is that user worth the extra $x/month? We didn’t want that. We wanted the entire organization to have access to Bugsee, similar to Heap Analytics.

OK, so if we are not charging per-team-member, what do we do then? Another proposal we’ve contemplated was to charge per app or per project. The problem with it is that many developers like to try a small projects here and there, e.g. a test app or have a separate staging build of the app. Charging per project would prohibit the exploration of this sort.

Another option was to charge per a reported bug. Obviously, that was immediately turned down, as we didn’t want anyone to think twice before reporting a bug. Is this issue worth an extra $0.00x? Plus, it wouldn’t work for anyone trying to start something in their garage. Too cost prohibitive to report many bugs one usually has in the early days of a project.

So the only factor that we were left with was charging per number of devices Bugsee is deployed on. The problem was that even in a moderately successful app, its number of users usually trumps the number of devices the app is being tested on in-house. So we had to introduce two different kinds of devices we are tying our pricing to:

• Test Devices — the devices you run your dev and test builds. If you test on your phone and your iPad — it’s free. Large test deployment for your app (more than 10) are paid.
• Live Devices — your active users of the app. And again, if you just released your app, it’s free. We’ll charge you only when your grows to above 10K MAU.

It might look obvious now, but isn’t it always the case? You go through number of different options until you land on something that actually seems like a perfect solution, that addressed all our needs:

• Simple and easy to understand pricing model. No matrices!
• If you’re just starting — you get a full functional Bugsee for free, unrestricted by time — i.e. no trial period.
• When your business grows — we grow with you.
• Everything else in the system is unlimited — number of apps, bugs and teammates. So go ahead, create a test app, add your boss to the team — everything is included.

Now we wait to learn more

So that’s it. This is our quick summary of our journey exploring the right business model for Bugsee. Similar to anything in a startup, our business model is a continuous refinement process. Only our customers have the answer to whether we got it right or not. We’re looking forward to your feedback. Give it a try and let us know what you think @bugseehq.