Ask HN: Anyone making a living off of desktop applications?

This type of analysis paralysis will kill your project.

> I have to think about the future, and so I have to try to make the right choice on this..

You don't have to make the right choice right now. For now, focus on getting something complete so that you can prove the idea out.

Obviously people still are, or else commercial desktop software would no longer exist/be maintained. Not being snarky, just saying it's a non-question (and that our company certainly is a "we do" response to your post).

We have a desktop application that uses QtWebkit for the UI.

We had no choice technically-we need to use audio APIs on Win/Mac to get our job done.

Based on my experience, I would not recommend building a desktop app unless there is a technical reason to do so.

Data storage, building installers, signing your app for target OS's, and dealing with auto-update are all technical problems that I'd prefer to avoid if I could. Building cross-platform code is also a pain and, while totally doable, will slow down a team that is not familiar with it, I think.

If I really needed to build a desktop app in the future, I'd investigate building building a headless app that hosts a websocket, and use the user's browser to connect to a localhost websocket to communicate with it. (i.e., a technical choice freeing my from Qt)

There are still financial desktop applications. Some old school people insist on using them.

I've published a desktop Windows app before with a freemium strategy. It was developed by a team of 3 after hours.

We didn't make a living out of it because we wanted to keep it as a hobby project but it paid out well enough to be considered a small business.

I don't have any advice on whether your app should be a desktop or web, it all depends on what is the app, who your users are, where are your users using it, what are your competitors, what is easier to develop, etc.

All I can say is that desktop apps can still be profitable in recent years, but I can't say it will be profitable for your project.

I make living off desktop app in construction industry. The app is 21 years old and is still written in Delphi 5. I still actively maintaining it and it runs fairly well on modern Windows OSes, but there were some low level problems in recent years.

We are team of two: I am sole developer and there is another person doing sales, support, training and all the rest of stuff.

From a desktop-application standpoint, the Web provides something very useful: easy upgrading. Like, you go to a URL, and if you aren't seeing the latest production revision of the site code, that's a bug.

IMO, if you think you'll ever have edge cases where users might struggle to stay connected to the Web, think about doing a desktop app - but even then, consider using eg Electron/QTWebKit/similar so you can continue to use HTML.

The only situation I would shy away from using the HTML/CSS/JS approach with new general-purpose PC-centric applications is supporting older hardware - I like my apps to remain snappy, but sadly even Webkit tends to lag (generally speaking) on anything older than an i3 or so.

I do, but I use a SAAS sales model. I think trying to use a one and done sales model is hard these days.

Yes, I am thriving with a niche C++/Win32 graphics app. Web apps are a long way from having the responsiveness and control of a desktop app.

Do you really think users will be doing Photoshop and AutoCAD in a browser? No matter if you have a fibre op connection, the lag is always there.

Recently the main player in this domain moved to Web apps. There was an overwhelming protest from its customers, who insisted they prefer the desktop version.

  No accidentally closing a tab or refreshing the page.  
  No browser updates f'ing with my right click menu.  
  No scroll-jacking.  
  No zoom-jacking.  
  No shortcut-key overlap with plugins (looking at you, 1Password/google docs)
  No input lag...EVER.

Oh, the future. The land of what ifs. Listen, you described your market already. Non technical people go to Google and type in facebook.com. A simple desktop app that they can just click will do. Still worried about future proofing it? Put it inside a webview and move on.

There are many ways you can actually not ask yourself that question.

1. You can package your web app into electron or similar 2. You can use a portable platform like QT or Xamarin

But more importantly, you should chose the one that will help you conclude that this is a good idea sooner. You'll probably end up rewriting the tool once you get feedback about where it rules and where it sucks.

So I'd say that unless you want to do that side project to learn something new, stick to what you know best (and what you know will work). That'll get you to the point where you can decide whether this is worth pursuing faster.

Our startup develops a HTML5 game editor called Construct 2, which is a Windows desktop app (Win32). We've been running about five years successfully with that. I'd say depending on the market it can still be relevant, but I don't know for how much longer - Windows in particular seems to be trying to drag developers away from Win32 and the new Windows Store UWP apps. Note that Windows Phone and "Windows RT" can only run Windows Store UWP apps, with poor support for Win32. MS continue to push UWP hard and I'd expect to see more MS hardware in future with no Win32 support, which is a little worrying, but doesn't seem to be happening fast enough to cause any kind of panic.

I'd add while mobile seems to be the trendy place to start a startup, most productivity apps are still easier and faster to use with a keyboard and mouse. So desktop-first can make sense sometimes.

One of my two small companies develop Windows development libraries for use in desktop and server applications and I see the native desktop apps doomed, except if you are targetting the enterprise (best in niche markets) and you know how to sell to enterprises.

Rule of thumb #1: if you can build the same application for the desktop or the web, choose the web. Don't think more. My company does Windows drivers and some other operating system internals stuff that is impossible to offer as a web app and this is the reason I can't follow this rule.

My last suggestion is trying to attach your app to other revenue streams such as trainings, customization, integration with other apps, and any other service that make you escape from selling individual (and probably cheap) units of your product.

I've been developing Horcrux Email Backup[1] over the years. The application had to be desktop by the nature of it. I'm not a living out of it but it is a very good side income. Given the fact that I live in a third world country helps too.

[1] http://thehorcrux.com/

I'm making video games for PC, Mac and Linux (like this one - http://store.steampowered.com/app/386900), it's a very traditional release cycle, I work on a project for x months, and then I release it, moving onto the next game after a few weeks of post-launch support. PC games are generally seen as more valuable than mobile games, so I don't need to sell a terribly large volume in order for me, a single developer, to make a living.

