[HN Gopher] Ask HN: What's a good business model for selling sta...
___________________________________________________________________
Ask HN: What's a good business model for selling standalone
software?
Hello all! 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!
Author : bluecalm
Score : 39 points
Date : 2022-11-17 20:52 UTC (2 hours ago)
| badtension wrote:
| 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?
| potatopotat0 wrote:
| noob forgot ads
| zuhsetaqi wrote:
| 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."
| lcnPylGDnU4H9OF wrote:
| 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.
| TAForObvReasons wrote:
| > 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.
| cpburns2009 wrote:
| > 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...
| prirun wrote:
| 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.
| inasmuch wrote:
| 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.
| bombcar wrote:
| 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.
| [deleted]
| eps wrote:
| 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.
| ravenstine wrote:
| 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.
| leros wrote:
| 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.
| pianoben wrote:
| 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.
| yoyohello13 wrote:
| 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).
| spfzero wrote:
| 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.
| TAForObvReasons wrote:
| 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")
| bluecalm wrote:
| 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.
| kristopolous wrote:
| 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)
| digitalblade wrote:
| 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.
| sacrosancty wrote:
| jabbott1960 wrote:
| 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.
| pdntspa wrote:
| Please no subscriptions. They epitomize evil and rent-seeking.
| 1letterunixname wrote:
| 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.
| aussiesnack wrote:
| > They epitomize evil
|
| What a very sheltered life you must have lived.
| Sytten wrote:
| 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.
| antaviana wrote:
| 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
| samwillis wrote:
| 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.
___________________________________________________________________
(page generated 2022-11-17 23:00 UTC)