I did ask the same question in 2016 [1] and got some really interesting answers.
I'm still chasing the dream of having a side-business and earning some side money, but with web apps it means mostly SaaS. Personally I hate rent-seeking behaviors (I'm not alone, it seems - "Tell HN: A Conversation Needs to Be Had over Subscription Software" [2]), so I'm trying to know what people are doing regarding desktop apps.
Are people still building desktop apps? More specifically, can you make a living (or earn some side money) in 2022 by selling a desktop app? Please share it with us, or are we doomed to build web apps and SaaS for the foreseeable future?
Although .Net went multiplatform years ago, my app relies on WinForms a lot so it's Win only, except through Wine. I would love to support Mac as well but the only realistic option looks to be Electron based, and it would be a significant step back for my Windows users. Maintaining two different GUIs looks like a problem for micro company.
The best thing about desktop software is it can't break for all the users at once like server-based app can. That gives some piece of mind when you're micropreneur. Sure, there are bugs, but they affect only users who downloaded buggy version. You can't crash all installed instances just like that.
The worst thing is, it's hard to ask for a subscription. Yes, I hate it as a user, but would love it as a business owner :)
https://www.cogin.com
We also have major upgrades which do bring in some more cash since they're more expensive and more users buy them. But it's every 5-6 years. And it's still significantly lower than regular new licenses.
I'm thinking about adding a Saas "Team" edition, which would offer centralized management of users, connections they use, permissions, with some auditing etc. First problem is we would have to store some sensitive data (connections) which gives me a security scare. Second problem is we'll introduce central point of failure which gives me another kind of scare. And very soon we'd have different versions of client software running on end users machines which should all work correctly with a server. That's a third scare, a versioning one.
WiseJ is a drop-in replacement for WinForms apps, to make those run in a browser.
The WiseJ 2.5 is yet on .NET 4.8, but the new WiseJ 3, planned for March, is running on .NET Core.
The key features for me are: (1) all the wiring is hidden, so no need do not deal with Javascript. All processing is done in server. (2) Refreshing the browser by pressing F5 keeps user's session. (3) Background tasks work seamlessly with UI updates. (4) Can use System.Drawing.
It is a paid library, but very reasonable price.
That's not a bad thing. My company pays quite a bit of money for various libraries and if we notice a bug in any of them, we report it and it's usually fixed within 4-6 weeks in a new release.
There is no discussion with 5 people chiming in and you don't need to follow up constantly. Report it once, answer maybe one or two questions on how to reproduce it, and even very complex bugs will be gone.
I know that there are a lot of well maintained free projects but being able to write a report and to be guaranteed an answer back on the very next day is very calming when you have customers waiting.
https://github.com/dotnet/maui
Also, it's hard to bet on a new MS GUI framework, when they released and abandoned several in the last decade. Will it be supported in 5 years as a minimum? Yes, Winforms looks outdated, but it still builds and works as it did back in 2005.
One more thing, I'm not using vanilla Winforms but also excellent DevExpress controls. For example Winforms has a grid, but DevExpress grid is highly customizable, works ok with 100k rows, has filtering, sorting, etc. It's not only about base GUI framework, it's also about entire ecosystem of GUI controls. And maturity of these controls. E.g. Devexpress has MAUI grid, but I don't expect is to be as mature as winforms one.
I'm not saying that MAUI couldn't be useful for some cases. Even many cases. It's just not yet ready for my kind of software.
https://venturebeat.com/2021/11/22/conduktor-which-brings-a-...
If anything, it's a testament to what an absolute pain it is to develop on existing message queue/event streaming platforms, so it's clearly a valid niche.
We have a desktop app that processes DICOM data to do implant treatment planning (where to place an implant in the patient jaw). Output is a STL file to print a drill guide for the oral surgeon to perform a guided surgery.
Our desktop scanners for dental labs and our intra-oral scanners for dentists generate 3D meshes of the patients oral situation.
Those meshes are the input data for the CAD/CAM Software my team builds. It is a desktop app for the digital design of dental restorations. The GUI is in javaFX and 3D visualization is done with OpenGL 4.5.
Once the restorative Design is done, that app can generate many different output formats. Labs will feed the design files their local milling machine or 3D printer. Dentists can send it to centralized milling facilities of their choice to produce the crown or bridge or what have you.
Some impressions can be seen here:
https://youtu.be/5THQMr5SAH0
Your observations is spot on:
Indeed, the environment is far from ideal. 2-3 years ago dentists had to apply a powder onto the patients teeth to make just the scan of the teeth work. Now the software has matured to work powderless. The scan has to work for a wide variety of surfaces and vis-a-vis refractive indices like teeth, metal implants, ceramic or gold inlays, gingiva, orthodontic engagers. The very high end models even detect tooth decay / caries.
The stitching is another challenge. Again, in the past the scanner would loose his reference on the mouth and it was fiddly to get it back to continue from the last scanned part. The team working on this was brilliant to overcome this problem and now it is a smooth experience
Finally, accuracy is something all devices on the market having a hard time with. They are operating on the limit of what is possible. Small partial scans are no problem. But when you scan a full arch, you must ensure the deviation does not exceed 30-50 microns over that full arch. Otherwise, if the dentist plans to do a big bridge that spans several teeth a lower accuracy will lead to miniscule deviations and twists in the designed and later produced bridge, that the patient will recognize it and feels that it "just does not fit right".
Our mouth is super sensitive in this regard because of the high number of nerves/sensors. Our tongue operates like a magnifying glass. When you have a small hair in your mouth or between your teeth you will feel that right away.
Damn, you weren't kidding - https://www.youtube.com/watch?v=AA4IWd3Svm0
Very impressive indeed. Looks effortless and natural, but I'm sure that the processing engine is not exactly trivial.
Any chance you could enlighten me?
p.s. the drill guide arrived, the implants go in next week!
For the latter you then also need the intra-oral scan. The output of the IO scanner is a simple (but massive) 3D point cloud. The software then is meshing those points on the fly. Using the color information from the IO scanners camera, shaders are added to generate the right texture for teeth, gingiva, etc.
We have a module in the CAD Software that allows to Integrate the surgical and prosthetic workflows through real-time case data sharing between coDiagnostiX and DWOS CAD. The Real-time (or asynchronous) connectivity between lab technicians and implant-placing dentists enables better prosthetically-driven implant planning and immediate provisional design.
On a personal note, don't be afraid of the procedure. With those drill guides and today's planning solutions we made leaps in implantology. In the beginning the surgeons did it by hand and feeling. I shudder at the thought.
Reading your comment made me really happy. As a dev I am always excited to have contact with our customers. Other hate it, but I love giving 3rd level support.
We had a team that also build Lab management software but overtime we painfully became aware that an integrated billing service is a maintenance nightmare with yearly changes to tax laws, the myriad of different health care providers/insurance companies ever changing what treatments they subsidize to which extend on an monthly or even weekly basis. Multiply that with all the different countries we operate in, it became unsustainable.
So again, kudos to your father to prevail in this space.
The tech stack for this app is really interesting (to me at least, natch). Lots of native node modules that need finesse on both macOS and Windows. I don't yet support Linux because out of thousands of users, only 2 people have emailed about Linux support (probably both from HN!).
I really love building Electron apps. It's a total joy bringing something (albeit "inefficiently" wrt memory and "native" qualities) like this to market for a niche that's otherwise a dumpster fire of old and clunky 1980s-era Windows-only software.
As for licensing, Label LIVE is licensed per computer. I wrote a custom license implementation leveraging JWT. The JWT is signed by my license server and the app verifies the signature and that the contents match the "fingerprint" of the computer being licensed, expiration, etc.
I'm a little surprised to read this from an Electron dev. I remember reading old forum posts about how the Spotify port for Linux was arranged by two devs who met after work for a few hours and got it working well enough that Spotify let them release it as an unsupported client. There was one or two issues that had to do with importing local music, but besides that it ran perfectly fine. You're of course welcome to do whatever you want, but if your runtime is essentially a web browser, I doubt there's going to be much trouble getting it to work on Linux. But what do I know, I don't make a living off of printing labels...
> It's a total joy bringing something like this to market for a niche that's otherwise a dumpster fire of old and clunky 1980s-era Windows-only software.
Here's my grumpy old man take: I kinda prefer the clunky Delphi forms of yesteryear. No, they weren't very pretty, but they were stable and performant enough that if you bought a license, you could guarantee that it would run forever. There was a special kind of feeling of ownership with that software, because it really felt like it was tangible and "yours". I don't think any Electron app has ever made me feel that way; at best it's a begrudging relationship with software I need for work, at worst it's one update away from being changed enough that I want the old version back. Again, take this with a grain of salt, I don't know your heuristics here.
Second, auto-update is disabled by default because I don't want a dumb bug on my side to break someone's "it just works" printing system.
IIRC, Spotify "unofficial-but-official" client largely predates the Electron version and this story is from the Qt era of Spotify (which was wonderfully light and fast).
Deleted Comment
Managing 10+ levels of JS promise chains can be a chore if not architected and named properly. Or worse, when you write a feature that’s close to the user and realize it requires asynch all the way back up through 10+ sync calls so now it’s refactoring across 30 files and you forget one edge case that doesn’t resolve/throw and it takes days to track it down. Normal solo project problems.
Integrating fabricJS with a custom wasm module to dither images. That was a 10x speed improvement but took a few hundred hours.
Early on I chose react/flow/redux/immutable/semantic-UI as my front-end “stack” and it’s been mostly good to me. Of course, I wish my codebase was all perfect typescript but eventually I’ll get there.
The node ABI changes over the years has really stressed me out. It seems like it breaks all the native code every 3 months. Ugh!
Customer support has been delightful. Out of a few thousand emails only 2 or 3 have been awful. Sometimes I’ll get an email at 2pm on a Sunday saying “I have to print 5,000 labels by Monday morning or else I’m fired!” and we are always successful. That feels good. The toll free number on the website rings my cell and sometimes I wake up to missed calls from Nigeria or UAE and I think that’s pretty special. Call volume has not been overwhelming. Thank god.
Marketing is a huge chore and I mostly disdain it.
However, I was about 5 minutes on your site and could not find a list of compatible printers. Where did you hide it :) ?
But it would be AWESOME if I could let a user click a button and send them to a labellive:// URL and have it just work. I'll explore a little and see if there's a mom-tested way to make this usable.
Again, very cool app!
I definitely have users triggering labellive:// integrations. The nice thing about the URI is it automatically launches the app if it isn't open - which is not true of HTTP integrations. The downside is it can be slower, especially on windows. Been there, done that. Maybe there's a workaround because Windows optimizations like this are a black box/art.
The other challenge is going to be referencing a standard design. Today, the integrations reference an absolute path or a "pinned" design file. I've had a few subtle requests to allow pulling down a standard "reference" design from the cloud (that you host for your users), and the app will cache the design based on a computed hash that you include in the URI. If your design changes, update the hash, Label LIVE will pull the update on the next invocation.
There's a lot of fun room to play with this. Let me know if you'd like to team up by emailing help @ label dot live. Now that I've got a fairly sturdy base of features my 2022 focus is to really hit and deliver on the potential for integrations like this.
That's certainly not the trend. Evernote has even released a Linux app after all these years. And for good reason - the Chromebook market. Hey is another.
It was a long way. I started in the Pro Audio niche and initially supported Windows, Linux, Mac. Over time, I learned the hard way that supporting Apple's constantly changing OS is very expensive, plus Mac users tend to act the most entitled when stuff doesn't look or feel like their native OS. And Linux just never sold a license, instead I got lots of Open Source bitching. So eventually, I dropped Linux and Mac support, doubled down on the new Windows APIs and then things got nicely profitable. Price is one-off $299 for the regular app kit with perpetual updates (so far). People use the apps for making movie sound effects.
I did not realize this was a mark of the student life. Who knew I was still a student at age 49?
Separate store and fastspring.
Deleted Comment
the current problem for me with Microsoft fat client is there are too much options and no clear one that Microsoft will support long term.
Imgui and juce are great frameworks.
Having been out of the web app development bubble for about seven years now, there's whole industries that work entirely in the pay-for-it-and-then-download model, and while games-as-a-service is more popular now than ever before there's still plenty of the old-school way of doing things going on.
I really like the simplicity. You can buy the thing, maybe from Steam or maybe from a DRM-free store like Humble, download it, play it. You can get a refund if you don't like it, or buy another copy and gift it to a friend if you do.
[0] - https://store.steampowered.com/app/386900/The_Cat_Machine/
[1] - https://store.steampowered.com/app/654960/The_Eldritch_Zooke...
* What's your tech stack for the games? Are you using an engine?
* Who made the art? If you did it yourself, what software are you using?
* How was the process for releasing your game on Steam? Did you have to do a lot of marketing to get users to greenlight your project?
* How did you make the trailer for the Eldritch Zookeeper? If you didn't do the voice, how did you hire the voice person?
* The Cat Machine has 107 reviews on Steam. How many users does that translate to?
* Does your current employer have a clause in the contract discussing IP made on your own time? Did you have to get an exception from your current employer to be able to release games on Steam?
Thanks in advance.
Marketing for The Cat Machine wasn't too bad, I had an okay ground game with getting coverage from gaming websites and someone posts it on Reddit and for 2015 that was good-enough marketing for the time, more than enough to Greenlight the game. The voice actor is Scott Gilmour (@scottgilmour7 on Twitter) and I found him after listening to about 100 voice samples on all the different VO websites. He's fantastic! I don't share my sales numbers publicly, but Steam is about 70% of The Cat Machine sales, and about 25% is from the Apple Mac Store - where the game actually hasn't been published for about a year now, I need to get on that and reupload it. And games is right now my full time job, so no IP clauses needed negotiating, and my old employer back in 2015 was very chill about letting me work on my own stuff.
Hope that helps!
I am a web developer and always assumed that you need SaaS or mobile app to make money from programming. But I hate to be responsible for customer data or troubleshoot servers at night.
I might have to look into desktop development and even game development as that was the reason I studied computer science.
It has this features:
* B2B in a niche market (TAM < 100K-200K users)
* Some viral component so you do not have to spend money on ads for growth.
* Sold as a subscription and only as a subscription. Don't innovate with licensing focus on product, this is important. When users have fewer buying options, they decide faster. That's why Steve Jobs reduced 50 Mac models to just 3.
* When the subscription ends, the application must stop working. This is also very important. You want your entire user base to be able to install the last version. You do not want to support older versions, you only want to support one.
* Has to have a very generous trial so that users have time to find use cases with your product. Better a trial based in actual usage instead of exploding trial base in calendar days. You want your users to actually use your product and depend on it.
> * Some viral component so you do not have to spend money on ads for growth.
Indeed. For years our sales department was simply our customers. They'd call their friends and tell them they need to get our software, or when they switched jobs they'd work hard to get our software used at the new place.
Now we have a small but proper sales team. However word of mouth got us very, very far.
> * Sold as a subscription and only as a subscription.
This was a key point my boss realized early on as well. It's much easier for the accounting department to handle a fixed recurring cost, than a bi-annual huge expense or similar.
It also allows you to incorporate usage into the price, so the price scales with the customers' income, not unlike cloud offerings.
We have a small fixed monthly cost, and a variable cost (per invoice/order essentially). The variable price depends on volume, but it's very predicable and makes it so the customer doesn't have to worry too much if business is slow for a while.
Note that viral is not the same thing as word of mouth. Viral means that one user expressly or subliminally forces other users to use that software.
For example, a customer asking or encouraging a vendor to use some specific software because it makes things easier for the customer and later, when that vendor is also infected with the need, they ask or encourage their own vendors to use that software too.
This is the distribution mechanism that we have for our tool.
* B2B niche - agreed, this is essential
* Viral component - I wish I could make label printing viral... but I feel like I'm dealing in the "colonoscopy of software" with my app
* Only subscription - I agree this maximizes revenue, but I find subscriptions user-hostile, so I also sell a one-time license
* Subscription expiration - obviously essential
* Generous trial - agreed, essential
It can be a relatively small gap in theory covered by several larger tools but only superficially covered either because they do not truly understand the pain point of that gap or because they simply want to limit complexity of their base product and their surface of support.
So then you focus on developing that feature to perfection with a strong focus on integrating with each of those larger tools, whenever possible without any collaboration of those larger tools (that will come anyways later if you get the traction).
The larger tools will never compete with you directly because if they created a tool doing the same thing you do, they would have to integrate with their direct competitors, which is a bad scenario for them as either they get expressly blocked by the other tool developer if seen as a threat or because by having such tool they would be ultimately improving their direct competitors tools.
Our current position is that if a customer of us decides it's time to change the larger tool, one of the factors of the decision is how well the new larger tool integrates with our tool.
Go onto any software listing site (eg. Softpedia or AlternativeTo), pick a not-a-brandname commercial product and chances are that it will be a single-person project. From things that are really well-polished and look like a team effort to pimped-up crappy weekend projects. Lots and lots are made and run by a single individual.
Whether they sell well is an altogether different question, but it's generally not hard to make several $k per month off a decently useful consumer desktop software. All depends on the size of the niche, the fit (read, specialization) of the product, its quality and the amount of marketing effort.
This business model is still often referred to as "shareware", so if you want to find communities of people that are involved in it, that'd be the keyword to search for.
Here are the ones that I use most and the companies that develop them:
Fission; Audio Hijack (Rogue Amoeba): https://www.rogueamoeba.com
Amadeus Pro (HairerSoft): https://www.hairersoft.com/index.html
Transmit (Panic): https://panic.com
Jedit Ω (Artman 21): http://www.artman21.com/en/
BBEdit (Bare Bones): https://www.barebones.com
GraphicConverter (Lemke Software): https://www.lemkesoft.de/
I only run macOS on my laptop and yet it's where I've spent the most money on various utilities.
MacOS-only software I've paid for: Bartender, BetterTouchTool, Forklift, SoundSource, Pixelmator Pro, iStat Menus, Nova, Alfred, DaisyDisk, and some other things I'm sure I'm forgetting.
I try my best to make it "worth it" to purchase the app. Label LIVE is a super- boring business label printer app so it takes a "special" person to 1) need the app and then 2) decide that they'd save more money by cracking it than just paying for it. If I 10x my pricing (as my competition does), then I would fully expect users would find it worthwhile to crack and distribute.
An altogether different option is to pay 2x the commission and use "full-service" reseller frontends like Digital River, PayProGlobal, etc. These are referred to as "registrators" and they used to be useful, because getting a merchant account and processing cards was a royal pain the ass. But now there's Stripe, so virtually no value in them. In fact, they tend to make thing more difficult to the clients than needed to justify their own existence (like requiring phone numbers, calling customers back to "verify" purchases and other artificial b/s like that).
Re: piracy protection - wildly depends on whom you ask. There is a camp of people that put minimum effort (literally a a single "if" check in the code) and embrace having their stuff cracked and hacked. The logic is that this acts as extra marketing and helps converting pirates (lol). There are also people who use packaged solutions like VMprotect and (previously) Armadillo. This tends to nip piracy in a bud, but creates issues with antivirus false positives. It also makes the software heavier and more fragile. There's also a middle ground of custom protection schemes that, if deployed wisely, can create 100x more headaches to crackers vs the effort spent on coding them in. Not that hard to do, but these aren't drop-ins, obviously.
Also, closely related, is the question of how the licensing works. Previously, most of the shareware used completely offline licensing using "keys" that were either hardcoded into the program or verified algorithmically (read, with elaborate checksums and such). This caused an emergence of keygens and it also fed credit card fraud with people smash-n-grabbing keys in bulk and then published them for the street cred. Surprisingly, a lot of shareware still uses this method and they still bitch and moan about the consequences. The alternative, obviously, is to use online activation. That is, what is sold is an activation token that can be swapped for a machine-specific license, via an exchange with the licensing server. This nearly completely eliminates the CC fraud and it allows for finer control over licensing. There are some drop-in solutions for this, but all of them are really quite basic and almost universally suck. However, the good news is that is fairly simple to roll out your own online licensing scheme in a matter of few work-days (assuming you know a bit of web backend and frontend).
Every iota of effort spent going after pirates is effort not going into servicing existing customers or getting new ones.
That said, long-term, we expect to earn more from subscriptions for businesses, than we do from single-user lifetime licenses. But again, ATM, it's the single user licenses that sell well.
However I really like your approach having a pay-once personal edition and a subscription team/business edition. It's something different from the subscription-everywhere trend.
They reached out to us. We integrated their SDK (trivial), provided sales copy and screenshot, then waited about two weeks for the review.
For the first few months, we got the most revenue from SetApp, it quickly jumped to ~$800, but these days, we earn more from selling single-user licenses. I expect the SetApp part to become smaller and smaller as we grow our Teams subscriptions.
Generally, I think it was good. It got us a few hundred users very early on, which helped us focus on the features and fixes that mattered. It also helps with brand trust, i.e. if you are in SetApp, there is less chance of you being a scammer.