@MORA you are correct. Pricing tiers only apply to devices grouped as a Particle product.
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.
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.
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’…
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.
An explanation of our decision-making process around the new pricing model from Zach, CEO of Particle: Explaining Particle's new pricing
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! 
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! 