Explaining Particle's new pricing

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

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

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

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

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.

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.

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?

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

But if you change the firmware, it won't receive anything anymore since it wouldn't know what to listen to(?)

A subscription works like a prefix filter. If you subscribe to "foo",
you will receive any event whose name begins with "foo", including
"foo", "fool", "foobar", and "food/indian/sweet-curry-beans".

So its not that hard to find out what data is being received, but finding out what is send is granted a lot harder.

How is this different from if it were a product, seems to me that USB uploading would still be possible? Honest question, I don’t know.

There is a slight safety check in that firmware for products must have the product ID builtin.
Although there is no check if the developer is the one that owns the ID, but the customer would need to find this somewhere, I dont think its treated as a secret though, so its likely possible to find…

I think the device will be isolated if the firmware is not the correct product, not sure though.
If a unknown device loads your product firmware, its isolated untill you allow it inside on the console.

So not sure theres much difference actually :blush:

Never forget that physical access will always be total access, no matter what route you take. This is why Particle recommends that you disable access to Serial and JTAG pins (breakaway post manufacturing). In any system be it Console or DIY all input should be verified and malformed/erroneous inputs should be rejected completely. Let’s say you use webhooks and have an instance of Redis inserting published data, can you be sure that malformed data wouldn’t cause an issue, are you prepared to watch all CVS traffic related to the full stack and it goes on and on. This isn’t an easy thing to do and in my mind part of the value is that I have Particle engineers working on my behalf and helping (not completely) identify potential attack vectors and mitigating them. Particle has handled so much of the low level stuff that is absolutely needed but not directly part of the “things” built on their system. Always think through any potential attack vector then mitigate, log, continually review and improve.

No device in the hands of a skilled and determined adversary is totally safe so do what you can to deter (make it harder) but focus the majority of your efforts on the side of the equation you are in control of and they can’t get to (the cloud side), Particle’s offering is what the industry calls Opioniated which is absolutely the direction most things are headed. Take advantage of their engineering, experience and skill or suffer the potential perils of bricking all your customers (hello to Wink again), a major outage, reputation loss or worst of all a very public and consumer confidence destroying breach that is likely to destroy your business/product.

3 Likes

Hi Luke, in my earlier post I laid out no need for particle services aside from firmware updates. Being able to send my Webhooks directly to AWS is all I need.

Your points re build vs rent are accurate if you believe as an user that they’ve hit critical mass where building doesn’t make sense. Rolling my own automatic update took an afternoon to write, test and perfect.

4 Likes

Can we get an update on this? I still want to see if Particle is or plans to implement a feature that only charges for "active" devices within a given month. I would define active as pings the server even once. If a device is not active for 12 months but sits in a customers closet. Why am I paying continued device fees for that?

Let's say that I have 10,000 devices in the field of which, 5,000 customers decide not to use their product anymore. In perpetuity in order to support those never used customers anymore I would need to pay $1,450 a month.

2 Likes

Hey there @incorvia – wanted to provide some responses to your questions. Your OP was back in 2016 and some things have changed, so will address comments in both your linked post as well as your most recent one.

There are two models for transacting with Particle.
The first is our "self-service" model, where customers have transparent visibility into hardware and Device Cloud pricing on our pricing page. Discounts on hardware and Device Cloud are provided at pre-set volume discount tiers.

The second is our "enterprise" model, where customers make hardware and Device Cloud volume commitments in exchange for deeper discounts and additional platform features. These commitments help make our business more predictable (good for Particle) and provides more value to our customers for lower per-device costs (good for customers).

More detail on enterprise "commitments"

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.

To be clear – there are no Device Cloud commitments for our self-service model. Our enterprise commitments typically span 2-3 years (term length is negotiable), not 5-10 years, and do not apply to any individual device, but rather a minimum number of devices.

So, in either plan, if a particular device is no longer in use, you can un-claim that device from your account or pause the cellular data services associated with that device and it will no longer be counted as billable. If you're on a self-service plan, you'll no longer pay for it. If you're on an enterprise plan, you're still accountable to the device minimums that you've committed to, but won't be charged for the device if you've already covered your minimums.

Billing for "active" devices

I still want to see if Particle is or plans to implement a feature that only charges for “active” devices within a given month. I would define active as pings the server even once.

Thank you for your feedback. What I hear you saying is that it would be easier if Particle automatically removed even devices that are claimed and "active" from your bill if they aren't being used, versus requiring customers to un-claim or pause connectivity manually to remove them. I agree that this would make life easier for product creators, and will pass on your feedback to the team responsible for implementing our Device Cloud billing. I can share that we have plans to simplify the model for "active" and "inactive" devices on the platform to make billing more straightforward, I can't provide a timeline around this feature.

Let me know if you have any more follow-up questions! Hopefully my response was helpful to you.

4 Likes

Thank you Will for your very thoughtful and direct response. The end of your email is exactly what I was referencing and it is great to hear that Particle is not only receptive to the idea but is making plans to address some of these concerns directly. As you guessed, adjusting billing makes more sense in many ways than manually unclaiming or deregistering a device. If a user pulls a device out of the closet after 2 years of inactivity it would be good for it to ‘work’ but we cannot foresee this and would be unaware of whether it was in a landfill or actually going to turn back on again some day.

As for your Enterprise points, this is something I’m aware of but will reach out in a PM to more directly ask about these plans.

Thank you again!

2 Likes

Has there been any update on the idea of active vs inactive pricing?

2 Likes

If anyone is familiar with the minimum commitment needed to get extended Carrier per country support for Gen3 cellular, please send me a direct message about what the commitment and pricing is. Thanks.

From decades of experience, multiple carriers per country is necessary for all cellular products, at least here in Europe.

1 Like

I was never able to get this pricing but just want to voice the wish for the future that multiple carriers per country was available from the start instead of after a “contact sales” number of units and pricing.