Ask HN: What's a good business model for selling standalone software?

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")

- 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.

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."

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.

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.

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.

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)

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?

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.

If it is B2C you will have to go transactional or hybrid, but hybrid is very complex as your support costs can easily escalate

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.

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.

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.

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.

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.

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.