COMMENTS
I think that fixed plans are a good thing - much simpler and easier to understand. So, thanks for that. One remark though: I think the "Professionnal" plan should have more spaces. It would be a big leap to upgrade from $99 to $249 just because we'd need an extra space after the 20 space limit is used up.
I can't believe you're proposing a fixed-price, centralised pricing plan for agile, distributed projects! I agree that the current way things are paid for is confusing, but what you have isn't a pricing problem, it's an information design problem.
If we, your users, can grok
git and handle
scrum, then a bit of pricing agility, if presented properly, isn't going to phase us. I don't think people would be at all confused if you simply listed how much we were paying for each project, and also how much for each person across all projects. Then offer bulk discounts on a user-project-by-user-project basis (for example: offer unlimited spaces, charge the first 100 user-projects at one price, the next 400 at a lower price etc.).
The current pricing structure, with the $8 cap, is a pretty clear motivation to stay loyal to assembla and the capped users, and use them for as MANY projects as possible and to keep growing. On the other hand, the new pricing structure motivates people to use Assembla for as FEW projects as possible and to keep things small, because each plan has an upper limit (and why on earth is the best value at the middle, not the upper end!). From where I'm standing, it feels pretty lame to be constrained like that.
(While I'm at it, another easy fix that would help A LOT is if we can make spaces read-only, so we can stop paying for them once the project has finished, or gone on hold, without losing data)
Finally: regardless of whether you listen to feedback and revise the pricing, even if it's a year away for us, this is the second time in a few months that I am compelled to investigate alternatives to Assembla. Worrying about what price/structure you'll settle on is becoming a hassle I don't want to have to repeat any more. I'd urge you to be much more careful about mucking around with the wallets of your loyal customers in future.
That's very comforting to hear, Andy, thanks. It still feels like a strange match to me, but it doesn't worry me now. I see a lucrative sideline in starting flat raters' 21st spaces for them! :-)
As for the information design for per-user plans, for now it would be a great start to have a column in "Manage Spaces" showing how many users, how many capped users, and what each plan would cost if there were no caps, and a summary at the end of who our capped users are, and how much we are saving due to each cap.
But yeah, that's just off the top of my head, though I do know my interaction design. I'd be happy to comment further on a UI sketch, say.
This is an erm... "interesting" move, as one of the companies that uses lots of repositories and has less than 10 users the new plans don't really fit our needs economically.
We like Assembla and weren't looking to change anything but now, I think, we are forced to. I appreciate the year you've given us to migrate elsewhere though.
I have to say that regardless of how much the pricing model changes, Assembla is hands down one of the best online project management systems out there (and I have tried and worked in some of the best PM systems out there). Comparing apples to apples, the cost for project management using Assembla is a drop in the bucket compared to other systems out there.
I just left a company that is using Creative Manager Pro (aka Workamajig) and the pricing model there for a 25 person team with no clients was nearly $875 A MONTH. It is not centered around agile process, does not have version control (let along multiple version control options) and in the end was a monster to work with.
I hope that the Assembla team continues to do what is necessary to fullfill the needs of their clients and not get hung up on the few people out there who are either too cheap to see the value or too dense to see the logic of choosing a partner that understands at the end of the day, it is all about getting things done.
My only feature requests would be for either tying in Freshbooks or providing a streamlined bookkeeping component like Freshbooks and the ability to archive a space. Maybe just paying for the disk space would be the key to monetizing this. We often have projects that are built, launched and then sit for months with no activity. But once that project is pulled out of mothballs, the first things we do is check out a working copy of the project and know that we are starting back up, right where we left off.
Thanks so much for the hard work!
And by the way, as it looks for us right now, our bill will go up slightly if we stay on the metered pricing (which we probably will) but it will not affect our buy-in for the Assembla product.
Thanks again!
--
Jamie Meredith
Lead Developer
South Central Media
Nashville, TN
615-440-1915
For info, without Andy's generous offer to loyal subscribers we'd have moved from $76 to $249 per month, so not a small move financially.
I would submit that even at that price point change you are only looking at $2000 more a year for a product that drives delivery, ensures quality and enhances communication. For the average development shop we are talking less than 15 hours ($150/hr) of work over the course of an entire year. Divide that number by an average shop size of say 10 people, and you are looking at less than 1.5 hours of billable time each month covering this cost increase. That is less than .15 hours per person, per month. That is a coffee breaks worth of time that has to be added to each employees roster of work. Insignificant in my opinion.
For smaller shops, the smaller packages make much more sense and keep the costs to a minimum. I suspect that many who are going to gripe are not the ones who are seeing the value of having to find an alternative. Just my two cents.
I signed up for the metered plan with the $8 cap (easy to understand) just before the new pricing plans started. I'm very happy I did because none of the new plans meet my needs. We are a very small shop, just 4 of us, all part time. We get some larger projects and more small projects. A fixed price plan that would work best for us is a small number of users and a large number of spaces. Our projects may last a long time, in part because our clients expect fixes and changes months or even years later. We also create a project for building a proposal and then move it on to coding and release. If we were operating with a fixed project limit, we'd have to be in the top bracket in a month or so, or stop using assembla for proposals and also need a way to completely archive and restore a complete assembla space offline.
I do like the service.
I'm dissapointed that you have felt the need to change the plan and remove the easy start options. I think you may be shooting yourselves in the foot, but I guess you weren't making enough money from the current plans - otherwise why change?
I run a two person developer team with occassional additional outsourced help and the price and structure suited me. I have lots of small projects so the $8 cap fitted perfectly. I had factored Assembla in as a strategic tool to grow with as I grow, but I'll be taking a close look at what my alternatives are again now. A 50% hike in cost per space plus removal of caps.
I know you are saying it wont impact me in the short term, but I don't like being a special case (they have a habit of not being considered in other changes) , and I can't afford to be held ransom at some time in the future to big changes in pricing structure. Right now I'm just nervous and thats not good. If you are looking to migrate your customer base from small startups to big companies, your strategy might just work, but I certainly won't be able to recommend you to my friends anymore.
As a solo developer, just starting up, Assembla has become quite uncompetitive as time has progressed. You no longer offer a package that is attractive to developers like myself. The $2/3 idea is actually offered for free elsewhere. Perhaps you should introduce a package based on storage space only. Allow users to create as many spaces as they like but limit their storage space and charge based on that.