[gregmac]

Yeah, at the core of it I see this as a value problem.

If you charge a lot, it's a tough or impossible sell for users who aren't yet sure they'll get that amount of value from it. If you charge too little, you're leaving money on the table from big customers who would be willing to pay much more.

Setting the up-front cost also requires you to estimate a bunch of things: what will it cost you to build (including future time to get to "feature complete" for this version), how many do you think you are going to sell, how much time is each customer going to take up? In other words: this is what you value your time at, but you can't know most of the numbers used ahead of time. You need this for subscriptions, too, but there's a bit more latitude to change, and you don't necessarily have any obligations should you decide to just stop at the end of the next billing cycle.

Longer term, there's also an incentive problem for you as the vendor. If you're very successful and saturate your market, why build new versions? Your incentive switches to making a "major" version with huge upgrades, which has a whole ton of downsides (which smart customers see, or learn the hard way). It's riskier than frequent, small releases: your first major real testing and feedback comes after a ton of massive changes. It incentives change for the sake of change (so you can justify a "major" version) as opposed to real improvements. Even fixing bugs becomes purely a cost, the only real incentives are pride/reputation, and hoping they'll buy the next major version.

Subscriptions help even this out, and tying the cost to some usage metric can make the cost reflect the value even more, even as the usage changes over time (eg: the customer grows).

The worst thing with subscriptions is when the cost doesn't reflect the value. If as a user, you pay $20/mo for something that enables you to make $2000/month, that's a no-brainer. When you have to pay $20/month for something that is useful 4 or 5 times a year, or when it's really hard to figure out what, if any, value you're getting for your money, that's when it becomes a problem.

[carlosjobim]

> If you're very successful and saturate your market, why build new versions?

I don't think you can ever be saturated in number of customers, if you have a good thing and are on the right track, the moon is the limit. You build new versions to increase the user base.

If you're in a niche market that can actually become saturated, then your customers are likely professionals and willing to pay much more than consumers, since they make money from your software.

[tonyedgecombe]

>If you charge a lot, it's a tough or impossible sell for users who aren't yet sure they'll get that amount of value from it.

Customers often value things by how much they pay for them. I saw my sales increase after my first price rise.