I sell desktop software to individuals (not business / industry) at a cost of $50-$100.

I have tested SAAS but have seen that:

* People trust a desktop app more. * People value a desktop app more as they feel they "own" it and will pay more

YMMV

I'm just launching a file manager (https://fman.io). In general I'd say use web / SaaS whenever possible. If you do go with desktop, you may be interested in a blog post I just wrote about the technologies we ended up picking: https://fman.io/blog/picking-technologies-for-a-desktop-app-....

For more than 3 years now I am making a decend full time income with a desktop cross browser testing application ( http://www.browseemall.com)

It is for a rather small customer group but still works great and is growing modestly.

It really depends on the usage of the application. What does it do? What features does it provide? What are the requirements of those features? You may need to consider a hybrid app, that has both a desktop component and a web service. If you can implement one or more of the features as a service, it will allow you to update them more easily. Also, keep in mind that a desktop app limits your install base to an OS, depending on its implementation, while an HTML5 application can be run almost anywhere.

I run a web app and am happy with it. Advantages:

- no update process

- support is easier, because you don't have to dig in the users specific setup

- monthly subscription model might be easier to accept for people, if they don't have the feeling of "owning" the software like with traditional desktop apps

- no multiple platforms (although people want apps, but at least, you don't have to also provide Linux and OS X versions)

Disadvantages:

- no offline mode (some people want that)

- some people want the feeling of ownership and privacy

I think as a one-man business, it's easier to maintain a web app than a desktop app.

Solo developer of a productivity app for the Mac for quite a number of years now. Yes, desktop apps are still very relevant and at least on the Mac, plenty of people willing to pay good money (unlike, say, the mobile market).

Whether to go desktop or web really depends on the application itself. Don't try and shoehorn it into one or the other. Ultimately, you'll need to find the right niche. Like in most industries, most people will fail (you usually don't hear their stories) and success will most likely not be immediate.

Doing things solo is tough so some general advice:

- You are going to be wearing many different hats but if you can afford it, contract out what you don't do well (like design, for many programmers). - You have fewer resources but also a lower bottom line. Don't expand without taking that into account, not just for the moment, but for the long term. It will affect how desperate you get with your revenue model. - Don't undercharge (especially if you go desktop). As mentioned, people still appreciate the value of desktop software.

Probably a lot more but those are the main ones plus I have support emails to deal with.

Our desktop app Pinegrow Web Editor (http://pinegrow.com) is build with HTML / JS / Node.js packaged with NWJS/Electron. Three years ago I started by myself, now we're three working on the app full time and making a comfortable living (mid six figures in yearly sales).

Choosing this tech stack lets you postpone web vs desktop app decision and keep both options open. While recurring web app revenue sounds appealing it requires servers and responsibility to secure user data. With desktop app you'll never receive a 3am call that your service is down.

Btw. Subscriptions and desktop apps are not mutually exclusive. We give both options (one-time license purchase or monthly subscription) to our customers and the split is about even.

Try making it with Electron http://electron.atom.io/

Then if you decide later you want it to be a web app its not that big of a job to convert it.

I have worked on a surprising number of desktop apps over the years, including Visual Studio and Internet Explorer. But even before that, a lot of businesses rely on desktop applications for a lot of their internal applications.

There's a guy called Andy Brice[1] who has been developing and selling desktop software for table seating plans[2] since 2005. He blogs[3] a bit about his experiences and thoughts.

[1] https://twitter.com/successfulsw

[2] http://www.perfecttableplan.com/

[3] https://successfulsoftware.net/

I have a couple Windows desktop apps (animal husbandry and event management) that have been around for years and still doing quite well. But I think these succeed primarily because they have a nice specific vertical and are particularly well suited for desktops.

For me, a successful desktop application has the following traits:

-- A nice specific vertical that is deep and complex to process,

-- Complex entry screens with lots of necessary rules and data validation,

-- Lots of manual data manipulation during the events,

-- Substantial benefit from ability to take advantage of desktop level mouse and keyboard actions,

-- Some complex grid based screens that can be tailored by each user,

-- Fairly complex reporting after the events.

These requirements are still too much for browsers to handle well. The grid based screens are especially horrible in browsers. And browser apps are still pretty horrible for complex data entry screens that want to be customized by the user.

That said, I'm porting the first to a mixed mode where the engine will be internet based but the primary interface will still be the "normal" download and install desktop model. This is to allow some portions to be used in a browser, but the main application still keep the full desktop power.

FWIW: my original apps were Delphi based, but the language long ago stagnated and had become tedious (comparatively). Since I'd switched to .NET for contract work, I started my rewrite in C#. But but I ended up hating the server deployment crap with .NET and also of got really tired the direction Microsoft is going in general. I've now switched C# for the desktop side and Google's Go language for the web/model portion. I picked Go primarily for the trivial single executable deployment. While I don't really get much enjoyment out of coding in Go, it is eminently practical for this type of work. (Note for Gophers: I don't think Go is bad either ... just sort of there. I do use it quite a bit these day and do get the "fun vs practical" trade-offs the Go team made.)

But the future may be bleak with Microsoft moving to an app store. Why the F do I want Microsoft sitting between me and my customers. It adds no benefit to me and provides no benefit to my customers for a portable or unzip and go desktop application. Plus they, like Apple and Google, want to become effectively the worlds most expensive payment processors.