New Particle console


#50

I would also like to comment on the new pricing model. This is a shocking change to the business model for working with Particle. One of the major reasons we started working with Particle was the predictable cost structure, which is essential in creating a mass produced product. The other competitors charged monthly for their services so it was difficult for us to build the lifetime data costs into a product upfront. However, with Particle, this was different. The deal was a $2 fee for your cloud data transmissions. This was a fixed and manageable expense that worked for our cost estimations. Now, everything is different . . .

I remember back when the AWS IoT service was launched there was a thread here that discussed the cost of the AWS service. It was said that charging $5/million messages sent through the service was very expensive. If we look at the Rollout tier in comparison it costs $249/month for 10 million messages. Even if we apply the “expensive” AWS pricing scheme, that would equate to $50/month for the same level of messaging. So the question becomes whether the other console services are worth $199/month. Of course, the AWS IoT service is not the same as the Particle platform since it does not have the device management and firmware upgrade capability, but the price difference is vast.

I also find the concept of fixed device and messaging count tiers strange. If you are going to charge a monthly fee based on the number of devices or messages sent I would prefer to pay for my actual usage. Why do I need to pay for devices or messages in excess of what I actually use? I would guess that the tiered pricing scheme is designed to make thing easier to understand. If tiered pricing is required, then I think soft limits for overage would be better. For example if you have 1001 devices or messages > 10 million, paying an extra $0.249 per device or 10k messages would be manageable and predictable.

In planning our production budgets, stable pricing estimates are an absolute requirement. We cannot have a cloud cost that ranges from $0.249 per product per month to > $1 if we end up selling more than 1k units. This type of a volatile cost base makes it extremely difficult to include Particle in our products.

Beyond the details of the new pricing scheme, I find the overall issue of drastically changing the business model deeply disturbing. We have been working for over a year integrating Particle services into our various products with the understanding that it would be $2 for the cloud licensing fee. We also just executed a production contract with a client on Monday but now our pricing estimates are completely invalid. Changing from a one-time fixed cost to a monthly, ongoing fee is a big big deal for us. I understand and respect that Particle has their reasons for making these changes but this is a game changer for us.


#51

I wonder if this kind of double tier pricing model would work:
Baseline cost which would cover the cost of support and some features. So these would mirror the current levels like prototype, pilot, rollout and scale etc. User could choose one that fits. Ie if you need fast support and SLA you’d choose scale.

Per device cost which would also vary based on tiers. So something like:

  • basic level which covers just the device management and OTA updates,
  • IOT level which has above + connectivity
  • IOT+ level which has above + webhooks and other fancy stuff

So then your montly invoice would be based on the baseline costs + (per device cost * amount of devices on that level)

Then everything would be easy to calculate beforehand and you would be able to cater to different use cases…


#52

Let me understand… I can have a single account with 1000 devices, not grouped in a product, and I can use for free the cloud? ok, I wouldn’t have all the cool features released with the console, but I can publish some vars and make OTA update, one device at time? If this is it, for me will be ok, I don’t need more.
Thanks, Flavio


#53

Hi @jeiden,

Sorry, I did not explain rather well my concern: it was a technical one. When I create a product in the console, I can choose only Particle products. Does this means that console does not play well with compounds, or should I choose the Particle product compatible with the compound (e.g. Photon if I have Duos) ?

Claudio


#54

Hmm, I’m assuming that $2 fee was the lifetime cloud access? If so, then that hasn’t changed I think. Before this price, there was also a recurring cost for dashboard features.
What’s similar with the ‘before & now’ is that the dashboard offers optional features designed to make creating a product easier. Key to this is the fact that they are optional. If you don’t want to use the dashboard, all the power to you, though you’ll have to make some features yourself, should you have need for them.

@flavio.ferrandi I think those assumptions are correct. If you haven’t meddled with products before, then nothing should change. The dashboard offers additional features to what’s already there.
No promises, just what I think.


#55

@Moors7 how can you do it? The dashboard before and the console now are required if you want to sell products to the final customers. You need customer claiming connected to a two-legged server, OTA updates to all devices, SSE events per product. And you can’t use Cloud API endpoints for product without going into the new tiers, you can’t either add a device to a product, so you can’t develop your own console on top of them.
Building a business using the platform as a developer and some tricks to find the way not to pay is a bad idea i think.
I want to pay the console because i like all the tools of the platform, that’s why i need to find a platform that make my business model sustainable.


