Ask HN: How would you monetize software that runs mostly offline?
69 comments
Sell it like a normal product. This was the way commercial software worked for decades. They buy a license. They download it and register it while connected to the internet. They then take it offsite. Then, have an option to be paid to be on call for support when a meet is happening. That way nobody is surprised if something doesn't work.
Or it could be a subscription still. Like Slack for example who are also a desktop app on Electron* . The advantage with a subscription is you can charge less upfront, and you are being paid for your maintenance and bug-fixing time, rather than supporting a bunch of people who paid you $50 or whatever ten years ago and still expect updates and support.
* Yes they have a mobile and web interface too, but I mostly use the desktop app anyway.
* Yes they have a mobile and web interface too, but I mostly use the desktop app anyway.
I think this is the right answer... not sure why I was so resistive to it. Maybe its the hive mind :p
Thanks.
Thanks.
My father used to run HS & college track meets using a SW package he bought online. Same model - buy a license, get updates once/year. It works.
Yes, as the OP states they don't want to make a business out of it, a subscription model kind of ties you to ongoing maintenance. At least a straight sale can be fire and forget.
[deleted]
When you say normal product, do you mean users will have to buy the next version?
We should be responsible developers with the ability to patch insecurities in the software we sell. You're also going to have feature requests you'd like to publish to your users. As a sole developer one evergreen version seems much easier to maintain for both these concerns. And I think a subscription model or some recurring payment model makes more sense both for you and your users. Explaining this to your users maybe difficult, but if they actually find a product useful they should want the developer behind it to be able to support it.
We should be responsible developers with the ability to patch insecurities in the software we sell. You're also going to have feature requests you'd like to publish to your users. As a sole developer one evergreen version seems much easier to maintain for both these concerns. And I think a subscription model or some recurring payment model makes more sense both for you and your users. Explaining this to your users maybe difficult, but if they actually find a product useful they should want the developer behind it to be able to support it.
Sure, patch your software, but you can keep accumulated feature requests on a separate branch. Then, as time goes on, decide whether you should rather monetize on an updated and more feature rich version, or just push updates and make people happy. I'd say there is more money in the first option, while the second makes me feel better. It's the developer's choice. Check https://www.holdemmanager.com/ how they do it.
For OP's kind of software, I'd say one time license purchase would be the most user friendly. So yeah, sell it like people did in the good old days, before the cancer that is SaaS took over the world.
For OP's kind of software, I'd say one time license purchase would be the most user friendly. So yeah, sell it like people did in the good old days, before the cancer that is SaaS took over the world.
How many insecurities are there going to be in software that doesn't connect to the internet or process input from untrusted users?
> How many insecurities are there going to be in software that doesn't connect to the internet or process input from untrusted users?
In principle there are ways this can be exploited, though I know the poster's application is likely a less interesting attack vector than uranium centrifuges (e.g., https://en.wikipedia.org/wiki/Stuxnet).
But there may still be user-facing bugs that would require fixing.
In principle there are ways this can be exploited, though I know the poster's application is likely a less interesting attack vector than uranium centrifuges (e.g., https://en.wikipedia.org/wiki/Stuxnet).
But there may still be user-facing bugs that would require fixing.
It's an electron app, what more could you ask for?
Do a normal product with a time-based license key.
Results are read-only without a valid key. Don't encrypt the data as it will irritate all your users. People will want to review results during the event, if only to verify that it was correct. Or contest results a few days later. In races, people are sometimes disqualified even months later - I don't know about weightlifting.
On the other hand, new input/modifications require a valid key.
Keys are renewed either automatically (with an online license check / renewing payment) or through an online purchase which returns a license key to input.
You can have a start/end date to the license to bracket the event, with a few days/weeks on either side for flexibility.
Note: I've never done anything like this; these are proposal only.
Results are read-only without a valid key. Don't encrypt the data as it will irritate all your users. People will want to review results during the event, if only to verify that it was correct. Or contest results a few days later. In races, people are sometimes disqualified even months later - I don't know about weightlifting.
On the other hand, new input/modifications require a valid key.
Keys are renewed either automatically (with an online license check / renewing payment) or through an online purchase which returns a license key to input.
You can have a start/end date to the license to bracket the event, with a few days/weeks on either side for flexibility.
Note: I've never done anything like this; these are proposal only.
JetBrains style - pay for a license to use the software forever, and get a year's worth of updates. Buy a new licence after a year if they want the next update. Maybe offer a discount for renewal.
In case it's not common knowledge, make sure license key requires a server-side verification.
Maybe. One of the primary advantages of offline software is that it can be used offline. If you're going to require people to connect to your server you might as well make it a web app.
To be fair, it's not really all or nothing like that, but remember that offline software is already a niche market. Is it better to go half-way into a niche market, or all the way? In other words, your users likely chose your software over the dozens of online offerings because it is an offline app, and then the very first thing you do is make them connect to your server.
Although, I don't see any downsides of doing server-side verification if there is a network connection available, it would be nice if offline software could work on a computer that was offline.
I'm working on a side-project that I may sell as offline software. One of my marketing claims will be that the users own the software forever. They wont experience a "UI upgrade" that makes things worse, and if I go out of business their software will still work for decades or longer. I cannot honestly make that claim if I require server-side verification. I'm betting that my niche users will care about this; if not I have no product because there are dozens of online competitors.
To be fair, it's not really all or nothing like that, but remember that offline software is already a niche market. Is it better to go half-way into a niche market, or all the way? In other words, your users likely chose your software over the dozens of online offerings because it is an offline app, and then the very first thing you do is make them connect to your server.
Although, I don't see any downsides of doing server-side verification if there is a network connection available, it would be nice if offline software could work on a computer that was offline.
I'm working on a side-project that I may sell as offline software. One of my marketing claims will be that the users own the software forever. They wont experience a "UI upgrade" that makes things worse, and if I go out of business their software will still work for decades or longer. I cannot honestly make that claim if I require server-side verification. I'm betting that my niche users will care about this; if not I have no product because there are dozens of online competitors.
While it's becoming rarer, it's worth noting that not all targets are going to have an internet connection. For example, in a typical large enterprise, not all servers will have internet access (neither directly or through proxy) for security reasons.
I won't link them here, but JetBrains has been struggling with many pirate license servers. Apparently those required a lot less effort to do than cracking traditional product keys.
Wait, if you JetBrains license expires, you can still use the product without receiving updates? I thought it would allow a grace period like the demos and then refuse to work.
Yeah, it keeps working. It's great. I paid for my license last year, in a year or two if it starts to feel buggy I'll pay again. I'm very happy with their software, it's made me a lot of money in productivity gained.
I wrote an electron app and I just charge per license.
It's an Apache Parquet format viewer https://www.parquetviewer.com
I've actually specified that a single license is per a single user but can be installed on multiple machines. I've had several users request this.
I've actually specified that a single license is per a single user but can be installed on multiple machines. I've had several users request this.
How are u managing piracy? With a same username or license - can the software be used by many people? Or you can lock some license remotely?
Genuine question - why an electron app and not an iPad app (or even iOS/android app) ?
Is there a massive amount of data entry that is not suited for an iPad or phone(iOS/android) ?
Given the fact that you can probably record the video of the lift using the device camera, plus a few more obvious advantages...wouldn't it be better to do it this way ?
Plus your distribution+billing is also sorted (using the Play Store/App Store).
Is there a massive amount of data entry that is not suited for an iPad or phone(iOS/android) ?
Given the fact that you can probably record the video of the lift using the device camera, plus a few more obvious advantages...wouldn't it be better to do it this way ?
Plus your distribution+billing is also sorted (using the Play Store/App Store).
The people that would be using it arent really the ios/ipad type... its hard to explain without sounding like Im stereotyping.
I really recommend you do customer discovery here (just like what YC would teach you). Given the number of lifters who are Instagram savvy, I think you might be surprised.
If you do a ipad version, remember you can make it keyboard friendly, so even that reason is out.
I can think of more and more things that are only possible in the mobile version - bar code/QR code scanner (in case you are selling tickets to the event), livestreaming to YouTube/Instagram, etc
If you do a ipad version, remember you can make it keyboard friendly, so even that reason is out.
I can think of more and more things that are only possible in the mobile version - bar code/QR code scanner (in case you are selling tickets to the event), livestreaming to YouTube/Instagram, etc
Encrypting results seems indistinguishable from holding the customer's data hostage. That's not a great place to be, especially if an event is in Outer Qlyphm and the participants want their results now, not when the caravan returns from civilization.
Just charge for the software, provide a download link, and have a simple activation step. Most of your users are not going to be technically capable of bypassing even a very simple registration system. And if they are, it will be very difficult to win that arms race without alienating your honest customers and destroying your product's reputation.
Choosing a good price and treating the customer fairly are the most effective anti-piracy measures you can take.
Just charge for the software, provide a download link, and have a simple activation step. Most of your users are not going to be technically capable of bypassing even a very simple registration system. And if they are, it will be very difficult to win that arms race without alienating your honest customers and destroying your product's reputation.
Choosing a good price and treating the customer fairly are the most effective anti-piracy measures you can take.
>your users are not going to be technically capable
Did you just assume weightlifters aren't technically capable?
Did you just assume weightlifters aren't technically capable?
Er, no. Just assuming that weightlifters are a representative sample of the general population. There will, of course, be exceptions to this due to geographies and special-interesting groups ("The Usenix Lambda Lifting Association?").
Also not assuming that weightlifters are the same as the folks running the events. In my experience the people who run events just want software that works, and are unimpressed with packages with elaborate and fragile DRM systems that can fail in the middle of a conference. Laptops fail or are stolen, and recovery from thumb drives and "somebody drive find a Starbucks and get those files from Dropbox" are often done with the clock ticking and the crowd getting restless.
Also not assuming that weightlifters are the same as the folks running the events. In my experience the people who run events just want software that works, and are unimpressed with packages with elaborate and fragile DRM systems that can fail in the middle of a conference. Laptops fail or are stolen, and recovery from thumb drives and "somebody drive find a Starbucks and get those files from Dropbox" are often done with the clock ticking and the crowd getting restless.
This guy gets its. The software already available is a headache to use and the goal here is to "get out of the users way", so they can focus on running the meet instead of fighting the software.
Assume all users are not technically capable
That was taken wildly out of context....
Sell keys. Why are you trying to make this complicated? Don't encrypt the user's data and hold it for ransom, that's just insane.
You could also just release it as shareware. Especially if you're writing this because you take part in this kind of event and have gotten a lot out of the general weightlifting community; now you're giving something back. Have a splash screen asking people to send you some money (maybe with a suggested donation) or a note with their thanks.
You could also just release it as shareware. Especially if you're writing this because you take part in this kind of event and have gotten a lot out of the general weightlifting community; now you're giving something back. Have a splash screen asking people to send you some money (maybe with a suggested donation) or a note with their thanks.
You can't monetize it without it being a business. So accept that and manage it like a business; decide how much time you want to devote to it and what are acceptable revenues to justify the time you are giving it.
Look at different business models and pick the one that works for you. If you want to hang ads on it, do that. If you want to work with the certifying authority for the sport and have the sports association pay you a yearly fee to provide the software to all official events, start investigating if that's possible. If event promoters find value in the software figure out what they are willing to pay for it and sell them licenses ( yearly, per event, lifetime, whatever works ).
Don't half-ass it by thinking you aren't in business, fully ass it by making it _your_ business.
Look at different business models and pick the one that works for you. If you want to hang ads on it, do that. If you want to work with the certifying authority for the sport and have the sports association pay you a yearly fee to provide the software to all official events, start investigating if that's possible. If event promoters find value in the software figure out what they are willing to pay for it and sell them licenses ( yearly, per event, lifetime, whatever works ).
Don't half-ass it by thinking you aren't in business, fully ass it by making it _your_ business.
Try to make an online portion that is subscription provides all the value.
Use the electron portion as an offline data collector for the web app.
Once the event is over the electron app uploads the data to the web app where they interact with it, share it etc.
Then you can handle your subscriptions through the web application.
Use the electron portion as an offline data collector for the web app.
Once the event is over the electron app uploads the data to the web app where they interact with it, share it etc.
Then you can handle your subscriptions through the web application.
I completely agree with all the comments that suggest a time-based licensed or paying per major version/updates. But have a small suggestion.
In addition to offline functionality, can there be any type of online functionality built-in as a convenience? I’m thinking automatic backups when an event ends, sharing results to a portal for competitors to log into later, etc.
If there is, you can use a hybrid model and offer those as a subscription with a fixed license or (depending on price) a more expensive monthly that will bundle the fixed license.
Good luck!
In addition to offline functionality, can there be any type of online functionality built-in as a convenience? I’m thinking automatic backups when an event ends, sharing results to a portal for competitors to log into later, etc.
If there is, you can use a hybrid model and offer those as a subscription with a fixed license or (depending on price) a more expensive monthly that will bundle the fixed license.
Good luck!
Yes, definately it will do those things. But it also needs to be 100% capable of running a meet offline.
If it were me (and you asked how I would do it) I would make the program open source and give it away. I would then build revenue around 1) Accepting donations, 2) selling custom feature development/consulting, 3) Selling additional products and services related to weightlifting.
You said that you have no interest in building a business out of it, so maybe you could just work with donations and maybe occasional feature request bounties.
You said that you have no interest in building a business out of it, so maybe you could just work with donations and maybe occasional feature request bounties.
Yeah, this approach is still on the table. Id just like to recoup my time _somehow_... even if monetization wasnt the original intent.
Hey, I’m working on a similar product for a different type of fitness competition. Email is in my profile if you’d like to catch up and compare notes.
> weightlifting events are rarely held at locations with internet.
Really? Even mobile networks? Are you familiar with floarena? Seems like a similar idea for wrestling events and it works great online -- allows people both at the event and remote to follow what's going on...
Really? Even mobile networks? Are you familiar with floarena? Seems like a similar idea for wrestling events and it works great online -- allows people both at the event and remote to follow what's going on...
Yeah, but its a poor pitch to say, "Oh, no internet? Just use your phones mobile hotspot." Existing solutions run entirely offline and I need to replicate that experience to get any initial usage of the app... at least outside of my contacts.
Sure, but your monetization strategy could still be tied to online access/community/etc. -- in other words, you could provide the software to keep track of the event offline for free, but have it connect to a website where people can see results live (when the event supports it), search historical results, and even watch video of the event for a fee (again, if the event supports it).
I should think a standard license key should be fine.
Sublime Text isn’t a bad model.
Sublime Text isn’t a bad model.
I'm writing an Electron app too:
https://getpolarized.io/
We're pretty far ahead so you could probably look at the source code repo if you want to look for ideas.
Anyway.
Do this...
Create a public/private key pair. Require the user to enter a 'key'. The key is just ascii armoured encrypted data from the private key. Just make sure the key validates.
They're competitive body builders not alpha hackers. Just obscure it in some way and you're probably good.
This system works offline too since you distribute the public key with the app.
The ASAR stuff in Electron has some obfuscation related framework but I haven't looked at it much.
https://getpolarized.io/
We're pretty far ahead so you could probably look at the source code repo if you want to look for ideas.
Anyway.
Do this...
Create a public/private key pair. Require the user to enter a 'key'. The key is just ascii armoured encrypted data from the private key. Just make sure the key validates.
They're competitive body builders not alpha hackers. Just obscure it in some way and you're probably good.
This system works offline too since you distribute the public key with the app.
The ASAR stuff in Electron has some obfuscation related framework but I haven't looked at it much.
Related: I recently wrote an article about license key generation and validation. The code examples are in Python, but are equally applicable in JS: https://build-system.fman.io/generating-license-keys
I'm a bodybuilder and an alpha hacker. There are more of us than you'd think.
> The user would then need to connect to the internet after the competition, log in, pay, and then could get their decrypted competition results.
Can you rely on them eventually connecting to the internet after the competition?
Can you add a cloud component that stores and shares the results online that they'd want to access?
Is it important to encrypt the local results? I would worry about getting successful first before wasting even a small amount of time on copy protection. People that are going to burn their own time breaking copy protection and risk legal consequences for the sake of a few $100 are unlikely to ever be your customers anyway.
Can you rely on them eventually connecting to the internet after the competition?
Can you add a cloud component that stores and shares the results online that they'd want to access?
Is it important to encrypt the local results? I would worry about getting successful first before wasting even a small amount of time on copy protection. People that are going to burn their own time breaking copy protection and risk legal consequences for the sake of a few $100 are unlikely to ever be your customers anyway.
> So far my idea is to encrypt the results of the competition after it is complete. The user would then need to connect to the internet after the competition, log in, pay, and then could get their decrypted competition results. Alternatively, I could just sell it like a normal product, $x/per download...
This would be so annoying for customers. I'm sure your customers will not expect this to happen no matter how many warnings you so and when it does, they'll be furious that you let them use it first and then locked in their data forcing them to pay.
Why not make it a subscription and make the app lock down if it cannot contact your server to verify its subscription key let's say every week or so. Most traditional desktop apps followed this model. It can also let you charge them based on the usage or volume of data so you can have subscription plans. Of course people talented and inclined enough can find ways around it but I wouldn't worry about that as much.
This would be so annoying for customers. I'm sure your customers will not expect this to happen no matter how many warnings you so and when it does, they'll be furious that you let them use it first and then locked in their data forcing them to pay.
Why not make it a subscription and make the app lock down if it cannot contact your server to verify its subscription key let's say every week or so. Most traditional desktop apps followed this model. It can also let you charge them based on the usage or volume of data so you can have subscription plans. Of course people talented and inclined enough can find ways around it but I wouldn't worry about that as much.
In addition to the choices already offered (just give it away or sell it like any conventional piece of software): I would favor your choice of seeing the results.
But don't encrypt the results -- what's the incentive to use the app then? Instead provide value to any user (it collects and saves the results locally), but for a subscription the data collector could upload the results.
Then you have a choice: does the event holder or the competitor (or both) pay to see the results? The fact that you collect them means competitors who compete in different events can see all their results, view leaderboards and the like. You could pretty well automate all that so your involvement would be minimal. I don't understand your domain but without prior knowledge I would think it would be easier to charge the contest holder.
Your model might be something like Strava.
But don't encrypt the results -- what's the incentive to use the app then? Instead provide value to any user (it collects and saves the results locally), but for a subscription the data collector could upload the results.
Then you have a choice: does the event holder or the competitor (or both) pay to see the results? The fact that you collect them means competitors who compete in different events can see all their results, view leaderboards and the like. You could pretty well automate all that so your involvement would be minimal. I don't understand your domain but without prior knowledge I would think it would be easier to charge the contest holder.
Your model might be something like Strava.
I created two weightlifting iOS apps - Lift Log and FitnessAI.
- Lift Log is a weightlifting journal that doesn't have any cloud functionality. It's been free for years, and I recently paywalled it at 7.99/mo or 59.99/yr (for all new and existing users). I received an incredible amount of backlash, but in the end it was worth it.
- FitnessAI uses all the data that Lift Log users generate to power an AI weightlifting coach. I charge 9.99/mo or 59.99/yr for that one with little pushback from users.
At the end of the day, you are affording your continued time and effort to maintaining your app, which is why I think a subscription model is fair.
Its not like we're writing books where all the user gets is v1.
They get v1-Infinity.
Its very easy to undervalue your work, don't!
And remember, you can always give anyone who asks free access, since you have unlimited supply :) Thats what I do for Lift Log.
Feel free to PM me if you want to talk more!
jakemny gmail com
- Lift Log is a weightlifting journal that doesn't have any cloud functionality. It's been free for years, and I recently paywalled it at 7.99/mo or 59.99/yr (for all new and existing users). I received an incredible amount of backlash, but in the end it was worth it.
- FitnessAI uses all the data that Lift Log users generate to power an AI weightlifting coach. I charge 9.99/mo or 59.99/yr for that one with little pushback from users.
At the end of the day, you are affording your continued time and effort to maintaining your app, which is why I think a subscription model is fair.
Its not like we're writing books where all the user gets is v1.
They get v1-Infinity.
Its very easy to undervalue your work, don't!
And remember, you can always give anyone who asks free access, since you have unlimited supply :) Thats what I do for Lift Log.
Feel free to PM me if you want to talk more!
jakemny gmail com
I created Video Hub App - https://videohubapp.com/ (Electron app)
I sell per download for $3.50 minimum (users can pay more if they would like). It was released last year around the same time and now has 473 copies sold. Late last year I made it open source: https://github.com/whyboris/Video-Hub-App
Unsure if anything I shared is valuable to your situation. I chose against using licenses / serial numbers / etc - fewer headaches. Makes the user experience better I suppose.
I sell per download for $3.50 minimum (users can pay more if they would like). It was released last year around the same time and now has 473 copies sold. Late last year I made it open source: https://github.com/whyboris/Video-Hub-App
Unsure if anything I shared is valuable to your situation. I chose against using licenses / serial numbers / etc - fewer headaches. Makes the user experience better I suppose.
How about the Sketch model: a license buys you perpetual use plus one year of updates. If you want further updates you can pay again to refresh the license.
What companies are trying to build mindshare among weightlifters and their coaches? ESPN for competition TV shows? Companies that make weightlifting gear, clothes, training products? Reach out and white label the product so they can pay you an annual maintenance contract, you stick their brand on it, they promote it and distribute it for free. One transaction per year so no licensing systems required.
I would venture selling the application would be your best bet.
The idea of having to login to see the results, is frustrating.
If you are looking to do pay per model, you could sell usage credits, and have them buy them before hand, or require to purchase one to see the results?
Additionally you could do a split functional option, with basic free functionality always available, and then enhanced functionality available only when connected.
The idea of having to login to see the results, is frustrating.
If you are looking to do pay per model, you could sell usage credits, and have them buy them before hand, or require to purchase one to see the results?
Additionally you could do a split functional option, with basic free functionality always available, and then enhanced functionality available only when connected.
Subscription, not permanent license. You do not want to maintain more than one version, the latest one.
Generous trial. It will help with distribution.
Implement some way to upload competition results to YOUR results server. Make it easy to navigate. If traffic deserves it add some relevant ads.
Generous trial. It will help with distribution.
Implement some way to upload competition results to YOUR results server. Make it easy to navigate. If traffic deserves it add some relevant ads.
I'd be thinking about the next version. How could that next version be leveraged to require an always connected model? E.g. is there an iOS version that needs cloud sync or is it possible to generate a subscription model?
IMO, non-techies are generally in tune and generally accept that there should be an iOS app for the software and aren't adverse to sub models given the plethora of other things they do. In fact, some might see it as a negative for the tool to not be iOS based and have cloud-type presence.
IMO, non-techies are generally in tune and generally accept that there should be an iOS app for the software and aren't adverse to sub models given the plethora of other things they do. In fact, some might see it as a negative for the tool to not be iOS based and have cloud-type presence.
How about those dongles with a license key, you can make it USB. Free download of software then you need the dongle to run it.
Have it run on an iPad and you can do iOS subscriptions that work fine offline.
Charge money + 25% maintenance annually.
Unless you offer phone support and an SLA, 20% is much more common.
It used to be.
Customers failure to fight subscriptions made everyone realize that you can extract much more money from them. Back in the day, only big vendors like Microsoft got away with wacky high maintenance percentages.
I see even little vertical vendors come in with 30-35% proposals all of the time lately.
Customers failure to fight subscriptions made everyone realize that you can extract much more money from them. Back in the day, only big vendors like Microsoft got away with wacky high maintenance percentages.
I see even little vertical vendors come in with 30-35% proposals all of the time lately.
B2B sales! Message me if you want to chat further
build in an auto-update mechanism
License it
Licence it
TL;DR:
Sell it per download.
Why?
If it is to be run in areas that rarely have access to the internet, then your target market isn't probably interested in buying a license or any thing that even remotely makes the app hard to use.
Go easy on your customers. From the moment they visit your website to the moment they have the app up and running should not take more than 3 clicks. Just my 2 cents.
Sell it per download.
Why?
If it is to be run in areas that rarely have access to the internet, then your target market isn't probably interested in buying a license or any thing that even remotely makes the app hard to use.
Go easy on your customers. From the moment they visit your website to the moment they have the app up and running should not take more than 3 clicks. Just my 2 cents.
Normally this would be relatively easy... just have a subscription model for $x/mo and move on. But the weightlifting events are rarely held at locations with internet. So the software is written to 100% functional offline... but Im having trouble thinking of a way of monetizing it.
So far my idea is to encrypt the results of the competition after it is complete. The user would then need to connect to the internet after the competition, log in, pay, and then could get their decrypted competition results. Alternatively, I could just sell it like a normal product, $x/per download...
That all feels so obtuse though... Id love any feedback, better ideas, or discussion.