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!
- 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.
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)
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.
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.
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.
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")
* 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
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."
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/
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.
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.
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.
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.
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 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.
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.
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.
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.
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 is B2C you will have to go transactional or hybrid, but hybrid is very complex as your support costs can easily escalate
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.
"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.
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.
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...