#56

I’ve never had the fortune to have to create a product before, so excuse my lack of knowledge on the subject.
You are right that you have to get users to sign up to a server, and you need a server to manage OTA and events. I personally don’t see a reason why the console is the only way to do so. And of those things could also be handled by a private server, though you’d have to make an effort to create/maintain it. The question then becomes if the development of that is worth it compared to the convenience the console would give you, given that everything would be contained in one platform.

The dashboard/console wasn’t there from the start of Particle, and people were still able to create products without it. I see no reason why that’s no longer possible now that it’s here. It might take (quite some?) more effort, but it’s still an option.

Again, just my personal thoughts on the matter.


#58

True, I made a basic firmware flasher using the API while the paywall was up, but didnt take it further than that, since they said prices was under review.

New pricing is just too steep for me when only using the OTA part, all my data are logged with direct connections.
At the moment, my flasher works, but only with online devices, so room for improvement.

I would gladly pay a reasonable fee to help keep particle in business, but several times the cost of my dedicated server to enable OTA is too steep.

But making an opensource alternative would nee clarification on the fee is only if you use the product feature, theres some disagreement with whats written and what customer service says in this thread.


#59

@duffo64 - currently, only creating products based on the Particle development kits are supported. In the future, we will likely support other compounds. If you want to take advantage of the product tools now, I would suggest using a Photon!


When Redbear Duo will gain product support?
#60

