
Ask HN: Anyone making a living off of desktop applications? - jventura
I have this side project that has been stuck for quite some time, because I can&#x27;t seem to make up my mind if I should go with a desktop or a web application. Is any single developer or small team making a living of desktop apps, and are they still relevant?<p>My side project is a kind-of productivity application, and my target users are not really technical people and will probably have one computer, but as I&#x27;m a &quot;lonely&quot; developer (working alone) I have to think about the future, and so I have to try to make the right choice on this..<p>It would be great to hear both successful and unsuccessful experiences made by single or small teams of developers..
======
rxlim
First, of course you can make a living out of desktop applications. In the
echo chamber of HN you could maybe get the idea that they are no longer
relevant, but out in the real world millions of people need to do real work,
but don't have a stable connection to the Internet.

Second, If you decide to create a desktop application, then make it native. I
must strongly advise against using any of these "web frameworks" e.g.
Electron, QTwebkit etc. to create desktop applications. They are slow, bloated
and probably contain many security holes because of the huge complexity of
browser engines.

They only exists because many developers don't know anything else than web
development, instead of learning new skills they created this abomination. One
earlier post said that minumum an i3 was required for the apps to remain
snappy, think about it, that is just ridiculous especially in a time where
PC's are upgraded much less frequently than they used to be. I would NEVER
install an application created using a web framework.

I have good experinces with Rust and Golang when creating native applications
for multiple OS.

~~~
derefr
> They only exists because many developers don't know anything else than web
> development

I know how to write native apps in C# with WPF, Obj-C with Cocoa, C++ with Qt,
Erlang with WxWidgets, and even in pure Tcl/Tk. I still prefer using HTML5 to
any/all of those. It's about multi-platform portability, where "the web" is
itself one of the targeted platforms.

> I would NEVER install an application created using a web framework.

Do you use web apps in a browser? Gmail or Outlook.com, say? Why would them
adopting more native UX controls make you _stop_ using them, then?

If it's about the cost in non-shared runtime memory (i.e. basically running 5
separate instances of Chromium for five "apps"), this can be fixed; look, for
example, at how the Chrome App Launcher works in Canary. Window-mode Chrome
Apps are basically equivalent to Electron apps, but run as sandboxes under a
common single-process runtime (Chrome) rather than each being a process of
their own.

~~~
dvdkon
I use Gmail and other web apps, because I'm accessing remote data through
them, and running remote apps to do so is a good idea IMO. However, I think
"the Web" is not a good platform for native-like apps. It's not only slow and
resource-hungry (I can edit pictures and video reasonably, yet web apps still
stutter and hang up), it was also never designed for app GUIs. HTML is a nice
text markup language, but it was never meant for GUIs. CSS is nice for styling
text, but it's now used for much more. Layout is torn between HTML and CSS.
And web apps don't "fit in" with their appearance, and I value consistency in
desktop apps a lot. With Qt/GTK, I can change a system-wide theme, and all
apps will fit in with each other, which is something web apps can't offer. And
while creating new frameworks may help programmers, it doesn't solve the
fundamental issue that the web is not meant for native-esque apps.

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

~~~
danieltillett
What are the low level problems you have been running into?

~~~
dejv
Three main things: \- memory space for printers and sound cards changed in
Vista, so when you have some constellation of printers and you change the
printer in dialog whole program just crash, because it is trying to touch
restricted memory or something.

\- running Paradox in network is quite difficult. Whole database was written
in 80s before things like tcp/ip was thought as a good thing and all the
networking part was hacked inside and it shows. Because of weird architectural
choices made 20+ years ago I am not able to migrate out to sane database
without rewriting whole application. (250+k lines of code)

\- BDE could be quite unstable in various scenarios and you spend quite a lot
of time fiddling with memory space, memory size and other variables to make it
work.

