Explaining Particle's new pricing

General
1

Hi all,

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 jon@particle.io. (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!

8 Likes
2

Also, one more thought - it seems that some of our communications on our pricing page are not super clear, as some of the questions that have come up should be better explained. Just a heads up that next week we will work on improving how our pricing is communicated so that it’s a bit clearer what we are and aren’t charging for.

4 Likes
3

Does this mean that the 'scale' plan supports more than 10K devices?

I was under the impression it was "up to" 10K devices, but I must be mistaken if a customer with 50,000 devices can be on the 'scale' plan?

For a product in your example with a retail cost of $60... if the 'scale' plan is capped at 10,000 devices, $2.16 per year, per devices (in a best case scenario where you have a full 10,000 devices sold), kind of makes the platform not viable for consumer devices if they are low cost when you have what is essentially an indefinite annual "tax" on product. Even at "just" a 3% or retail value annual cost, it makes it not viable. While I understand there are infrastructure costs and all that, it simply makes Particle not a viable platform for normal consumer products (still great for a hobbyist or for very expensive products). It would be like a car manufacturer needing to pay 3% of the retail cost of every car they sell, every year, forever. I suspect that also wouldn't be a viable business model for car manufacturers.

I suspect what it's really about is deciding if Particle wants to be a hardware company or a SaaS provider. Looks like it's the latter under the new pricing plans.

3 Likes
4

I feel theres a plan missing for just doing OTA, anyone not willing/able to pay 1$/device/month will have to stay below 25units or not group them as products.
Not grouping them as products opens you up to a few interesting attack vectors, since a user can change the code by DFU and listen in on events/publish fake events, since you cant lock a firmware without using the product system.

So theres really no option for >25devices that cant maintain 1$/device/month.

Take the small low value example.

0,83$/device/month 10$/device/year
If we say the device lives for 5years, thats 2.5times the original hardware cost or 30% of the retail price.
Thats a huge chunk of the product price.

You can ofcause ungroup then after a few years when development stops, but you lose the safety of isolation/firmware version control, so a tough call to trade safety for running cost.

7 Likes
5

I too share the same concern of the “annual tax” so to speak. I spoke with a customer service representative and specifically asked what to do with devices that are thrown away after 2 years but we have to keep registered for 5 - 10 years paying fees for a machine that is technically no longer being used. The reason I have evaluated some services like PubNub for the message brokering aspect of an IoT platform is because they have a per message pricing structure which seems more amicable to me.

A couple ways I would have liked to have seen this structured:

  • Charging for volume of messages passed on the platform.
  • Charging per “active device” meaning if a client doesn’t send a message in a month it isn’t considered active.

Despite that, I want to explore an option where after, say, 12 months of no use, I un-claim a device. If I can transparently re-claim the device if the user ever turns it back on, I would find that to be a sufficient work around. If anyone knows if this is possible, I’d be glad to hear it.

6

@zach Can you give any timelines for integrating data storage as an easy to use Particle service like PubNub does?

I'm looking at Microsoft Azure for data storage now, but I'm interested in your plans if you can share any of that with us.

7

Sorry @RWB, no timelines yet for data storage.

8

@zach No problem.

When you do get to the point of adding it I request that it’s in a format that can be easily used with Microsoft Power BI dashboards if possible.

1 Like
9

Exactly @MORA & @digitalpoint (and others). The pricing plan defies simple retail math. You need to provide end retailers minimum of 45% margin. Let’s pick 250 as a round RRP. That means a 250 RRP Has to be a 140 their buy price. Then take out distribution (10%?) and 3PL. If you’re going via a vendor chain you may need to pay them 10% margin as well. That’s 3-4 steps of successive margin.
Let’s say best case scenario that me as a creator makes 40% margin on COGS, roughly in this case $40!

@zach and team (in my case Dan) have been open to chats along the way and I truly understand that they need to make some money. However these plans represent killing my gross profit (i.e. Before I get paid) with a thousand monthly cuts on a product with a 3-4 year life. Now I understand tacitly the team are saying if you don’t need the features then keep doing what you’re doing, however that also sells short what we could be doing together on shared cost Optimisation.
Let’s start with AWS - so Particle gets better and processing costs aren’t incurred on both the particle and your side. i.e. Those Webhooks aren’t free, but it’d be ‘easy’ to tie the particle gateway to your lambda functions. Alternatively open the kimono slightly so the AWS http gateway certs are included in the library and enable direct webhook publishing to our AWS API gateway, which proactively flips the ongoing cost issue to the creator. The answers to this will determine if the Particle business model is now margin on ‘platform processing’ costs or Stilton the original hardware. Creators should be able to choose which way they go, some folk will run with arms open to the Particle platform (& costs), while some others want to manage themselves.

Particle was a very bright hardware company designed from the ground to provide a pathway to IoT commercualisation and beyond. However these new plans only work for certain business models, i.e. Those with monthly annuity income, but not retail models where an initial purchase is made and you’re on the hook to provide reasonable product lifetime platform support.

I already have my own software management solution, realistically all I need is firmware support which again you expect after buying an IT product for the reasonable lifetime. Let me know how I can help make it easier for Particle to make money on the chips I buy and offload the ongoing costs to me to manage.

7 Likes
10

A commercial product, where firmware updates, feature enhancements and connectivity are expected services for cost, seems to be the avenue that works best for the pricing structure they just rolled out.

Retail math, as you point out, won’t work in an era of consumer expectation that the product’s lifetime cost is baked into the selling price.

Traditional Retail merchants hardly want their customers to have to buy batteries much less have to sign up for a paid service for a product that they sell. And if yes, well they’ll want a piece of that too!!!

Perhaps the Particle team could consider an all-inclusive royalty arrangement for retail channels that drive retail volumes.

And putting on my consumer hat, I’m very unlikely to buy a product that has a monthly/annual toll fee unless that product achieves a very high and consistent value (e.g. the mobile phone I’m typing on right now).

7 Likes
11

MTerrill and Bulldog’ nailed it.

Unfortunately this announcement completely knocked the wind out of us, and took some pretty serious reevaluation before we elected to abandon the Particle entirely. The hit was close to six months, but I’m glad it happened now!

I’d suggest the Particle team give some thought to offering a simple provisioning and updating service, with a per-device cost. (I thought that’s what we were buying, but suppose I thought wrongly).

2 Likes
12

Though I get that it’d be easier to manage them though a product in the console, there’s no reason why you can’t batch OTA your devices yourself.
The API is accessible, and there are libraries provided to interact with it. Using those, it shouldn’t be too hard to roll your own solution. Batch OTA shouldn’t be a reason to drop the platform if you ask me.
What else do you desperately need from Particle that makes you currently see it as non-viable?

1 Like
13

Sure, I agree. We can roll our own.

Why would I pay Particle their “cut” when I’m just going to need to start engineering my own solutions to end-run new pricing models? Their value becomes negligible rapidly.

1 Like
14

The dashboard is extra functionality provided on top of the things you get for free. It’s optional, and as such, you’re free to roll your own solution. That might take you more in time, effort, and maintenance to keep it stable than it’s worth for you to buy.
The things I personally might sell that have photons in them also don’t justify the cost of the dashboard. That said, with the tools provided, it’s easy enough to recreate the few parts that I require. It’s not as pretty, maybe not as flexible, and a tad harder to use perhaps, but it gets the job done, which is all I need.
But… I still get all the comforts that the cloud already offers me currently. Easy OTA flashing, a REST API, webhooks, events, IFTTT, etc. Those are things I wouldn’t want to build myself, which luckily, we get for free :smile:

2 Likes
15

While I understand the challenges for makers and maintaining profit over the term of a product I think those that are calling this a “tax” on their product are insinuating that Particle should pay the tax on their product. The services are a value add and not required in order for you to produce and sell a product based on any Particle product. If you believe that building and maintaining a system with feature parity to what Particle has produced then I say go for it but is that system really in your core business value? Is maintaining a staff and infrastructure less than using the Particle Products system? I highly doubt that but it is possible depending on what features you truly need for your product. What they have accomplished and built is truly a value added service that allows companies to focus time, money and staff on their actual product. The job of the maker is create the same for their customers, if you can’t then maybe consider the value of said product being connected.

In my day job I have the Buy vs Build conversation on a regular basis and in the instances of my customers (IT infrastructure) the TCO/ROI (Total Cost of Ownership and Return on Investment) are always better when the Buy route is taken while at the same time reducing risk of project failure.

The traditional consumer product retail model does not work for IoT. No matter what you do if you have a connected product that requires ongoing updates, support, analytics and control you WILL incur ongoing costs and it is no one’s responsibility but the product maker to maintain. You could go the way of Google Revolv/Wink and just shut it down leaving your customers with a product that is no longer useful but I don’t think anyone here is looking to pull such a maneuver.

The question to ask is not how do you eliminate ongoing costs but how do you create recurring revenue opportunities:

Can you sell the data to a data broker (varying views on this model but it certainly does exist)?

Can you sell a “Premium” on your product/app that adds value your customers would pay monthly for?
If yes…What conversion rate to Premium would you need in order to be profitable?

Can I create a V2 that is compelling enough that a customer would buy the next version and limit updates and the best new things to the V2 thus creating a compelling event?

Look at any connected product that requires the manufacture to maintain an infrastructure and I can promise you that they are using at least one of those approaches if not all OR they are on a monumental burn rate just trying to take market share…can’t rule that out in todays VC fueled market.

7 Likes
16

Using just OTA flashing of the devices means you cant trust the publish/subscribe system, because you cant isolate them like the console can.
Anyone can load new firmware onto a photon using USB cable and read all publishes made to the device or send fake/bad publishes to your server.

So if you abandon the console/dashboard, IMO you also needs to abandon the publish/subscribe system and roll your own communications system, or the very least encrypt the data being published on top of what particle already does.

You still get a "stable" product though, and all the network stack is worked out, so theres still some power in the particle device over a clean wifi solution.
I understand that particle needs a cashflow, but setting the bar so high, means all the small fish will go elsewhere, or feel isolated from the platform and not recommend it to others.

2 Likes
17

Not necessarily IMHO.
If you also provide a setup routine with your product that also claims the device to an isolated account, there would be no cross talk between devices.
If you don't want to upgrade a product after sale, I'd think there might also be a programmable fuse that prevents dfu-util updates without clearing the keys.

And as mentioned earlier in this thread: Particle is usually open for one2one talks if the current pricing would be a dealbreaker because of just a few devices over the tier margin.

18

Its not really inter-device I am concerned about, but device-server, if you cant verify the firmware, then you cant trust the data, that may or may not matter depending on the device.

If the device is sending room temperature, its pretty harmless, especially if its the owner thats hacking the device, but other devices where the customer may be rewarded based on information from the device would have to be secure.

If the dfu-fuse would not block OTA, thats a good option though.

19

But for that the customer would need to know what data gets sent to the server to "replicate" that "protocol", but how would he if he never sees the account/access token?

20

True theres some guessing involved, based on the data the device receives which you could get dumped by changing the firmware.