How much should software cost? Our approach exposed.

We're rethinking our pricing model for DoneDone, our web-based issue tracking tool, and want to open up our entire thought process, lessons learned, and epiphanies to you.Our current pricing plan is simple: You pay $24/month for one project, and then $5/month for each additional project.When we launched last month, we asked some of our early customers what they thought about our pricing. We got some great feedback. Everyone had slightly different ideas. Then we stopped asking and thought what is this thing really worth. Finally, I read Joel Spoltsky's article on software pricing. He recommended the following:

"Take my advice, offered about 20 pages back: charge $0.05 for your software. Unless it does bug tracking, in which case the correct price is $30,000,000. Thank you for your time, and I apologize for leaving you even less able to price software than you were when you started reading this."

We're now certain that somewhere between free and $30,000,000 seems like the right price point. Mark our words.Why we chose a linear pricing modelWe chose to price DoneDone on a per-project basis (linear) rather than on the far-more-familiar tiered pricing method. That's because we guessed most companies attracted to DoneDone would be in the same boat we're in: A small shop with only a few projects in QA at a time. As a quick comparison, we have 30+ projects open in Basecamp at any given time, but only one or two are in a true "testing" phase.By charging per project, you only pay for what you use - and you can always archive a project as well. Archived projects are free.Why not do the tried & true tiered model?We're against the tiered model because we didn't like the big "steps" up to a new tier. Having tiers by project (e.g. 1 project for $, 10 projects for $$, 25 projects for $$$, and 1,318 projects for $$$$$$!) didn't make sense if our hunches were correct. If most companies indeed would only have a couple of projects active at a time, the leap to a plan with a bunch more projects would never make financial sense to them.But, we've received a bunch of mixed reviews about our linear model.For one, it's a different model than what most of our competitors use. And, it's probably not a great idea to be innovative with something like asking for people's money when virtually everyone selling web-based software is doing that same tiered-pricing thing. (Plus, it's the one time you can legitimately make a table in HTML without your HTML buddy getting-all-up-in-your-$hit).There's potentially a lesson in this, though. We should be weary about forcing our hunches into the pricing model. Perhaps sticking with a cost structure that's tested with apps roughly similar to ours (but not necessarily how we think people will really use DoneDone) is a better way to go. Perhaps.Also, part of the beauty of the tiered model is that bit of marketing sleight-of-hand:

"Why pay double platinum at $149 a month,when that bronze plan at $29 is so much more affordable?"

How some of our competitors are pricingIf we're wrong on our hunch, that companies do want the flexibility of having a bunch of projects open at a time, then our current pricing cost flat out sucks compared to our competitors. There are about 8 billion bug/issue trackers on the market. Here's how we currently compare to a couple of comparable competitors, Sifter and Lighthouse:

In the beginning, our model falls in line with the other two. But as we add more projects, things start to go bad quickly. Again, given our assumption that people only have a few active projects at a time, it's a non-issue. Get anywhere above 10 projects and things quickly start lookin' down for us. The m part ($5) of our "y = mx + b" needs to change. So does the b ($24). Finally, we don't have a natural cap on the cost because we didn't think that would ever rear its ugly head. Yes, if someone has 1000 projects, they'd be paying...$5,019/month. But is that ever realistic? Probably not. But, from a quick glance, the never-ending orange slope looks like a rather ominous predicament.Why we like linear pricing over tiered pricingA bit ago, I said we should be wary about burying our philosophy into the pricing model. But, we still think a linear model still has its advantages to the tiered model, particularly with something like issue tracking.Where the tiered model "hurts" is at the beginning of each tier. With Sifter, you're paying as much for 11 projects as you are for 25. You're paying as much for 26 projects as you are for 50. While our guess that people will use DoneDone for only a few active projects at a time might be wrong, assuming a company hovers around a sweet spot of active projects is probably a safe assumption. For us, that sweet spot might be...2. For a different company, it might be 8 or 15 or 24. Who knows.If you happen to hover around a tier, you're in a bit of a conundrum. Go down a tier and you have to worry too much about hitting your limit. Go up a tier and you might be paying double for just one or two more projects.We still like the linear approach. It holds to our philosophy, but it probably needs some tweaking. We need to make it more competitive and advantageous for you.Sticking with our approach with some tweakingWhat have we learned? We like our approach in theory but a few things need to be changed:

• Charge less up front.
• Make the incremental slope more gradual (each project should be a lot less).
• Put a cap on it.

Instead of charging $24/month up front and $5/month for each additional project, we're thinking of tweaking the initial cost to $15/month for the first 3 projects, then $2/month for each additional project. We also want to provide a cap at $99/month (which happens to be 45 active projects) to assuage the fears that costs can get unreasonably high. We still don't think too many companies will get to that level - and if they do, it really doesn't hurt us to cap the cost (storing that extra data is cheap). Let's see how this quasi-linear approach works:

Now, we're far more competitive and, overall, more advantageous by sticking to the linear approach. Admittedly, we're still charging more (on average) than Lighthouse does after 20 projects. But the benefit of the linear approach is the cost-hits are always incremental.If our second hunch is right, that most companies will hover around a set number of active projects at any given time, the natural peaks and valleys a company experiences throughout the year won't drastically affect cost. In a tiered plan, if you're hovering near a tier (say you have 22 Sifter projects or 38 Lighthouse projects), you need to consider the cost hit of the next big tier.Will this work better?We think it does. But, because we don't want to charge like everyone else, there's more 'splainin to do.

It's easy for someone to see our approach and not like that there's a per-project charge (albeit, after 3 projects in this new model). But, when you really break it down, we hope you see where we're coming from.We'd love to know your thoughts.