Ask HN: What's a good business model for selling standalone software?
79 comments
From my point of view the "jetbrains" licence model is one of the best:
- You can purchase their software with a single annual fee or 12 monthly fees
- If you purchase with an annual fee you can use the last updated purchased version forever. Also, if you pay for 12 month continuously you have the same advantages
- If you purchase the same software for 2 sequential years you will receive an automatic discount and at the end of the third year you will obtain a fixed discounted price (if I remember correctly around 20% forever)
Also they have a lot of bundles but this is valid only if you have a lot of software that are not necessarily usefull for all users but that can be usefull for some specific categories of useres.
- You can purchase their software with a single annual fee or 12 monthly fees
- If you purchase with an annual fee you can use the last updated purchased version forever. Also, if you pay for 12 month continuously you have the same advantages
- If you purchase the same software for 2 sequential years you will receive an automatic discount and at the end of the third year you will obtain a fixed discounted price (if I remember correctly around 20% forever)
Also they have a lot of bundles but this is valid only if you have a lot of software that are not necessarily usefull for all users but that can be usefull for some specific categories of useres.
I think the only caveat here is it only works for software which is mostly offline. If you software is highly dependent on Cloud services then maintaining backwards compatibility for the people who have stopped paying and use old versions quickly becomes costly. But I guess if your software is dependent on Cloud services than it is more of a service.
I think jetbrains really got it right. Everyone I know has been giving jetbrains money forever, and I don't think I've ever heard a complaint about their pricing or business model.
The switch to the current pricing model was anything but smooth. The uproar was so bad they had to come back with a revised plan. A lot of people were still upset with the revised plan after it launched.
Not my site, but this blog entry explains what happened: http://muppetgate.github.io/the-jetbrains-subscription-blood...
Not my site, but this blog entry explains what happened: http://muppetgate.github.io/the-jetbrains-subscription-blood...
In they end they listened to their customers. I use clion regularly for personal work. It's not eggregiously expensive and new features are always comming in so I feel like I get my money's worth and it's not cost prohibative.
Hint: deliphi, take note
Hint: deliphi, take note
[deleted]
I don't like limiting anyone to older versions. As the OP said, it's difficult to maintain. You'd have to be aware of every bugfix and improvement so that when they want a feature or bugfix, you know to direct them to the latest version. It's easier if everyone's on the latest version or at least can update if they feel that might solve their problem.
It might be a way to satisfy both people who want a perpetual license and to get recurring revenue and pay for future development, but it's kind of arbitrary to make the distinction at version numbers instead of features or easily-identified packages of features.
It might be a way to satisfy both people who want a perpetual license and to get recurring revenue and pay for future development, but it's kind of arbitrary to make the distinction at version numbers instead of features or easily-identified packages of features.
> I don't like limiting anyone to older versions. As the OP said, it's difficult to maintain.
You don’t maintain it, if you need a bug fix or new feature you have to upgrade to the newest perpetual license. IMO this is a much better model than the subscription model.
You don’t maintain it, if you need a bug fix or new feature you have to upgrade to the newest perpetual license. IMO this is a much better model than the subscription model.
> it's kind of arbitrary to make the distinction at version numbers instead of features or easily-identified packages of features.
That is literally what version numbers are made to represent
That is literally what version numbers are made to represent
I like the JetBrains model. You subscribe (annually, in my case), and for as long as you maintain the subscriptions, you get updates. If you cancel, you keep and can use the version you bought forever. The vendor gets recurring revenue, and the customer gets to own their tool.
I agree. JetBrains is my favorite model to interact with. I especially like the 'loyalty discount' where you get some percentage off for every year you're subscribed (caps at 3 years).
“The version you bought forever”
Do you mean the latest version that was released while you were subscribed? If so, that sounds ideal. You’re buying software and paying for them to keep improving it… until you want to stop.
Do you mean the latest version that was released while you were subscribed? If so, that sounds ideal. You’re buying software and paying for them to keep improving it… until you want to stop.
If you stop paying now you get forever access to the Nov 2021 version. The way I look at it is, my money gets me the current version, plus a year of "previews".
I'm not actually a jetbrains user, but I do like the general model; could be adapted to "you get to keep the latest version, as long as you've been paying for the previous year.
I'm not actually a jetbrains user, but I do like the general model; could be adapted to "you get to keep the latest version, as long as you've been paying for the previous year.
Yep
Who's the customer? How are they using it? Will it be a substitutable technology?
Don't trust the consensus in here, it's a very biased sample set.
You should probably familiarize yourself with basic product, sales and marketing books.
The problem is for these purposes software isn't a useful category. Infrastructure management is way different then say, creating bingo cards and it shouldn't be sold the same way.
I like to recommend Ries and trout 22 immutable laws of marketing as a first step. You can read it in literally an hour.
It's not free of bullshit but abstractly it's a good framework for thinking about products. Redefine "law" as "majoritarian observation" and it's basically now all correct
(Btw, the one minute manager series and stuff by seth godin are all, 100% complete bullshit along with probably 90% in these categories. But there's a few decent things. One that often gets overlooked in the whitelist of not-lies is Andy Grove of Intel - the bullshit dial is hovering around 0 on his stuff)
Don't trust the consensus in here, it's a very biased sample set.
You should probably familiarize yourself with basic product, sales and marketing books.
The problem is for these purposes software isn't a useful category. Infrastructure management is way different then say, creating bingo cards and it shouldn't be sold the same way.
I like to recommend Ries and trout 22 immutable laws of marketing as a first step. You can read it in literally an hour.
It's not free of bullshit but abstractly it's a good framework for thinking about products. Redefine "law" as "majoritarian observation" and it's basically now all correct
(Btw, the one minute manager series and stuff by seth godin are all, 100% complete bullshit along with probably 90% in these categories. But there's a few decent things. One that often gets overlooked in the whitelist of not-lies is Andy Grove of Intel - the bullshit dial is hovering around 0 on his stuff)
fwiw ... the chapters of R&T:
1. The Law of Leadership
2. The Law of the Category
3. The Law of the Mind
4. The Law of Perception
5. The Law of Focus
6. The Law of Exclusivity
7. The Law of the Ladder
8. The Law of Duality
9. The Law of the Opposite
10. The Law of Division
11. The Law of Perspective
12. The Law of Line Extension
13. The Law of Sacrifice
14. The Law of Attributes
15. The Law of Candor
16. The Law of Singularity
17. The Law of Unpredictability
18. The Law of Success
19. The Law of Failure
20. The Law of Hype
21. The Law of Acceleration
22. The Law of Resources
1. The Law of Leadership
2. The Law of the Category
3. The Law of the Mind
4. The Law of Perception
5. The Law of Focus
6. The Law of Exclusivity
7. The Law of the Ladder
8. The Law of Duality
9. The Law of the Opposite
10. The Law of Division
11. The Law of Perspective
12. The Law of Line Extension
13. The Law of Sacrifice
14. The Law of Attributes
15. The Law of Candor
16. The Law of Singularity
17. The Law of Unpredictability
18. The Law of Success
19. The Law of Failure
20. The Law of Hype
21. The Law of Acceleration
22. The Law of Resources
The missing ingredient is whom it is that's producing the software.
If I wanted to be a solo developer, I would go with option 1 and simply charge as high a price as I possibly can and still make enough profit. That way I have better quality customers and fewer of them to complain about things. If a feature is widely requested, my customer base already has demonstrated that they've reached financial "escape velocity" and may be willing to front the money to make new features happen. What I might do from the outset is split more distinct features into their own "add-ons" that can be paid for extra. That way, if a feature is needed but only applies to a fragment of my user base, only the people who want it will be charged for it.
Subscription models are idealized because you can charge peanuts and rely on the fact that most people won't remember to cancel their subscription. I'm not much a fan of this model because the quality of user is lower and it turns every user into a customer all the time. A one time purchase, on the other hand, doesn't necessarily imply that support be provided indefinitely. From a technological perspective, managing subscriptions is a pain in the rear, whereas not a whole lot of code is needed to charge cards just a single time. You might need a license server, but I'd rather my license server be compromised than find a rogue for-loop charged my customer's credit cards a hundred times over.
If I wanted to be a solo developer, I would go with option 1 and simply charge as high a price as I possibly can and still make enough profit. That way I have better quality customers and fewer of them to complain about things. If a feature is widely requested, my customer base already has demonstrated that they've reached financial "escape velocity" and may be willing to front the money to make new features happen. What I might do from the outset is split more distinct features into their own "add-ons" that can be paid for extra. That way, if a feature is needed but only applies to a fragment of my user base, only the people who want it will be charged for it.
Subscription models are idealized because you can charge peanuts and rely on the fact that most people won't remember to cancel their subscription. I'm not much a fan of this model because the quality of user is lower and it turns every user into a customer all the time. A one time purchase, on the other hand, doesn't necessarily imply that support be provided indefinitely. From a technological perspective, managing subscriptions is a pain in the rear, whereas not a whole lot of code is needed to charge cards just a single time. You might need a license server, but I'd rather my license server be compromised than find a rogue for-loop charged my customer's credit cards a hundred times over.
Thanks, very useful reply
A perpetual fallback license model is the most customer-friendly I've encountered. It's effectively a subscription model which doesn't have the customer losing access to the software when they stop paying their subscription. They would simply have access to the most updated version at the time of their subscription lapsing.
Having features locked behind a paid subscription in software that's otherwise free is probably next best but I find myself being frustrated by this more often than not.
Having features locked behind a paid subscription in software that's otherwise free is probably next best but I find myself being frustrated by this more often than not.
> have access to the most updated version at the time of their subscription lapsing.
Since JetBrains has been mentioned multiple times here, it's worth pointing out that they do not do this. If you do not renew, the fallback license applies to the version on the day you purchased, not the version at the time the license lapsed.
Since JetBrains has been mentioned multiple times here, it's worth pointing out that they do not do this. If you do not renew, the fallback license applies to the version on the day you purchased, not the version at the time the license lapsed.
JetBrains may not, but others that implement a perpetual fallback license do what the OP is expecting [0..3]. I also run a software licensing API that supports a perpetual fallback license model like this via a RESTRICT_ACCESS expiration strategy on the license policy [4], so a lot of my customers use the same model for their applications.
[0]: https://help.panic.com/nova/purchase-faq/
[1]: https://devutils.com/perpetual_license/
[2]: https://www.sublimehq.com/sales_faq
[3]: https://proxyman.io/pricing
[4]: https://keygen.sh/docs/api/policies/#policies-object-attrs-e...
[0]: https://help.panic.com/nova/purchase-faq/
[1]: https://devutils.com/perpetual_license/
[2]: https://www.sublimehq.com/sales_faq
[3]: https://proxyman.io/pricing
[4]: https://keygen.sh/docs/api/policies/#policies-object-attrs-e...
> If you do not renew, the fallback license applies to the version on the day you purchased, not the version at the time the license lapsed.
It's not as bad as that. Your fallback license is updated every 12 consecutive months. If you do not renew after a 12 month period, your fallback license will be for the version from 12 months ago. [1]
[1]: https://sales.jetbrains.com/hc/en-gb/articles/207240845-What...
It's not as bad as that. Your fallback license is updated every 12 consecutive months. If you do not renew after a 12 month period, your fallback license will be for the version from 12 months ago. [1]
[1]: https://sales.jetbrains.com/hc/en-gb/articles/207240845-What...
That seems hard to manage if you have data upgrades. For example, a new version adds new data fields, obsoleting old ones. If you don't renew, you have to revert to a version from 12 months ago? That version doesn't support the new data fields, only the old ones, which no longer exist. Or maybe I don't get it.
If you pay the subscription yearly, it makes sense, though it's not completely ideal. You get a fallback license for the version at the time you paid for the year. The monthly subscription complicates this because someone could game the fallback license scheme if you were immediately granted a fallback license (e.g., you only subscribe for 1 month every year). This is why I think JetBrains updates the fallback license every 12 consecutive months. The monthly subscription acts equivalent to that of the yearly. Ideally, yes, it would be nice if the fallback license was effective from when your subscription ended rather than the last yearly renewal.
Just to provide another data point in addition to JetBrains, the license for NCrunch (which I very much recommend) is similar. Being a paid user of both of them I find that kind of option pretty ideal. The main difference between them is that NCrunch allow the latest version available in the qualifying period as the fallback one and JetBrains use the earliest.
I came to suggest exactly this, though I'm not sure I've ever seen it in the wild.
Set a flat minimum amount you need to collect for the software and allow your customer to either pay that out in subscription payments (and then continue paying if she wants to keep receiving updates) or, if she decides to cancel her subscription early, allow her to pay any remaining difference between the sum of her subscription payments and your flat price.
Set a flat minimum amount you need to collect for the software and allow your customer to either pay that out in subscription payments (and then continue paying if she wants to keep receiving updates) or, if she decides to cancel her subscription early, allow her to pay any remaining difference between the sum of her subscription payments and your flat price.
You're probably aware of all of the following, but no one else has mentioned it, so I thought I'd add it.
I'm a mechanical engineer that uses a variety of commercial software, as well as developing extensions for that software via the software's API, and also developing standalone software for our own internal purposes.
A lot of that commercial software that we use has a very long history, sometimes even starting way back in the mainframe days. It's expensive stuff, costing $100k or more per user.
A couple of programs follow the pure subscription model, and none of them follow the pay once to 'own', with a period of maintenance built into the purchase price.
What most of them follow is what I'll call a purchase and maintain model. The user purchases the software, then pays a yearly maintenance fee (typically 1/8 the purchase price) that provides regular updates and support (via phone and web portal) for as long as the maintenance fees are paid.
If the user stops paying maintenance, the then current version continues to be usable indefinitely, but the updates and support stop.
If the user decides to stop paying maintenance for a period of time, then wants to restart it, the user has to either 1) make all the maintenance back payments all the way back to when the payments stopped, or 2) , repurchase the software.
I don't know if any of that is useful to you, but it seems like you were trying to gather ideas on business models. I've spoken to some of the software companies that use this model, and they like it. They use it to make a rough internal allocation of resources/funds. The income from the maintenance fees covers the staff directly supporting end users, plus bug fixes. The income from the initial purchases funds strategic and tactical development of new functionally.
A final note: all of this often uses a floating license model with a central licensing server within the end users' controlling the number of simultaneous users (though a license file tied to particular computer(s) can be installed locally as an alternative). The users' company pays the yearly maintenance fee up front to get a licencing file that authorizes usage for the next 12 months. I don't see how this could work without running a licencing server, or across the internet, and that be more complicated than anything you want to consider.
I'm a mechanical engineer that uses a variety of commercial software, as well as developing extensions for that software via the software's API, and also developing standalone software for our own internal purposes.
A lot of that commercial software that we use has a very long history, sometimes even starting way back in the mainframe days. It's expensive stuff, costing $100k or more per user.
A couple of programs follow the pure subscription model, and none of them follow the pay once to 'own', with a period of maintenance built into the purchase price.
What most of them follow is what I'll call a purchase and maintain model. The user purchases the software, then pays a yearly maintenance fee (typically 1/8 the purchase price) that provides regular updates and support (via phone and web portal) for as long as the maintenance fees are paid.
If the user stops paying maintenance, the then current version continues to be usable indefinitely, but the updates and support stop.
If the user decides to stop paying maintenance for a period of time, then wants to restart it, the user has to either 1) make all the maintenance back payments all the way back to when the payments stopped, or 2) , repurchase the software.
I don't know if any of that is useful to you, but it seems like you were trying to gather ideas on business models. I've spoken to some of the software companies that use this model, and they like it. They use it to make a rough internal allocation of resources/funds. The income from the maintenance fees covers the staff directly supporting end users, plus bug fixes. The income from the initial purchases funds strategic and tactical development of new functionally.
A final note: all of this often uses a floating license model with a central licensing server within the end users' controlling the number of simultaneous users (though a license file tied to particular computer(s) can be installed locally as an alternative). The users' company pays the yearly maintenance fee up front to get a licencing file that authorizes usage for the next 12 months. I don't see how this could work without running a licencing server, or across the internet, and that be more complicated than anything you want to consider.
Your points are really valuable, but don't forget, that mechanical engineering software (MES) is very special market, with it's own decades old traditions, which are not guaranteed to work on other markets.
For example, users of MES, usually very conservative and deeply tied to their current software stack, so vendors could manipulate these ties and make additional profits, or use them (ties) to make themselves life's easier.
For example, users of MES, usually very conservative and deeply tied to their current software stack, so vendors could manipulate these ties and make additional profits, or use them (ties) to make themselves life's easier.
This is what we use on our manufacturing execution system (MES) to our manufacturing clients. Maintenance is what keeps us alive. Its easier to earn money thru maintenance existing clients than finding a new client.
New features that are added outside the scope of the current version will have a new contract. new contract means outside of maintenance and will have to pay more.
Good advice is in short supply because most of the market reoriented in favor of SaaS and subscription pricing (buoyed by lofty market valuations and predictable revenue streams)
Perpetual licensing + paid support and maintenance contract balances the core goal.
That said, sometimes software is just "done". The classic unix utilities like `cat` don't need monthly releases. If you can reach that stage, there should be no need to ship new developments regularly and focus should shift to ensuring it keeps running ("maintenance mode")
Perpetual licensing + paid support and maintenance contract balances the core goal.
That said, sometimes software is just "done". The classic unix utilities like `cat` don't need monthly releases. If you can reach that stage, there should be no need to ship new developments regularly and focus should shift to ensuring it keeps running ("maintenance mode")
We are far away from that stage. My view is that there is more profitable and wanted by customers directions that we will ever be able to follow. This is one of the reasons we are looking for a business model that helps us focus on programming and shipping new things.
Love the JetBrains model. Another viable option is "moderately priced one time purchase that includes free updates to the core product forever". This seems to be working fine for FL Studio over the last 20+ years. I think three of the reasons it works for them are:
* feels like a great deal and so produces word of mouth that leads to extra unit sales. Anecdotally, I have definitely observed/experienced this personally
* indie musicians are (probably??) relatively easygoing & forgiving as far as desktop software customers go, meaning that long term support costs prob take a relatively small chunk out of the one time payment
* there is a steady stream of relevant and compelling but completely optional upsells to drive further revenue, in the form of (both in-house and third party) plugins and sample packs
* feels like a great deal and so produces word of mouth that leads to extra unit sales. Anecdotally, I have definitely observed/experienced this personally
* indie musicians are (probably??) relatively easygoing & forgiving as far as desktop software customers go, meaning that long term support costs prob take a relatively small chunk out of the one time payment
* there is a steady stream of relevant and compelling but completely optional upsells to drive further revenue, in the form of (both in-house and third party) plugins and sample packs
Like other mentioned JetBrain has a very good Model. I also like the model of Agenda:
https://agenda.community/t/get-all-features/21
"Agenda comes out of the box with a great set of features, completely free. There are no time or trial limits. You can use it forever, at no cost.
Agenda does offer extra premium features that require an In App Purchase, and that make the app even more powerful. If you decide to purchase the upgrade, you permanently unlock all current premium features across all of your devices. Each of them is described in detail below.
Additionally, any new premium features we add in the 12 months following your purchase are also permanently unlocked."
https://agenda.community/t/get-all-features/21
"Agenda comes out of the box with a great set of features, completely free. There are no time or trial limits. You can use it forever, at no cost.
Agenda does offer extra premium features that require an In App Purchase, and that make the app even more powerful. If you decide to purchase the upgrade, you permanently unlock all current premium features across all of your devices. Each of them is described in detail below.
Additionally, any new premium features we add in the 12 months following your purchase are also permanently unlocked."
1. Each feature will be assigned a release date
2. $45 purchase gets you all the current features and all the features updated in the next 1 year.
3. even if you don't renew, you can update to the latest version and enjoy the bugs.
4. can be purchased at any time for $15 for a second time.
This is the business model I recently developed for the Read Later software. There is a premise to implement this model "the software itself is not server dependent, all features are implemented locally"
Here is my pricing page. https://hamsterbase.com/pricing/
2. $45 purchase gets you all the current features and all the features updated in the next 1 year.
3. even if you don't renew, you can update to the latest version and enjoy the bugs.
4. can be purchased at any time for $15 for a second time.
This is the business model I recently developed for the Read Later software. There is a premise to implement this model "the software itself is not server dependent, all features are implemented locally"
Here is my pricing page. https://hamsterbase.com/pricing/
Who are your customers? I think the answer will be very different for B2C vs B2B.
I use some specialized engineering software that's by subscription. The subscription pays for the ability to use the latest version, otherwise you're locked out. And it pays for support. Only the latest version is supported. Even if you're paid up, if you have an issue, the first thing they ask you is if you've installed the latest version.
Mechanisms vary. The license I'm using can either be managed through a networked license server or a physical dongle.
Don't forget to set aside some resources just to maintain and support the licensing and purchasing processes.
Mechanisms vary. The license I'm using can either be managed through a networked license server or a physical dongle.
Don't forget to set aside some resources just to maintain and support the licensing and purchasing processes.
If it doesn't run in a browser, "cloud" host and mine customer's data, and have an ARR subscription, it might be time to dust off old-school models... :)
I used to develop expensive technical workstation software (in Engineering, but I was always friends with Marketing, and picked up some bits).
My naive engineer's idea of one model is that you offer all of:
1. Start by selling a particular version by the "seat" (say, number of simultaneous users) or "site" (maybe up to N users at a particular company, especially with WFH). (Probably you provide free minimal updates for any security and other critical defects to this exact version, but hopefully you have zero of those.)
2. Recurring revenue from support contracts. This entitles the customer to the latest version at any time, as well as responding to their questions. (Your latest version is for landing new customers, as well as additional reason to keep customers on a support contract.) Maybe you make 1 year of support contract a mandatory (maybe discounted/free) part of the initial sale, to help customer be successful, and then they can decide whether to renew, or keep running the last version under their contract period without further updates or technical support. I think this keeps you from having to maintain many version maintenance forks (except for security and other critical defects, so there's your incentive to not make those defects :). You do want to have smooth backward-compatibility, to reduce customers getting stuck happily on old version, resistant to updates (effort, fear, dealing with IT), and then see less reason to keep paying for support contract.
3. One-time or recurring revenue from training. This at least used to be significant, even when the one-time software cost alone is 4-5 figures per seat. Each training purchase involves scheduling training days/weeks with highly-skilled trainers on-site, and expensive employees all scheduled to receiving the training at the same time. Maybe you also have free async training videos and tutorials, and only really deep-pocketed customers want to spring for the on-site/virtual live trainer.
4. Systems integration and customization consulting. Some of this might be tightly paired with sales/marketing, such as systems engineers that are paired with sales, and solve gap problems as part of closing the sale. But customers might have bigger tasks they want to pay you to do with your software and their software/business.
I'm sure others can improve upon the ideas above.
I used to develop expensive technical workstation software (in Engineering, but I was always friends with Marketing, and picked up some bits).
My naive engineer's idea of one model is that you offer all of:
1. Start by selling a particular version by the "seat" (say, number of simultaneous users) or "site" (maybe up to N users at a particular company, especially with WFH). (Probably you provide free minimal updates for any security and other critical defects to this exact version, but hopefully you have zero of those.)
2. Recurring revenue from support contracts. This entitles the customer to the latest version at any time, as well as responding to their questions. (Your latest version is for landing new customers, as well as additional reason to keep customers on a support contract.) Maybe you make 1 year of support contract a mandatory (maybe discounted/free) part of the initial sale, to help customer be successful, and then they can decide whether to renew, or keep running the last version under their contract period without further updates or technical support. I think this keeps you from having to maintain many version maintenance forks (except for security and other critical defects, so there's your incentive to not make those defects :). You do want to have smooth backward-compatibility, to reduce customers getting stuck happily on old version, resistant to updates (effort, fear, dealing with IT), and then see less reason to keep paying for support contract.
3. One-time or recurring revenue from training. This at least used to be significant, even when the one-time software cost alone is 4-5 figures per seat. Each training purchase involves scheduling training days/weeks with highly-skilled trainers on-site, and expensive employees all scheduled to receiving the training at the same time. Maybe you also have free async training videos and tutorials, and only really deep-pocketed customers want to spring for the on-site/virtual live trainer.
4. Systems integration and customization consulting. Some of this might be tightly paired with sales/marketing, such as systems engineers that are paired with sales, and solve gap problems as part of closing the sale. But customers might have bigger tasks they want to pay you to do with your software and their software/business.
I'm sure others can improve upon the ideas above.
Oh yeah, and maybe additional modules or complementary product, that maybe are huge specialized functionality that one wouldn't expect to be part of the core product (for which they're already paying a support contract to get whatever new features you add to core).
I think a big part of it is going to be your business model.
If version 1 is going to be a "one and done" then you're either going to need to sell enough copies to keep you in business nearly forever, or you're going to eventually saturate your market, and there won't be much reason for people to upgrade.
If so, you would be better off with subscription and "you can use the last version after you unsubscribe for a year" or something.
However, if you are going to be developing it continually, then the jetbrains method may be best.
If version 1 is going to be a "one and done" then you're either going to need to sell enough copies to keep you in business nearly forever, or you're going to eventually saturate your market, and there won't be much reason for people to upgrade.
If so, you would be better off with subscription and "you can use the last version after you unsubscribe for a year" or something.
However, if you are going to be developing it continually, then the jetbrains method may be best.
A model that's been used for a very, very long time, successfully, is similar to the one you are now using. Sell the current version for a fixed price, and the customer owns it forever. Also sell a support subscription plan, for a fraction of the price of the software, lets say 2.5% of the flat cost, per month. Sometimes, give one year of that with the base purchase. Support contract entitles you to bug fixes and minor feature enhancements (point releases) for free, and free or discounted major upgrades.
If you go the subscription route, and offer both an annual and monthly subscription, for the love of god don't do and Adobe and make the monthly subscription a yearly subscription in disguise. Going to cancel a monthly subscription, and discovering actually you have to pay the next 9 months is an evil business model.
Just offer a discount on a yearly vs monthly subscription.
Tricking your customers and bullying them into paying for something they don't want is a sure fire way to destroy a brands reputation.
Just offer a discount on a yearly vs monthly subscription.
Tricking your customers and bullying them into paying for something they don't want is a sure fire way to destroy a brands reputation.
I work in oil / gas. I really think it depends on your customer base, and how often you release updates and new features (you used the word boring a lot). Is the product finished, and you just anticipate maintenance? Do you have regular feature updates?
Typically, most of the software I deal with has one of the following payment models:
1) buy outright, maintenance / support fee (code, phone, email), and usually can use the last version you paid outright for
2) rent the software monthly (license is through a server or usb dongle with expectation date) great for consultants. Starting to see this model a lot + on demand computing via aws or whatever "cloud" you want
3) some sort of academic or consulting price. In my industry, consultants tend to get a discount or a lower rate since consultants often influence software purchases at the companies they consult for
Can you elaborate on your customer base and the cost of your software? For instance, at a large organization buying multiple seats / subscriptions that will typically go through procurement and the customer with haggle with the vendor on cost and maintenance contract.
If your software is $1000 and used by a 20 person office, that can be charged on the company credit card without raising an eye brow.
Typically, most of the software I deal with has one of the following payment models:
1) buy outright, maintenance / support fee (code, phone, email), and usually can use the last version you paid outright for
2) rent the software monthly (license is through a server or usb dongle with expectation date) great for consultants. Starting to see this model a lot + on demand computing via aws or whatever "cloud" you want
3) some sort of academic or consulting price. In my industry, consultants tend to get a discount or a lower rate since consultants often influence software purchases at the companies they consult for
Can you elaborate on your customer base and the cost of your software? For instance, at a large organization buying multiple seats / subscriptions that will typically go through procurement and the customer with haggle with the vendor on cost and maintenance contract.
If your software is $1000 and used by a 20 person office, that can be charged on the company credit card without raising an eye brow.
I understand the need for subscription software. I would never push a developer to sell something with a one-time payment, especially if that software requires servers or will have future updates.
I like the idea of a monthly subscription. I've seen some apps where you can buy a lifetime subscription for the price of 2-3 years of monthly payments. That could be an interesting alternative for people who want to buy once.
I like the idea of a monthly subscription. I've seen some apps where you can buy a lifetime subscription for the price of 2-3 years of monthly payments. That could be an interesting alternative for people who want to buy once.
DynamoDB Serverless/on demand pricing is the best model in the universe imho. It’s sad so few companies rip that off. One of the best ideas AWS ever had, not proprietary at all: pay per millisecond & byte. Monthly subscriptions are annoying and don’t cover the long tail of diversity of customer usage patterns. Some folks use stuff exponentially more or less. A flat rate subscription just isn’t fair either way, and one-and-done upfront payments don’t cover ongoing maintenance and upkeep. The biggest benefit of Serverless, it’s the pricing. Don’t tunnel vision one-and-done vs subscription model and forget about on-demand autoscaling scale-to-nothing pricing. It’s a lot better for people just starting out on your product and incentivizes both sides in a win/win. Just wish more services (cough, databases) scaled to zero. No usage, no bill. High usage, high bill. Simple!
Doesn't this actively disincentivize people from using your software though? I'd expect the power-users of software to be the biggest source of grassroots marketing, and making them pay out the nose to use it seems like a pretty quick way to get them to quit.
I would be thinking about make ecosystem, where will be something central, may be even distributed for free, and have powerful api, to which hooked modules, which could be fixed price, or subscription.
For about policy, natural for people, to have similar to property. Mean, if you have property for a long time, you will got some additions which not included for new buyer, for example, Scottish property owners got Lord or Lady title, but if one just buy property, will not.
This remember me gamedev. Mean exists title "Game Designer", who mostly spend time in spreadsheets, computing game balance, for example, counting, if some achievement will add +10hp, how much will change gameplay, and even how much money will company pay to players for additional wins.
And yes, I spent lot of time on learn gamedev, we could talk about hire me, or for consulting, or just talk, if you interested.
For about policy, natural for people, to have similar to property. Mean, if you have property for a long time, you will got some additions which not included for new buyer, for example, Scottish property owners got Lord or Lady title, but if one just buy property, will not.
This remember me gamedev. Mean exists title "Game Designer", who mostly spend time in spreadsheets, computing game balance, for example, counting, if some achievement will add +10hp, how much will change gameplay, and even how much money will company pay to players for additional wins.
And yes, I spent lot of time on learn gamedev, we could talk about hire me, or for consulting, or just talk, if you interested.
And I must say, game companies - Sony, Nintendo, could teach "classic" developers lot about make money, how deep they engage customers.
And customers (mostly) happy, and it is really hard to find people who love play games and don't love at least one console.
And customers (mostly) happy, and it is really hard to find people who love play games and don't love at least one console.
Consider: (A) sell it once and customers own it forever, included in the price is (B) all updates for one year since date of purchase. This means customers don't have to wait for a new release, they can just buy whenever and receive a year of updates. If after the year of updates the new features are worthy of another purchase, they can buy again. Feel free to give discounts to customers from the past. This also means you're free to not release anything for a while if you want to take a vacation - there is no expectation that you must keep delivering new features.
While you could try to maximize the amount of money you earn, consider that for any amount of money you earn less than the maximum, it's value to your customers. Don't maximize, satisfice: figure out what is enough for yourself and be happy once you achieve that.
While you could try to maximize the amount of money you earn, consider that for any amount of money you earn less than the maximum, it's value to your customers. Don't maximize, satisfice: figure out what is enough for yourself and be happy once you achieve that.
My personal model for my commercial software: charityware - require a payment but made most proceeds go to my favorite (cost-effective) charity.
I'm getting about 100 purchases ($500/month, donating $350 of that) with my Video Hub App - https://videohubapp.com/ - which is also open source - https://github.com/whyboris/Video-Hub-App
I wrote about charityware a few years ago: https://medium.com/@whyboris/charityware-doing-good-with-pro...
I'm getting about 100 purchases ($500/month, donating $350 of that) with my Video Hub App - https://videohubapp.com/ - which is also open source - https://github.com/whyboris/Video-Hub-App
I wrote about charityware a few years ago: https://medium.com/@whyboris/charityware-doing-good-with-pro...
I'm curious about some things you said.
Under the disadvantages of 1, you say:
> II) you can't give customers what they want/need immediately even if they want to pay for it right now as you need a significant improvements for the next version.
That's true of subscription software, too. Developing any feature takes time, often a lot more time than you thought. It might be longer for the traditional model, but a feature that takes 2000 developer hours takes 2000 developer hours regardless of what your sales model is.
Under 2, you say:
> I)Everyone is on the newest version all the time
How do you figure? Just because you offer an update doesn't mean people will install it. In fact, many pieces of software I use on a daily basis are "don't update until current project is finished" status. It can be very disruptive to install an update mid-project, especially if something goes wrong and breaks.
It can also be really irritating. I remember reading that Valve releases something like 3 updates per week for Steam. I hate running Steam because it's always freaking updating and I have never seen an update that made any material difference to my use of the app. I literally can't tell anything has changed in most updates.
Under 3 you say:
> III)It's seems to be recipe for a situation where there are 100s of "current versions" people are running and that's very difficult to support.
I think that's going to be the case no matter which sales model you use. (Well, maybe not hundreds, but several versions.) Most businesses decide to support the last n versions. If you're on an older version, it's no longer supported and you either need to update or migrate to something else if there's a problem. This can be fairly reasonable if you support a wide enough range, but there's always the push and pull of what the company can afford to support vs. what users want supported.
Under the disadvantages of 1, you say:
> II) you can't give customers what they want/need immediately even if they want to pay for it right now as you need a significant improvements for the next version.
That's true of subscription software, too. Developing any feature takes time, often a lot more time than you thought. It might be longer for the traditional model, but a feature that takes 2000 developer hours takes 2000 developer hours regardless of what your sales model is.
Under 2, you say:
> I)Everyone is on the newest version all the time
How do you figure? Just because you offer an update doesn't mean people will install it. In fact, many pieces of software I use on a daily basis are "don't update until current project is finished" status. It can be very disruptive to install an update mid-project, especially if something goes wrong and breaks.
It can also be really irritating. I remember reading that Valve releases something like 3 updates per week for Steam. I hate running Steam because it's always freaking updating and I have never seen an update that made any material difference to my use of the app. I literally can't tell anything has changed in most updates.
Under 3 you say:
> III)It's seems to be recipe for a situation where there are 100s of "current versions" people are running and that's very difficult to support.
I think that's going to be the case no matter which sales model you use. (Well, maybe not hundreds, but several versions.) Most businesses decide to support the last n versions. If you're on an older version, it's no longer supported and you either need to update or migrate to something else if there's a problem. This can be fairly reasonable if you support a wide enough range, but there's always the push and pull of what the company can afford to support vs. what users want supported.
> That's true of subscription software, too. Developing any feature takes time, often a lot more time than you thought. It might be longer for the traditional model, but a feature that takes 2000 developer hours takes 2000 developer hours regardless of what your sales model is.
The OP means that in standard model you can't ship a feature even if you already spent 2000 hours and it's production ready if it's not big enough to justify new major release.
The OP means that in standard model you can't ship a feature even if you already spent 2000 hours and it's production ready if it's not big enough to justify new major release.
This is a very interesting problem - how to be fair to the users in case recurring business costs are zero or negligible.
Can you not support the newest version only? If anyone needs help then they would need to update. Some people could keep-up with subscriptions, other would stay with the outdated software that was good enough for them.
This would mean customers pay larger price once (for a "license" to own app X indefinitely) and then a smaller update fee every month/year (subscription) that is completely voluntary.
Do you have some custom file types or internal data that could have changed between versions and would be hard to migrate if someone decided later they needed support after all?
Can you not support the newest version only? If anyone needs help then they would need to update. Some people could keep-up with subscriptions, other would stay with the outdated software that was good enough for them.
This would mean customers pay larger price once (for a "license" to own app X indefinitely) and then a smaller update fee every month/year (subscription) that is completely voluntary.
Do you have some custom file types or internal data that could have changed between versions and would be hard to migrate if someone decided later they needed support after all?
If it’s B2B you need to go pure subscrition if the goal is to maximize revenue and minimize the risk of leaving unsupported customers. Business don’t really care about new features, they care about that the features they purchase keep on working ad infinitum. Also your existing customers will be as valuable as your new customers so you will focus on the product, not on trying to outcompete yourself with dubious new features just to justify a new relase until your product is so bloated nobody wants it.
If it is B2C you will have to go transactional or hybrid, but hybrid is very complex as your support costs can easily escalate
If it is B2C you will have to go transactional or hybrid, but hybrid is very complex as your support costs can easily escalate
If you have no server cost, then the jetbrains model might make sense. Otherwise despite the loud people on HN, the subscription is the only viable model. This is especially true if you serve a niche market.
I second this - the number of ill-informed loudmouths here making off-the-wall claims like "subscriptions are universally hated" boggle my mind
> > If you have no server cost
> We are selling standalone (...) software
They have no server costs. That's the principal part of their question.
> We are selling standalone (...) software
They have no server costs. That's the principal part of their question.
Simple. Offer both. Sell perpetual license that gives you 1 year worth of upgrades and offer subscriptions as well. Then each customer can choose whatever they like.
Personally for me I consider subscriptions a plague and unless there is absolutely no choice / substitution (which is luckily not the case yet) I would never pay subscription. Only perpetual license, though I do buy upgrades as well when I feel it's worthy.
Obviously excluded from the rule are services where subscription is a natural choice. Netflix for example.
Personally for me I consider subscriptions a plague and unless there is absolutely no choice / substitution (which is luckily not the case yet) I would never pay subscription. Only perpetual license, though I do buy upgrades as well when I feel it's worthy.
Obviously excluded from the rule are services where subscription is a natural choice. Netflix for example.
I would echo what others have said regarding the JetBrains model. For software that is valuable enough for me to pay for AND is something that I'm going to use regularly (which means it's gotta somehow be one of my daily drivers, typically a productivity or work or programming tool), I want the JetBrains model.
How do you market your software? Please let me know if you don't mind sharing. Thanks!
Remember to consider all aspects related to liability, terms of service, and so on, as it relates to security. Does your app connect to the Internet, network, or make use of user logins or similar information? If it does, you cannot just let customers keep using an old version forever and not get security updates. Keeping old versions secure will be costly for you, so you always want people on the current version.
"Standalone" in 2020s is not the same as the 90s. Subscriptions, while people may not like them, are a good solution for a host of less obvious problems.
How do you make a decision now so that you're not stuck in 5 years' time? Go with subscriptions and continuous updates and monitor whether customers really care. If your target market is business users then don't take the HN view on whether subscriptions are bad.
"Standalone" in 2020s is not the same as the 90s. Subscriptions, while people may not like them, are a good solution for a host of less obvious problems.
How do you make a decision now so that you're not stuck in 5 years' time? Go with subscriptions and continuous updates and monitor whether customers really care. If your target market is business users then don't take the HN view on whether subscriptions are bad.
Any concrete examples of liability being brought up against a developer?
The theory is one thing, the reality is another. Continuous updates are universally treated by developers as a carte blanche for any changes, including drastic reworking of the UI, refactoring established features and generally messing up user experience. So the resistance to this model is very real and well justified for that reason alone, without considering the subscription aspect of it.
* Besides, if a developer screwed up so badly that a patch is required, it's only fair and reasonable for that patch to be provided pro bono.
The theory is one thing, the reality is another. Continuous updates are universally treated by developers as a carte blanche for any changes, including drastic reworking of the UI, refactoring established features and generally messing up user experience. So the resistance to this model is very real and well justified for that reason alone, without considering the subscription aspect of it.
* Besides, if a developer screwed up so badly that a patch is required, it's only fair and reasonable for that patch to be provided pro bono.
>if a developer screwed up so badly that a patch is required
Required patching isn't necessarily due to a "developer screw[ed] up" - it's as likely to be that an upstream package has a discovered vulnerability, or something like the Intel fiasco from a few years ago, etc
Don't assign to illwill or incompetence what's more likely to be accidental, or ignorance
Required patching isn't necessarily due to a "developer screw[ed] up" - it's as likely to be that an upstream package has a discovered vulnerability, or something like the Intel fiasco from a few years ago, etc
Don't assign to illwill or incompetence what's more likely to be accidental, or ignorance
Intel case was an extreme exception.
Irrespective of the root cause, all critical issues are still ultimately on the developer and it's the developer who should absorb the costs. If they can't afford that or can't do it in a way that's not disruptive to the normal use of the software, then it's still their problem, not users.
Irrespective of the root cause, all critical issues are still ultimately on the developer and it's the developer who should absorb the costs. If they can't afford that or can't do it in a way that's not disruptive to the normal use of the software, then it's still their problem, not users.
you're not a dev, I see
... and you must be from sales.
lol
nope
but nice try (and thanks for admitting you don't understand the problem, and instead want to unilaterally blame someone else for something which likely wasn't their problem)
nope
but nice try (and thanks for admitting you don't understand the problem, and instead want to unilaterally blame someone else for something which likely wasn't their problem)
[deleted]
The model that is most fair to the vendor and their users is a perpetual license + termed upgrade/support coverage.
That is, users buy a license for currently available version and get, say, a year of support and upgrades. After a year they have an option of buying another year of upgrades or staying on their version.
That's it. As fair as it gets to all parties involved and it gives a lot of freedom to the vendor to release as they want.
Macrium is like this, Bvckup2 is like this, RamDisk is like this, etc.
On the other hand, if you really want to milk your users, subscription is a way to go, but it's universally hated. You will get a LOT of friction, goodwill will be non-existent and the word of the mouth will be near zero. So you'd better be sure your numbers add up.
That is, users buy a license for currently available version and get, say, a year of support and upgrades. After a year they have an option of buying another year of upgrades or staying on their version.
That's it. As fair as it gets to all parties involved and it gives a lot of freedom to the vendor to release as they want.
Macrium is like this, Bvckup2 is like this, RamDisk is like this, etc.
On the other hand, if you really want to milk your users, subscription is a way to go, but it's universally hated. You will get a LOT of friction, goodwill will be non-existent and the word of the mouth will be near zero. So you'd better be sure your numbers add up.
I find it funny whenever I read people say things like:
>if you really want to milk your users, subscription is a way to go
First, that someone would think a "subscription" is "milking" their users
Second, that it would be followed up by this extraordinarily false claim:
>it's universally hated. You will get a LOT of friction, goodwill will be non-existent and the word of the mouth will be near zero
Subscriptions are a fantastic model for many many things - for both customers and vendors
As a customer, I pay so long as I want to use a tool/get updates/etc
For a vendor, I get a consistent revenue stream to fund continued development, updates, etc
>if you really want to milk your users, subscription is a way to go
First, that someone would think a "subscription" is "milking" their users
Second, that it would be followed up by this extraordinarily false claim:
>it's universally hated. You will get a LOT of friction, goodwill will be non-existent and the word of the mouth will be near zero
Subscriptions are a fantastic model for many many things - for both customers and vendors
As a customer, I pay so long as I want to use a tool/get updates/etc
For a vendor, I get a consistent revenue stream to fund continued development, updates, etc
have you checked https://keygen.sh/, yoyll get ideas there
[deleted]
You can do classical model, plus feature pack sales; a la PC games before digital distribution.
I've written about this topic in more depth previously[0] (warning, it's long) and there is really no straightforward answer.
Now, I should note: I'm a YC Founder, so take my thoughts with a grain of salt. I've been "trained" by YC to think in terms of building businesses around raising VC funding and to scale quickly. (Software businesses tend to be very good at scaling compared to, for example, pure consulting where `$X = X Hours`. That doesn't mean you _have to_ scale though!)
Now, given that caveat, if you are looking to raise funding the future, then investors care a _lot_ about Monthly Recurring Revenue (MRR) which can be extrapolated into Annual Recurring Revenue (ARR). That means selling a subscription with a low churn rate ("sticky") so that you can make confident predictions about your growth.
That underpins why VC money exists: If you can demonstrate that buying $1 of Google Ads gives you $1 more in MRR, then you can run the math to show how quickly you can grow if you were to re-invest every dollar earned back into the business to reach some % of growth per month. (Imagine graphing something like `y = x` from algebra.)
By taking funding, you can "teleport" your growth to a future point of on your graph by buying more ads _now_ instead of waiting. This is the basis by which you calculate the value of your business (valuation) and how much % the investors get. Also, many business tend to benefit from "economies of scale" so your function might actually become `y = 2x` with more funding.
Now, if you're thinking about going that route, then I'd recommend trying to structure your pricing around MRR to make your life easier. (Even companies like JetBrains do this by selling "corporate license bundles" with a multi-year time frame and a minimum seat commitment.)
But if you're _not_ looking to raise VC money, then you can take a different approach like what you list up above.
That said, and this is probably the most important part of text here: Pricing is not the hardest part of building a business. Getting people to give a sh*t is the hardest part and that's best achieved by solving a real problem that they care about!
You can always undercharge and fix it later once you actually understand the business + sales side. Until then, focus on the product and, if you're looking to fundraise, go apply for YC's Winter 2023 batch[1]! (Do it ASAP for maximum odds)
Good luck and feel free to email me (see my profile). :)
0: https://www.lunasec.io/docs/blog/how-to-build-an-open-source...
1: https://www.ycombinator.com/apply/
Now, I should note: I'm a YC Founder, so take my thoughts with a grain of salt. I've been "trained" by YC to think in terms of building businesses around raising VC funding and to scale quickly. (Software businesses tend to be very good at scaling compared to, for example, pure consulting where `$X = X Hours`. That doesn't mean you _have to_ scale though!)
Now, given that caveat, if you are looking to raise funding the future, then investors care a _lot_ about Monthly Recurring Revenue (MRR) which can be extrapolated into Annual Recurring Revenue (ARR). That means selling a subscription with a low churn rate ("sticky") so that you can make confident predictions about your growth.
That underpins why VC money exists: If you can demonstrate that buying $1 of Google Ads gives you $1 more in MRR, then you can run the math to show how quickly you can grow if you were to re-invest every dollar earned back into the business to reach some % of growth per month. (Imagine graphing something like `y = x` from algebra.)
By taking funding, you can "teleport" your growth to a future point of on your graph by buying more ads _now_ instead of waiting. This is the basis by which you calculate the value of your business (valuation) and how much % the investors get. Also, many business tend to benefit from "economies of scale" so your function might actually become `y = 2x` with more funding.
Now, if you're thinking about going that route, then I'd recommend trying to structure your pricing around MRR to make your life easier. (Even companies like JetBrains do this by selling "corporate license bundles" with a multi-year time frame and a minimum seat commitment.)
But if you're _not_ looking to raise VC money, then you can take a different approach like what you list up above.
That said, and this is probably the most important part of text here: Pricing is not the hardest part of building a business. Getting people to give a sh*t is the hardest part and that's best achieved by solving a real problem that they care about!
You can always undercharge and fix it later once you actually understand the business + sales side. Until then, focus on the product and, if you're looking to fundraise, go apply for YC's Winter 2023 batch[1]! (Do it ASAP for maximum odds)
Good luck and feel free to email me (see my profile). :)
0: https://www.lunasec.io/docs/blog/how-to-build-an-open-source...
1: https://www.ycombinator.com/apply/
Please no subscriptions. They epitomize evil and rent-seeking.
Subscriptions for updates and support are fine, but desktop software should work perpetually. Subscriptions mainly make sense for time and money put into constantly changing data such as automotive repair software.
> They epitomize evil
What a very sheltered life you must have lived.
What a very sheltered life you must have lived.
We are selling standalone boring, mainly desktop (although it runs on beefier laptops as well) software. It's for Windows and written in boring technologies (C99 for the engine and C# for GUI). We are considering various business models when it comes to selling it in the future as our current one causes a lot of problems. Some options and thoughts I have about them right now:
1)What I call a "classical model" which we tried so far: release 1.0 version, sell it for a fixed price. Continue to support it for a while with bugfixes/features. At some point move to developing 2.0 version, sell it again (giving discounts for current 1.0 customers).
Advantages: simple, the customers can use software they purchased forever
Disadvantages: at some point you need to start collecting features/development for the next version. This means you will not be shipping new things for a while and "sit" on developments in house. This creates numerous problems, the most severe are: I)you are releasing all the new things at once making the release period hell as all the bugs/suggestions/problems hit you at one point in time and II) you can't give customers what they want/need immediately even if they want to pay for it right now as you need a significant improvements for the next version. III) You don't get quick feedback from the customers (only from testers which will always be less complete) about the things you are working on. It may turn out you have spent a few months working on something people don't really want or they want it in a different way.
2)Pure subscription.
Advantages: I)Everyone is on the newest version all the time II)Everyone can cancel/renew at any point III)Incentives aligned: developers can ship new stuff immediately, no reason to sit on new developments
Disadvantages: you can't purchase software and "own it". I like the idea that software once purchased can be run in 3-5-10 years from now and it's not developers' business when/how you choose to run it.
3)Some mix of the above. For example one time purchase and then subscription for updates.
Potential problems:
I)Difficult to determine what happens to people who cancel subscription (do they get the latest version at the time - that's difficult to support, what they need to pay if they renew in a few months?)
II)What happens when someone want to jump from subscription to one-time payment + updates?
III)It's seems to be recipe for a situation where there are 100s of "current versions" people are running and that's very difficult to support. It would be nice if everyone is on a newest one (or some ancient one that doesn't need support anymore).
It seems like it's very difficult to choose a business model that let people "own" the software but which also keeps incentives for the developers to ship new developments regularly. I guess that can be worked around with frequent release schedule (so you don't sit on stuff for too long) but that's very difficult to accomplish in a small development team.
I also think in case of various subscription/subscription hybrid ideas it's very important to be very clear about the policy towards people who cancel/want to renew after some time.
Any advice/suggestions are much appreciated!