~~~
danieltillett
Thanks for the explanation. A lot of my code is getting old (just like me),
but I was lucky in that it was designed from the start to be cross platform.
This ended up meaning that it was written in C and all the platform specific
code was kept as separate modules.

My big problem is I have so many code paths that I can’t fully test the
interactions between the different modules and functions (there are over 10^25
different possible paths). I am not sure what can be done about this given the
functionality of the software is critically dependent on this flexibility. The
best I have been able to come up with is testing 99.99% of the most popular
paths and building in a lot of error recovery code.

~~~
vram22
>My big problem is I have so many code paths that I can’t fully test the
interactions between the different modules and functions (there are over 10^25
different possible paths).

Interesting. Have you considered the pros and cons of writing a custom fuzzer
for your app, and whether it may help?

~~~
danieltillett
I actually have written a custom fuzzer. It has been really useful in chasing
out bugs caused by improper handling of corrupt files, but fuzzing won't help
solve the combinatorial coverage problem.

~~~
vram22
>possible paths

But don't all those paths depend on the inputs, ultimately? Trying to
understand this here. Can a fuzzer that generates lots of different inputs,
not be used to exercise all those paths?

~~~
danieltillett
Not when you have 10^25 paths to cover and each path takes around 2 seconds.

~~~
vram22
Wow. Got it.

------
DizzyDoo
I'm making video games for PC, Mac and Linux (like this one -
[http://store.steampowered.com/app/386900](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.

~~~
bdavisx
When you say "make a living" \- how does that compare to a "typical" US
developer salary/benefits - say around $120K total compensation? (and yes, I
know that's far below a SV total compensation, but you wouldn't have to live
in SV for this kind of lifestyle business).

~~~
gambiting
Just to keep your expectations in check - I work for a major games company in
the UK as a C++ programmer and make 25k pounds/year($36k USD). US salaries are
an abnormality.

~~~
rgovind
$35K is what a decent developer in India would make. So, your UK seems too
low.

~~~
sokoloff
Much of the games industry is incredibly low-paying. I felt fairly fortunate
to have worked in my 20s for a good game company (where I was paid OK, learned
a ton, and we eventually had an exit to Sierra), but I feel like most of my
peers at other companies were working for terribly low pay and often under
poor management.

------
cylinder
I can offer the perspective of the customer. I am a bit fed up with web apps
these days, and would find a good desktop solution refreshing. You should
include cloud backups and sync, however, that is key. But, web apps are
getting slower and slower -- even the 1 or 2 seconds it takes to open a new
link stresses me out when I'm in the zone and trying to work fast. I am even
trying to move away from Gmail to Outlook now.

~~~
lj3
Would you still choose a desktop app over a web app if the web app's response
time was within the 100ms window[0]? In other words, is speed your only
complaint with web apps these days?

[0]: [https://www.nngroup.com/articles/response-
times-3-important-...](https://www.nngroup.com/articles/response-
times-3-important-limits/)

~~~
cylinder
I think so, assuming the web app has full keyboard shortcuts. But if I notice
response time, we're in bad shape - I'm admittedly ADD and will likely switch
to another tab while waiting for the page to load.

~~~
brokenmachine
I am the same, I have buttons mapped on my mouse for switching to the last-
used tab (Ctrl-Tab), closing the current tab (Ctrl-W), etc.

Usually I will middle-click any link to open it in a new tab, then immediately
switch back to the original tab while that one is loading. Only when I see
that it is loaded (text on the tab turns red) will I switch to it.

All too often I see web-apps as a regression. We have super-fast machines now,
but we're choosing to make ourselves dependent on the slowest link in the
chain, the network. Might as well go to Pluto.
[https://blog.codinghorror.com/the-infinite-space-between-
wor...](https://blog.codinghorror.com/the-infinite-space-between-words/)

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

~~~
codecamper
separation of concerns. Just write the logic in a fairly portable language.

~~~
jventura
I do have it in Python! I've successfully build some frontend experiments with
Android ([http://joaoventura.net/blog/2014/python-
android/](http://joaoventura.net/blog/2014/python-android/)), Web (with Flask)
and Qt (PyQt5 and pyotherside).

My problem is with the choice of the best frontend approach, and since I'm
only one guy working on this, I am trying to find my "best" decision..

~~~
Retric
Generally, if it works as a website use that. Desktop apps are for things you
can't do with a website.

EX: File system tools, AAA FPS, etc.

------
mattront
Our desktop app Pinegrow Web Editor
([http://pinegrow.com](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.

~~~
bung
I'm not sure why it bothers me, maybe I'm just grumpy this morning haha, but I
might have preferred "Enter your email for a free trial" rather than being
forced to do it after I've already downloaded and installed and run it and
can't use it.

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

~~~
pabloski
Hi, if I can ask: "why QtWebkit instead of Qtquick?".

~~~
jventura
+1, I'm wondering if anyone is using Qt Quick for productivity-like desktop
applications?

~~~
kidproquo
I built Tasktopus[1] using QtQuick/QML/C++. Highly recommended. I built it on
the LGPL version.

[1][https://gumroad.com/l/ADWm/tasktopus](https://gumroad.com/l/ADWm/tasktopus)

~~~
jventura
Can you comment on your experience? One of my doubts is if I should go the QML
/ Qt Quick Controls way or the standard Qt Widgets (with PyQt).. For instance,
do you think you could implement your app's interface with Qt Widgets by
itself?

The problem is that I know how far I can go with Qt Widgets, but on the same
way, I would like to build something more "modern" and Qt Widgets may be quite
limited..

~~~
kidproquo
I could have implemented it with QtWidgets, however I had found a decent UI
widget library that suited my use case very well ([1]). Hence went with
QML/QtQuick.

My advice - just do it :-). If you want to build a cross-platform desktop app
then go for QtQuick/QML/C++. QtCreator has a bunch of example projects. Use
those as reference. The Qt docs are solid. Worst case - you will learn that
Qt/C++.

I am not a big fan of PyQt/PySide, especially when starting fresh with Qt -
you would have a hard time figuring out how everything fits and where the
issues are.

[1] [https://github.com/papyros/qml-material](https://github.com/papyros/qml-
material)

Paraphrasing a previous comment:

I have used web-based task/todo lists (trello, asana, etc.) but I wanted
something that could be used offline - my work does not allow storing company
sensitive data on 3rd-party servers.

Started the project with Electron, using AngularJS and Angular Material. That
allowed rapid prototyping with a slick UI and it was fairly easy to find
additional Angular-based plugins. My main motivation in selecting Electron and
Angular was to learn the two technologies (easier to learn something by doing
a project in it). Screenshot:
[http://imgur.com/NZzEFKX](http://imgur.com/NZzEFKX)

Had a few issues with the Electron app - big download size (50-70MB zipped),
no print functionality, app felt non-native, very convoluted process to get it
published on the Mac App Store.

Decided to change the tech stack to Qt/QML. I have published C++-based games,
built on Cocos2dx. Wanted to try Qt to build a serious app.

Gumroad has been a slick experience - I have opted for the fully functional
trial option and let the user buy a license to use beyond the trial period.
Gumroad's onboarding (buy workflow) and tech (license key generation and
validation) have been a revelation.

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

~~~
windowsworkstoo
Yet the same feature can be a pain in the ass as you don't control your
upgrade destiny. I know, I know, git orf mah lawn!

But when you see normal folks totally confused because the developer decided
to "upgrade" their experience in a way that was totally out of the users
hands, it can be cringey.

~~~
i336_
Yeah... that's very true too, I hadn't considered it from that angle.

I will admit that I far prefer software that runs fully locally; if I don't
like the direction a particular program has gone, I can either just use an
older version.

And I do also find it jarring to open an app and be met with some new layout
or design, or discover a new feature buried in a menu that wasn't there
before. It would be really nice if app design was at the point where we could
go "okay, here's a bunch of new features, click this button to switch
over!"...

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

~~~
AshleysBrain
> Web apps are a long way from having the responsiveness and control of a
> desktop app.

I don't think this is the case. Facebook never needed desktop apps, did they?
The web worked great for them.

~~~
fekberg
Depends on the audience and the application. As Photoshop and AutoCad are both
mentioned, I think that's the benchmark and not something like Facebook that
wouldn't benefit as much from running as a desktop client.

On a side-note, didn't Facebook just release a new UWP app and didn't they
regret going the HTML5 route to start with (not focusing on native apps)?

~~~
AshleysBrain
They were fine for years without any kind of desktop app, and the HTML5
backtracking was just for mobile. I don't think they ever said they regretted
being web-only on desktop from the start. In fact I think it is even a big
reason for their success - would Facebook have taken off if it had an
installer?

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

------
fatimafouda
I'm currently working on an AI customer service Desktop/Web app solution.
We're a team of two.

Initially, it was going to be only desktop, because we were targeting big
enterprises who still rely solely on phone for customer service. So, pretty
backward companies. A Desktop app would have been perfect and not too
"revolutionary".

But, then, we decided to not limit ourselves to that market alone, and have
since made the transition to include web and even mobile solutions.

My advice is to: Stop hesitating. Write code (MVP?). Run private and open
betas. Collect feedback. Make predictions. Make decisions. Maybe your market
will rejoice over your desktop app and maybe they won't. The point is, you
won't find out until you actually test it. If it works then that's great. Now,
you can focus on marketing and growth. But if the feedback that you get points
that your customers would rather get web, then that's also great. Because,
now, you've gained an important insight about your customers, and will have a
choice of either to switch to web (if it's a true market need (also from
customer feedback)) or to start something new.

TLDR: Based on our market research alone, you CAN definitely make a living off
of a desktop application; it depends on your customers, that's why it's
paramount that real customers test your app asap. Don't worry about the future
too much. If your desktop app is successful and somewhere along the line,
customers demand a web app instead, you can always scale and adapt.

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

~~~
dorfuss
Off topic - googling facebook.com drives me nuts.

A couple of days ago I went to an administration worker at a university and
asked her to help me with getting the vpn to connect to the net via university
wi-fi. She told me to google the vpn to download it. I said: well, this is the
very problem, I want to connect to the Internet, I cannot google it while I'm
offline. People no longer distinguish between the address bar and google
search, searching for files on your local drive or looking for them online.
It's become one blob of "computer stuff". And you might think that when we
moved from command line in DOS to Windows that was creating a new kind "stupid
user". There is the next level, certainly.

~~~
asimuvPR
The whole UI/UX has been app-fied. The most common device an average person
uses has a touch screen interface. Writing on an address bar is _old_. Google
is now their personal assistant and facebook replaced their tv.

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

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

------
nvader
Since this hasn't been posted yet, "Why I'm done making Desktop Applications"
by Patrick McKenzie (patio11) is going to be a useful read:
[http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-
web-a...](http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-apps/)

It seems that his customers share a lot of characteristics with your ones.

------
azeirah
I've made an addon-program for game streamers, one day I decided to go "heck",
why not ask some money for a license.

I can't really say I'm making a "living" off of it but for a student I do have
a /really/ nice income.

It's a /very/ specific application though. It swims along with the bigger fish
like Open Broadcaster Service and xsplit, when they go down, I go down.

~~~
randhnuser
I'm currrently reading "Don't just roll the dice" which is a really nice and
short book about software pricing. It's freely available too at
[https://www.red-gate.com/library/dont-just-roll-the-dice](https://www.red-
gate.com/library/dont-just-roll-the-dice)

What I want to say to you and the others in the thread is: maybe you can
extract more money at a different price point by reading that book.

~~~
azeirah
Thanks for the recommendation, will have a look. I'm a little skeptical of
price changes though. Partially because of ethics ("Why'd he have to pay 5$
while I have to pay 8$?"), and partially because of my target audience, mainly
students and young adults (18-28)

Regardless, it's interesting to look into

~~~
taprun
Here's a cheat: When you raise your price, you can bundle something else in.
That will automatically prevent people from asking "Why am I paying more?" It
doesn't even have to be that impressive. Spend an hour and write an extra
guide, checklist or something like that. Make sure that it's clear to buyers
that this add on is new. Done.

------
hermitcrab
I have been making a good living selling desktop software as a solo developer
for the last 11 years. I think reports of the death of desktop software are
exaggerated: [https://successfulsoftware.net/2013/10/28/is-desktop-
softwar...](https://successfulsoftware.net/2013/10/28/is-desktop-software-
dead/)

~~~
jventura
Thanks for replying! Your blog was one of the "triggers" that made me decided
to ask if more people have been having success with the solo developer/desktop
developer strategy.

I just wish more people shared their experiences on their blogs, because here
where I live it is pretty hard to find someone working for themselves..

~~~
hermitcrab
Desktop and web both have their plusses and minuses. Some solutions are a
better fit for desktop. The key thing is to do a good job of solving the
customer's problem. If you do, they won't care whether it is desktop or web.
In fact, plenty of my non-techie customers don't even know the difference.

------
lostmsu
Fail story: I have SSD + HDD caching for Windows (
[https://diskache.io/](https://diskache.io/) ). But due to lack of marketing
skills, and, perhaps, lack of common store for system software for Windows,
even free Beta version has been downloaded by like 3.5 people during 3 months
of availability.

~~~
orf
Your link is grey for me, so I've seen it before. If it's been on HN you must
have seen more than 3.5 downloads, what are your actual counts?

~~~
lostmsu
I don't have exact download count, but only 13 people actually launched it.

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

~~~
jventura
That is the tricky part, is that I know how to make web apps (used to work as
backend web developer), desktop apps (did my fair share of them), and can also
play a bit with Android (did some small experiments and patches for
Cyanogenmod). It seems that I just need to commit to something and work from
there..

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

~~~
SyneRyder
> Don't undercharge (especially if you go desktop).

This is incredibly important advice! Marketing & actually finding customers is
the hardest part of the business, so if you only need a few customers, you'll
be way ahead of the pack.

I know someone who is selling a Photoshop Plugin for $100 and seems to be
doing okay from it, even though that's more than the price of Photoshop
Elements itself! If your product is valuable enough to your customer, they'll
pay for it. If they're earning $100/hour & your product saves them even two
hours of work, it's a no-brainer.

> ... plus I have support emails to deal with.

Don't forget this when considering your pricing. Some percentage of your
customers will always need support, and you need to account for all those 15
minute blocks where you're helping people. If you're selling a $2 app, a
single support email wipes out your earnings from several sales.

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

------
AlikhanPeleg
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](http://www.browseemall.com))

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

~~~
jventura
Very interesting case of subscription based desktop application, am I right?
How do you manage things such as a person being offline, do you require the
person to connect to the internet so that you can manage the subscription? How
does your users react? Have you already started with a subscription-based
approach?

~~~
AlikhanPeleg
Generally people will need to get online to get the latest version (which is
necessary frequently to get newer browser versions). During this time the
licence is also checked.

In my experience the customers expect a subscription based pricing especially
with an application that required high-frequency updates (I release a new
version once or twice a month).

------
walkingolof
As a developer of both services and also in the past desktop application, I
have to say that one big plus with desktop apps is that they do not need a
24/7 NOC operation, that uptime thing is putting a huge strain on founders and
resources starting out....

------
Razengan
As a user, I despise webapps, unless it's for social networking or news (like
FB/Twitter/HN/Reddit/Imgur.) Even for social/news I prefer native apps to
webapps when available.

I mean look at the native mobile apps for FB and everything; I'm sure the
majority of users prefer opening the apps to using the browser, so there
_must_ be _something_ going for them.

Webapps NEVER feel as responsive or powerful or fit into the look-and-feel of
a platform, compared to native apps.

To me, most of the alleged advantages of webapps just look like the excuses of
lazy developers, not to mention also a bit of hypocrisy: Would YOU prefer most
of your IDEs and development tools to be webapps, or native apps?

------
anotherevan
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](https://twitter.com/successfulsw)

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

[3] [https://successfulsoftware.net/](https://successfulsoftware.net/)

~~~
infinite8s
He is also on this site -
[https://news.ycombinator.com/user?id=hermitcrab](https://news.ycombinator.com/user?id=hermitcrab)

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

------
mherrmann
I'm just launching a file manager ([https://fman.io](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-...](https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016).

~~~
kowdermeister
Very good idea, if you can pull off what sublime did to text editors, then
take my money :) I'm still using Total Commander, but I definitely see the
need for a more focused app that help my directory browsing habits.

Subscribed, rooting for your project.

~~~
mherrmann
Thanks! :-)

------
pnathan
I would suggest a desktop app on the JVM - C# possibly if you have access to
that and your customers care - but nail down the upgrade story.

Web Apps immediately invoke an entire side set of knowledge of sysadmin and
management that, unless you're comfortable doing that - are a pain.

There are reasons to do web apps, but I don't think ease of operating or
development are one of them.

~~~
stephenr
> I would suggest a desktop app on the JVM

Is this a joke? Or possibly a comment somehow posted from 8 years ago?

Unless you're doing what Jetbrains do (and ship an embedded JRE) relying on
Java is adding a barrier to entry on top of "wtf, java? it's 2016 not 1999".

In my career i've had reason to use a small handful of jvm desktop
applications. In every case, it was because there is no good alternative, and
they were used _in spite_ of being jvm based - if a non-jvm alternative comes
along, it gets an instant boost in any comparison, because it isn't tied to
the jvm.

~~~
pnathan
No.

I have had good experiences developing JVM apps and then using them. Age of
technology has nothing to do prima facie with quality.

If you're interested in shipping a reliable desktop application, you'll take
the time to handle the runtime and the associated dependency chain. Similarly
to the web, you have to understand your system to do the job well. Unlike the
web, you don't immediately confront distributed system operation and
maintenance problems.

And, finally, I'd actually suggest Clojure/seesaw for the mode of desktop GUI
development, not Java/Swing. And, of course, the customer doesn't care whether
you hand-crafted it with magnetic tweezers or used Node 9 Ember Rock Stars.
They just want it to work, and work reliably.

~~~
stephenr
I wasn't suggesting java's age is why it produces terrible desktop apps, I was
referring to its former "glory days" of common usage - these days it's much
less common for desktop apps in my experience.

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

~~~
jventura
The application that I want to build is for a niche market (but not for
companies), that is why I am in doubt between desktop and web.

One thing that makes me want to stay way from web is that if this thing does
not work, I would like people to continue using the application, even if I
don't update it anymore. If it runs on a server, I will not be able to stop
the server until everyone stops using the application for some time. I know
some people kill services without thinking too much, but this is a very small
niche and my name is relatively known there..

The other reasons of wanting to stay way from web-only is that then I have to
take care myself of everyones' data (think application data, settings, etc.);
front-end web developments is a pain for me (too many options, none good) as
I'm mainly a backend developer; and then there's the latency problem.

As I think I said above, my application is something like a productivity
application, where everyone does his own thing and there's no intrinsic need
for "social" or "sharing" things. The only reason I can think for web is
discoverability, hence my doubts, if "discoverability" beats everything else
(for desktop apps)..

~~~
wslh
How long will it take to develop your desktop application? If it is just a few
weeks or very few months go for it and test the market. If it doesn't work
after spending some marketing efforts move away. Indeed nobody can predict
your success.

Again, I think it is very difficult to attack the desktop market even if you
target a niche market for end users. Enteprises uses are a different story.

One more thing if you insist: look at the OSX desktop market too because the
dynamics of the end user consumption are different from Windows.

~~~
jventura
> One more thing if you insist: look at the OSX desktop market too because the
> dynamics of the end user consumption are different from Windows.

Definitely, even more as I develop primarily on a Mac.. Thanks!

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

~~~
uhtred
I can understand some people not wanting to send sensitive financial data
across the web.

------
cdennison
I wrote (C#) desktop apps for several years that did manufacturing QA
analytics. We went the desktop route because 1) UI development was faster for
us (C# vs. jQuery) and 2) Users wanted to interact with Excel in real time
(e.g. export).

My experience when I went to look for a job was that I got about 10 interviews
and was turned down for all of them because I didn't know about JavaScript,
Distributed systems (e.g. load balancers, HTTP caching), WebSockets,
deployment pipelines, web services, etc. Don't get my wrong I spent a lot of
time reading about all these types of things but until I built an actual
API/website it was hard to answer questions about them.

------
jjp
This feels to me like there are a few other questions to ask: \- do your
target users have a preference for desktop vs webapp? \- can you achieve
everything you want in desktop vs webapp? \- How do similar solutions from
competitors deliver? How would you differentiate? \- do you have the
skills/time/inclination to provide desktop support when a user can't get your
software working with Win XP and a badly written printer driver? \- What's the
pricing model you will use with lone users? Sell once, sell once and then try
and sell upgrade; subscription?

------
netman21
I would pick my app carefully. Things that are specific to desktops like AV,
disk cleaners, performance monitors would have staying power. Also word
processors for specific constituencies. Scriviner, for instance, is for
serious writers and is still supported by its creator. Diagram creators, slide
presentation creators, even a database with an easy to use interface would be
popular. I personally would love to see an enhanced Activity Monitor for Mac.
Something that would have an entry for every process running so I could just
click it to figure out what it does.

~~~
lstamour
That's the problem with desktop software though -- it's expensive to build and
often, there's a solution already out there or will appear in the next release
of the OS. For instance in Activity Monitor, you can view every process simply
by clicking the View menu, then "All Processes". It will even show them
hierarchically. Which then leads to users often picking something that works
and rarely switching unless an app fails on them somehow. Contrast this with
the web, where we routinely "switch apps" because there's so little cost to
install them, keep them up to date, commit to them and save our data in their
format, etc. AV software is much less useful these days as systems ship more
securely by default. Disk cleaners also have less utility as folks learn of
free or built-in options, or buy larger drives than they need...

About all I can say to sum up is, yes, pick your app carefully, but solve a
problem you've researched and haven't found an easy solution to, and then ...
see if you can build that into a business? :) It'd also be fun to build a
meta-app: e.g. gamify learning about OS X, such as the activity monitor. Maybe
it could be social, where you get points for being the first to get something
set up amongst friends on the same wifi? That sounds like an incredibly niche
market though...

------
Lordarminius
I posted a link relevant to this conversation a few days ago.

[https://news.ycombinator.com/item?id=11656443](https://news.ycombinator.com/item?id=11656443)

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

~~~
jventura
For my application there's no intrinsic need for "social" or "sharing"
features. It's supposed to be a productivity application where each user does
his/her own thing. The target user are mostly non-technical people which
probably will not have the need for have it on more than one device, so "sync"
of data between devices may not be a relevant for them..

If I go the desktop way, I will probably use Qt (PyQt5) so there's some degree
of freedom for cross-platform.

------
arcaster
I've considered creating an app with node.js and electron to turn my current
soundcloud archiving script into a desktop app. It makes taking essentially
all of someone's soundcloud and archives everything with proper ID3 tags, also
tracks updates to your playlists and likes.

Initially I built this to archive indy music and prevent losing tracks that
people removed from their soundcloud pages.

This project would require some major legal hurdles, which is why I've never
really built it as a proper desktop app.

------
matheweis
I don't make a living, but I'd like to think I'm close (3-5x would get me
there)

Anyhow, my strategy was to make both the web app and the desktop app.

The web app is free, which drives users to the site, a small percentage of
which buy the desktop app. The strategy works well, in the sense that I can
run everything on autopilot for a few months at a time if I need to.

On the other hand, I sometimes feel like the relative profits are kind of low
for the number of users that I have.

~~~
rangera
Programs like Nativefier allow you to quite easily (within reach of not-so-
technical users) create desktop apps out of web apps. Unless your desktop app
provides significant OS or other-app integration or additional features, you
may want to reconsider your strategy.

~~~
matheweis
It does - that is the case for the upsell. :)

------
justncase80
Try making it with Electron
[http://electron.atom.io/](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.

------
suhastech
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/](http://thehorcrux.com/)

~~~
ommunist
Very nice programme, that saves a lot of bacon. Please keep it maintained, I
beg you.

------
skiltz
I have a plugin for Outlook - [http://appointmentreminder.info/outlook-
calendar](http://appointmentreminder.info/outlook-calendar)

Desktop apps make you think a lot more about the release cycle and minimizing
potential errors before releasing.

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

------
cabbeer
Anyone here from the omnigroup? I'd love to hear some behind the scenes from
those guys!

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

~~~
ralmeida
I believe OP would like to know about solo operations or very small teams,
side-project-sized operations.

------
leecarraher
videogames are mostly standalone and viable, as are OS (less-and-less), and
apparently steve gibson makes a pretty nice living off of spinrite which is a
hard drive maintenance and recovery tool. Which I suspect gives insight on the
viability of the standalone software space. Needing extreme performance and
inately interfacing with the computer's hardware. As a maxim, if you can put
it on the web without sacrificing anything significant, you probably should.

~~~
khedoros
There are a few things that make me value the desktop over the web, as a user.
First, no surprising interface changes. If I install a new version and dislike
it, I can go back to the previous one. Second, if it doesn't need a network
connection by its very nature, it'll work fine without one, removing a point
of failure. Third, local data storage with optional cloud synch is the best of
both worlds. Fourth, a polished native program will have more predictable
timing than a similarly-polished web app.

Both have their place. I'll go to a web app for asynchronous communication
(e-mail, forums, social media), for one-time reference or reference to things
that change often (wikis, imdb), and things that I intend to use for a short
amount of time, or which wouldn't be worthwhile to download and install on a
couple machines.

Putting things on the web has always felt to me like a compromise of usability
and predictability in favor of convenience of access[0]. I like storing my
data locally until such time as I explicitly decide to store it online. I like
knowing that I can continue using the software, regardless of the fate of the
developer.

[0] Given internet connectivity and continued operation of the company
providing the software

------
cft
I suppose not many people do, but probably many people did in the early 90s.
In 5 years people will ask this question about mobile apps too.

------
pellias
I know grc.com spinrite still runs on DOS and his last release was easily 5-6
years ago and it seems to be still selling well !

------
k3liutZu
Build it with web technologies, and if you need to ship a desktop app, package
it with electron.

~~~
ommunist
I remember the guy who just decided to keep Windows 3.11 on a Celeron laptop,
because it was awesome fast on that hardware (still perceivably faster than
your Win 10 notebook perhaps), and he just worked couple of years that way,
until some SSL problems forced him to leave Win 3.11. But business
applications were ok for him in that environment. The very idea of a desktop
app is that it should be able to deliver value completely offline, imho.

------
jacobmarble
I interned for this company 6 years ago. Still kicking because it's so good.

[http://wenlin.com/](http://wenlin.com/)

------
vizza
Look at the top desktop apps out there - they are <b>browsers</b>

