The new device management sounds very useful.
However it seems to hit small products pretty hard, is this an intentional limitation ?
Instead of charging a small fee per device, you pay a fixed 49$ per developer per month, so you need a fairly large and stable sales flow to support it, and if your device stops being for sale, you still need to pay a monthly fee as long as you want the firmware features.
While for a large company with 10,000+ units sold and employees 49$/month is a non issue.
Hey @MORA - sorry for the delayed response here, slipped through the cracks. Would love to hear more of your feedback, we designed this pricing model to be as affordable as possible, but I understand you don’t feel that’s the case. I’d love your thoughts on how you’d prefer to see the pricing structure; what would you like to see us do instead? Also happy to discuss this on today’s Particle Interactions
Thanks for the reply, I will check the interactions tomorrow, its 1am my time sadly.
I have 2 questions first.
Several persons have raised the point in other threads,a fixed price hits the small player the hardest, its pretty basic.
If you sell 10devices a month, each of them have to cover a 5$ fee to use device management.
If you sell 1000devices a month, each of them have to cover 0,05$ fee to use device management.
The 1000one would likely get a bit higher with more seats, but just to highlight the issue, unless you are sure you can sell at least 10units a month, every month, its pretty steep to use device management.
Ofcause if your devices are expensive enough, 5$ does not need to be a problem.
A similiar but different cloud solution charge around 0.2$ per device per month, so break even around 260devices with a minimum of 20devices.
I am not suggesting to do the same, just to have something to compare to.
The $49/mo covers all products, and if the developer stops paying, the product keeps working, the developer just doesn't have access to the fleet management tools any longer. None of the tools that we're charging for are necessary for the product to function, which I think is an important part of our pricing model.
Well, that's not entirely true, based on your analysis above. If you sell 10 devices every month, and each device costs $0.20/mo (using your example below), then the first month you're paying $2, then $4, then $6, etc. After two years you're paying $50/mo, and after four years you're paying $100/mo.
The point I'm making is that we chose not to make our pricing scale with devices because if you're selling a device at a fixed margin you will eventually consume that margin due to your monthly fees. So if you make $20 of profit for each device and it costs you $0.20/mo to run it, then after your customer uses the product for 8 years, your profit has been consumed.
Our pricing model is based on # of team members, which we think is more reflective of the value your team is generating from the platform. You may do very active development on your product for the first three years of its life, and have a bunch of team members working on it, which is when you'd be paying the most (because you're using the platform very actively and deriving value). After those three years are up, you may no longer be doing active development on that product, and you can unsubscribe from the management tools. The product will keep working. And that's very important, I think.
I think the point that you made is very valid, and it comes down to the ratio between # of devices and # of members of the team. If you have a large team working with a small number of devices, our current pricing structure isn't going to work well for you, whereas if you have a small team working with a larger number of devices, the pricing structure should be great. No matter what we do, it's likely that some people will be happy and others will be unhappy. I do appreciate the feedback and we'll definitely consider other models.
I understand both sides of this coin and while the $50 a month might be “high” in vacuum I’ll add my perspective (for what it may be worth). In this changing software world of transitioning to OpenSource/freemium services it is challenging to find business models that keep you viewed as part of the shift but also allow you to keep your doors open. Particle is not immune to this challenge but I see the value add in fleet management, it isn’t required so they are still Open and what would be the cost to you as a developer to create a system that offers similar features? They have real cost in the infra, support and development of this tool that is focused on fleets and a per seat model is the predominate model for software as a service. Clearly they are strong supporters of the maker movement and b2b alike but when developing a tool focused on b2b customers they have to draw a line. Smaller product lines end up in the gray area but as a business there are always the edge cases and outliers that you do your best to support but can’t tailor a model to them as by their very definition they are a minority of the target demographic. I would love to see a “hobbist” or “micro fleet” tier of pricing as much as anyone but can appreciate the challenge that presents. In that vain however could there be a “micro fleet” that is per device based at say $1.00 a device that is capped at 50 devices? This allows early entry to fleet management so it can be integrated early in the Dev cycle but then switches to the per seat pricing as scale starts to meet the target demo. Just a thought but either way…keep up the great work and keep developing top notch tool sets because that in my mind is the Particle differentiator.
Thanks @LukeUSCM, I think your micro fleet pricing model is a really interesting one, and definitely something for us to consider!
Thanks for the thoughtful consideration, much of which revolves on business models.
Our use of Particle in the foreseeable future is internally-focused tinkering that cannot make the current figure balance; you already imagine the lame behavior when we flash updates to 10-50 devices (like using a hand calculator instead of excel); we’d pay per flash or per device/month even in a slightly regressive structure to get some of those same benefits at our scale. However, our ability to demonstrate fleet management could make a product a future viability that reaches that threshold.
This is also going to shift naturally as the feature set becomes more robust and can be differentiated. We’re also so small that I can’t imagine how many seats are needed even in a large product shop, or how much bandwidth you might get for the same price to update 200,000 or 200 devices. I’ll keep my eye on this closely; its early days for a lot of cloud platform models, and we’re prepared for the ground to shift, but hopefully not derail our efforts to make great things with them.
Once we get queued firmwares, basic flashing of multiple units should be doable using the API.
Device management is more than that, but at 49$ its not for personal or maker business.
The price is decent for reasonably sized companies, for us small fish, we can work with the basic code access and make some API based work arounds for useability.
So in the interaction you mentioned that you would like feedback on what features people want from the fleet management system for free/cheaper.
IMO the most lacking feature of the current web ide, is that you cant tie a code to a device, and second that you cant tie multiple devices to the same code.
So when you make changes, even if its a change to a single code running on a single unit, you have to remember which unit that is, and if you forget or pick the wrong one, you flash bad code on another device with potential magic smoke results(due to external components).
I played with the API a bit today, and its an ok workaround, we can make simple scripts that call PUT /device with new firmware, but first you need to make sure the devices are on the correct system firmware, which there does not seem a easy way to do yet.
Hopefully in near future firmware calls to PUT firmware will also autoupdate the device, or we get a API call to start the auto updating.
You also mention that you hope to make it something that people are willing to pay for on a recurring basis, I think people are willing to do that on a personal/small business level, just that the entry price is a bit high for personal/small business use.
Personally I pay 5$/month for a project time keeping service, I could make do with a free one, but the cost is low enough for the value it provides.
I also pay 42$/month for my dedicated server which runs my small/miniature business, so that puts the 49$/month for access to software management in perspective for me.
Anyways batch files with API calls works for now, and hopefully in near future we will have queued firmwares and automatic system firmware updates (which I believe are only working when using web ide atm, correct?).