I see that there’s some confusion about what we’re charging for vs. what’s free, so I’d encourage everyone to take a read through the FAQ on our new pricing page (https://www.particle.io/pricing). If there are questions about the pricing structure that aren’t answered by the FAQ or aren’t clear, please let us know so we can improve the FAQ and make all of this clearer!


#61

Thank you. Our product will be BLE based, so Photon isn’t an option.

Claudio


#62

"Particle provides free access to Particle Cloud for prototyping."
Seems to imply that when the “thing” is no longer in prototype, you have to pay.

"I’M A DEVELOPER / MAKER, AND I AM NOT CREATING A PRODUCT; WHAT DOES THIS MEAN FOR ME? ​"
Seems to imply that only makers and developers are entitled to the free tier.

"WHAT’S A PRODUCT?"
Defines a product as made with the console, but does not contradict the first point.

So just to be absolutely clear, anyone can have say a thousand photons registered to their account, and not group them as a product, but instead use a 3rd party tool to manage the OTA, and particle would be fine with this ?


#63

@MORA you are correct. Pricing tiers only apply to devices grouped as a Particle product.


#65

It might be worth thinking about a reasonably priced tier that really was nothing but device management.

I’m in the same boat as many others… I have no need for events, support or an uptime guarantee (the little bit I played with the cloud functions, they weren’t that stable anyway… would see a ton of Nginx Internal Error 500 messages). The attraction to Particle was the device management. Is it worth more per year (at the 1001 unit level) than the cost of a Photon to do an OTA update? No, not really…

It’s simple enough to build our own OTA update system. But purely as a business thing, it might be something to consider… a device management tier that allows OTA firmware updates, but isn’t sending millions of events.

If the Pilot tier gave the same functionality as the free tier, but for unlimited devices (no support, no uptime guarantee, 250K events, 5 team members) it essentially becomes a device management tier for doing OTA updates. And you would get a whole bunch of subscribers to that tier. Instead, you are going to end up with people wanting nothing but OTA updates doing their own OTA updates and not subscribing to any tier.


#66

Could there be a chance that OTA for free is blocked by particle.io at some point in the future?
It does go through their Cloud, doesn’t it?

A reasonable per device dashboard for OTA could be livable for me too.


#67

Here’s my 2c on pricing:

I understand the need of provider to cover the ongoing infrastructure expenses but the only option for small consumer products is to have that cost known, limited and baked into the purchase price. That was possible with $2 of the module cost paying for the lifetime of the cloud service. Particle made it clear that this is still an option for modules not grouped into products. I just hope it’s not going to be eventually deemed a loophole and gradually tightened to the point when it is no longer usable for anything other than DIY projects and small scale prototyping.

Now for some products the monthly bill is wholly justified and expected by consumers. I’ll be happy to see Particle prosper as the company and be able to hire top talent. I just don’t quite understand the proposed scheme with drastic cost increases at the boundaries of the tiers. This puts creators in the position where half of the time they will dread the growth of their fleet. In my opinion it would make more sense to charge per device fee based on the actual number of units online with progressive tiers (kind of like income taxes but in reverse). For example based on average per-unit cost in proposed tiers:

  • 1 - 25 are free
  • 26 - 250 are $0.71/mo each
  • 251 - 1,000 are $0.56/mo each
  • 1,001 - 10,000 are $0.40/mo each

The change in price only affects the units spilling over into the next tier so first 25 are always free even if total number of units is higher. This way growing from 1,000 units to 1,001 unit is going to be a gradual increase of $0.4/mo instead of $1720/mo jump. This scheme may not look quite as straightforward on the chart, but your customers are a smart bunch and they’ll get it.

Just sayin’…


#68

The pricing changes don’t effect me yet but one thing that seems to be missed is the cost associated the changes in the number of allowed events and the amount of support/uptime provided by the different tiers.

If the cost was broken down for access per device with a decrease in cost per unit that goes down with quantity.
+
Cost per unit for the tiers for the number of events allowed
+
Cost per unit for the support per tier it may make more sense.

If I get a product that I feel is viable I would like the option of getting and paying for additional support and events even if I only had 50 to 100 units.


#69

An explanation of our decision-making process around the new pricing model from Zach, CEO of Particle: Explaining Particle's new pricing


#70

This is the inherent issue with getting in bed with a partner, especially a monogamous partner, and the thing that’s kept me out of single-sourced cloud solutions in my past business ventures.

For me - I’m glad we dragged our feet a bit. Divorce is always painful, but at least we’re not fighting over the kids!

@zach : #1 and #4 are the same. #2 and #4 are the same. #3 and #4 are the same. “Cost of doing business” is part-and-parcel to your COGS. You build a model, you build your margins into your model, your net margin is what you’ve modeled after your cost of goods and your “cost of doing business”. It’s a rare model (and I’d love to find one!) that can absorb suddenly finding itself in the hundreds-of-percent increase in its cost of goods!

If your market will bear “Option 2” - great! Generally that’s the most attractive market for funding anyway, the market that has an ongoing recurring revenue stream. It has its own risks, and they’re real, but it’s there. That’s what makes the cell phone industry tick!

So given all of that, we can either reprice the product to absorb the hit, if your market will bear it (mine certainly wouldn’t), go to a pay-to-play if you market will bear it, or we absorb the upfront hit to knock it off and control the means of service (probably the most viable in my instance). The partner can probably still screw you in this case - I’d have to negotiate that out for sure.

Great. But this demonstrates why you absolutely CAN’T get in bed with someone providing these services and have a real business. You made these changes today, and we have a few thousand hours of engineering in place - it’s recoverable. You make your next set of changes in six months, and suddenly we’ve shipped thousands of units that have been bought-and-paid-for under an entirely different model and bang! We’re toast. Customer’s toast. Nothing but death-and-destruction as far as the eye can see.

We can’t trust a single-source third party with the under-pinnings of our business. If you HAVE to do it to bootstrap a project… just know the risks. Build for them. But the instant you can, second-source the service provider. I bet you don’t have a single piece of fiber from a single provider running into a single DC either. (ok - I know you don’t since it’s trivially obvious where it’s all hosted anyway…) Even single-sourcing to AWS is fraught with risk, but at least it’s manageable risk, as long as you control the under-pinnings.

Personally - I’m in a position where I need to think quickly and see if this is at all salvageable or bail before it’s too late.

I should probably be thanking you though! I went from “paranoid” to “visionary” in ten seconds flat! :wink:


Photon - pointing to own servers
#71

Gave it some consideration on the drive home from the office: I think the obvious path is to use Particle as an accelerator to get a 1.0 to test market/acceptance market, just with hardcore obsolescence baked in. This puts an absolute cost (under today’s pricing, no telling what tomorrow brings…) on the devices and limits risk, and then simultaneously create a parallel development path to 2.0 that completes somewhere south of obsoleting 1.0 and removes the dependency on uncontrollable single-source models.

It creates a number of irritated 1.0 clients that are going to need placating, but that’s absolute cost I can plan for, so the risk is acceptable.

I’m good enough at painting myself into corners, it’s the one place I don’t require assistance! :smile: