There have been a number of questions that have come up in the forums about our new pricing we announced earlier this week (www.particle.io/pricing). In particular, the common thread is: why did we choose to charge for our platform in a certain way? In the spirit of transparency, I wanted to step in and explain, at a high level, why our pricing structure looks the way it does.
First off, let me start with one thing: Particle Cloud remains free for makers/developers/prototyping, regardless of how many devices you have connected. The paid tiers are for ‘products’, or fleets of devices that are managed as a unit. That includes things like OTA firmware releases to a fleet of devices and setting up a webhook or other web integration for a fleet of devices.
The reason we chose ‘products’ as the defining characteristic of our paid platform is because having a ‘fleet’ that you want to manage is what most distinguishes professional users from personal users. This is not unlike Github’s model; Github is free for open source projects and paid for closed source projects because professional users like to close off their code and personal users like to open it up. We will sometimes have personal users who will pay for ‘products’ because those features are useful to them, and we will sometimes have professional users who won’t pay for ‘products’ because they don’t care about the features we provide when you build a product. And that’s totally okay.
When we first launched the Dashboard in 2015, we didn’t know much about how people would use it and how our customers were going to scale. But now we have hundreds of customers who have scaled with Particle, and we’ve learned that they fall into four basic categories:
- Small, low-value fleets of devices. For example, someone who creates 200-300 devices with a retail price of $100 or $150 each. These are typically entrepreneurial ventures with a small team behind them, or perhaps a side project for a professional engineer. We would expect these types of customers to be on our ‘rollout’ tier, paying about $250/mo.
- Small, high-value fleets of devices. This is most common for industrial customers, who might have 200-300 devices with a retail price of $1,000 or more. Examples might be irrigation systems or industrial automation products. These products are often mission-critical, so these customers care about having a guaranteed SLA and white glove support, so we’d expect them to be on the ‘scale’ or ‘enterprise’ tiers, even though they don’t have that many devices.
- Large, low-value fleets of devices. This is most common for consumer devices, where a customer might have 50,000 devices that cost $60-$80 retail. These customers would be on the ‘scale’ or ‘enterprise’ plans.
- Large, high-value fleets of devices. These are less common (because high cost products tend to be distributed in lower volumes), but customers with large fleets of devices that cost thousands or tens of thousands of dollars each care a lot about those devices, so we’d expect them to be on the ‘enterprise’ tier, and requesting higher SLAs, better support, and private deployments of our cloud platform.
One of the most common concerns that I’ve seen with our new pricing is the question of what happens when you set up your 1,001st device. That’s an expensive device! It pushes you over the edge from the $250/mo ‘rollout’ tier to the $1,800 ‘scale’ tier. Well, what we’ve learned from our customers is that this almost never happens. The reality of manufacturing is that you start small with a prototype, then move to a pilot, and then you scale up. Customers who scale into thousands of devices typically jump from a pilot of 50 or 100 devices straight to 5,000 devices. We have very few customers who have more than 1,000 devices and less than 5,000 devices, and those customers tend to very quickly grow out of that stage. No one stays there for very long.
Another common question is ‘why not charge per device?’ The reason is because there area number of axes upon which our customers may scale; it’s not all about the number of devices you have deployed. If we had a usage-based model, it would be a pretty complex model, and it would get much more complex over time as we add new features. For instance, data storage is on our product roadmap, and while we intend for everyone to be able to store data in the Particle Cloud, paying customers will be able to store more data for longer and will get other advanced features associated with that data. Rather than adding a new feature that we have to charge for separately, we can just add data storage to the existing pricing tiers, which keeps our pricing plan simple.
I truly appreciate the feedback you’ve shared here in the forums over the last few days; we are absolutely listening and deeply considering all of the feedback that we’ve received. I also know that many of you who have expressed concerns with our new pricing are not concerned because of the impact to your own business, but rather because you want to see Particle be successful and you feel like we’ve missed something. I hope you will continue to provide feedback, and at the same time I hope that you understand that we did already consider and debate many of the issues you’ve raised.
Finally, I understand that there are some who feel slighted by the pricing changes because you were intending to follow a certain path with Particle and that’s no longer economically feasible because of our price changes. Our head of Customer Success, Jon Logan, is eager to hear from you if that’s the case, because we want to do right by you. Shoot an email to email@example.com. (Quick note: Jon is at Defcon right now so he’s totally offline today and this weekend so that he doesn’t get pwned; expect a response early next week)
Thanks and please let me know if there are more questions or issues that we can help resolve!