I’ve been fascinated by the ongoing war in the software development world between upfront and subscription pricing models. I was thinking about how I’d approach this pricing issue if I was an App Store developer and wanted to use my tried-and-true manufacturing cost analysis. Manufacturing physical objects is nothing like developing software, but the basic principles of time, value of money, and cost allocation still apply.
Pricing
From a software developer’s point of view, pricing an app is largely the same whether you are going to use the subscription or upfront model. The exercise of calculating your upfront costs for software creation and post-launch customer support costs isn’t going to change. You are simply going to allocate your costs over a different unit of measure depending on the method that you choose.
Definitions
Development Cost - The cost of creating your software product prior to launch.
Support Cost – The cost of supporting your customers and maintaining the software after launch through the end of the product’s life.
Calculating the Upfront Method
This is the old-school way. You sell a customer one full “unit” which would be the full cost of the software package with no monthly fee.
1. Development Hours x Rate = Total Development Cost
2. Lifetime Support Hours x Rate = Support Cost
3. (Development Costs + Support Costs)/Total Forecasted Sales Units = Cost of Sales per Unit
4. Unit Cost of Sales / (1 minus Profit %) = Sell Price per Unit
Calculating the Subscription Method
Calculating the subscription costs entails redefining your units. Not every customer is going to subscribe for the same amount of time, so you’d have to create a subscription model to estimate total periods. If your product had a lifespan of two years and 5% of your subscribers sign up in month one, then you get twenty four “units” from 5% of your customers. 2% of your customers are going to sign up in month 21 so you’ll only get 4 periods from 2% of your market. And so on.
1. (Development Costs + Support Costs)/Total Forecasted Periods Sold = Cost of Sales per Period
2. Cost of Sales per Period / (1 minus Profit %) = Periodic Subscription Price
From a software developer’s point of view, pricing an app is largely the same whether you are going to use the subscription or upfront model. The exercise of calculating your upfront costs for software creation and post-launch customer support costs isn’t going to change. You are simply going to allocate your costs over a different unit of measure depending on the method that you choose.
Definitions
Development Cost - The cost of creating your software product prior to launch.
Support Cost – The cost of supporting your customers and maintaining the software after launch through the end of the product’s life.
Calculating the Upfront Method
This is the old-school way. You sell a customer one full “unit” which would be the full cost of the software package with no monthly fee.
1. Development Hours x Rate = Total Development Cost
2. Lifetime Support Hours x Rate = Support Cost
3. (Development Costs + Support Costs)/Total Forecasted Sales Units = Cost of Sales per Unit
4. Unit Cost of Sales / (1 minus Profit %) = Sell Price per Unit
Calculating the Subscription Method
Calculating the subscription costs entails redefining your units. Not every customer is going to subscribe for the same amount of time, so you’d have to create a subscription model to estimate total periods. If your product had a lifespan of two years and 5% of your subscribers sign up in month one, then you get twenty four “units” from 5% of your customers. 2% of your customers are going to sign up in month 21 so you’ll only get 4 periods from 2% of your market. And so on.
1. (Development Costs + Support Costs)/Total Forecasted Periods Sold = Cost of Sales per Period
2. Cost of Sales per Period / (1 minus Profit %) = Periodic Subscription Price
Upfront vs Subscription
Part of what makes this whole discussion so fascinating to me is that what seems more logical from a financial review turns out to be the opposite of what is actually happening.
You’d think the developers would like the upfront method better since they lock-in their full payback. It’s also easier for them to calculate since they don’t need to segment their customers into tiers of periods purchased. But that’s not what is happening. Developers seem to be gravitating towards the subscription model even though it seems to be against their self-interest.
I'm guessing this is happening because most software developers have done a rotten job of either creating a good financial model or forecasting their sales. Admittedly, this isn’t an easy task. As a result, they underprice their software and find themselves not able to pay their support costs. From this perspective, the subscription method could look inviting because it offers the promise of constant revenue.
Then there are the consumers who you’d think would favor the subscription model. You don’t have to foot the whole bill up front, so if you’re low on cash this makes a software purchase easier. You also mitigate your risk. If you don’t like the software you can just cancel after a month or two, and you don’t lose as much money as you would have if you’d paid the entire cost up front. But consumers are actually upset at moving to a subscription model. And I don’t blame them. If you calculate the present value of the cash stream going to some of these software companies the cost of this software is exponentially higher than the old way. How are these guys calculating their monthly prices?
Also, if you’re the type of person who wants to buy a piece of software and use it for the next ten years it’s going to be a money losing proposition to subscribe monthly. Additionally, I’m not sure that these software developers are correctly calculating what a fair-but-profitable period cost should be. Nobody wants to pay $2 per month for what would have been a $20 piece of software.
Personally, I think software should be sold like cars. You should have the option of buying it outright or subscribing. Subscribing would be like leasing a car, which works for some people but not others.
If a software developer does his due diligence and creates a decent financial model and can get a ballpark accurate forecast, it really shouldn’t matter how they sell it. If anything, revenue should be higher. In theory, if customers had a choice, you would have higher sales since you’re not losing the segment that dislikes your chosen method. With today’s binary choice, you alienate a segment of your potential market either way you go.
Part of what makes this whole discussion so fascinating to me is that what seems more logical from a financial review turns out to be the opposite of what is actually happening.
You’d think the developers would like the upfront method better since they lock-in their full payback. It’s also easier for them to calculate since they don’t need to segment their customers into tiers of periods purchased. But that’s not what is happening. Developers seem to be gravitating towards the subscription model even though it seems to be against their self-interest.
I'm guessing this is happening because most software developers have done a rotten job of either creating a good financial model or forecasting their sales. Admittedly, this isn’t an easy task. As a result, they underprice their software and find themselves not able to pay their support costs. From this perspective, the subscription method could look inviting because it offers the promise of constant revenue.
Then there are the consumers who you’d think would favor the subscription model. You don’t have to foot the whole bill up front, so if you’re low on cash this makes a software purchase easier. You also mitigate your risk. If you don’t like the software you can just cancel after a month or two, and you don’t lose as much money as you would have if you’d paid the entire cost up front. But consumers are actually upset at moving to a subscription model. And I don’t blame them. If you calculate the present value of the cash stream going to some of these software companies the cost of this software is exponentially higher than the old way. How are these guys calculating their monthly prices?
Also, if you’re the type of person who wants to buy a piece of software and use it for the next ten years it’s going to be a money losing proposition to subscribe monthly. Additionally, I’m not sure that these software developers are correctly calculating what a fair-but-profitable period cost should be. Nobody wants to pay $2 per month for what would have been a $20 piece of software.
Personally, I think software should be sold like cars. You should have the option of buying it outright or subscribing. Subscribing would be like leasing a car, which works for some people but not others.
If a software developer does his due diligence and creates a decent financial model and can get a ballpark accurate forecast, it really shouldn’t matter how they sell it. If anything, revenue should be higher. In theory, if customers had a choice, you would have higher sales since you’re not losing the segment that dislikes your chosen method. With today’s binary choice, you alienate a segment of your potential market either way you go.
RSS Feed