
Ask HN: Desktop or SaaS for a low-maintenance product? - isv12345
I&#x27;ve read what I could find about this, including patio11&#x27;s excellent blog post. A SaaS product makes licensing and version&#x2F;upgrade issues irrelevant. However, you can offer a better desktop experience for many focused tools. And you can sell a desktop product with a simple download website and set up a bug tracker, which you have to run for the SaaS product too<p>As a source of passive income, I&#x27;m attracted to selling desktop software (standalone or browser extension) because I don&#x27;t want to have to worry about uptime&#x2F;my provider&#x27;s uptime and hosting costs, I&#x27;d rather be running on the customer&#x27;s hardware. Am I thinking about this the right way? Everything I read says desktop software is dead, but people seem happy to pay for it still.
======
dontJudge
Sure, server side software avoids update issues, piracy, and fits naturally in
a subscription model (more $$$ over time). No argument there, but those are
considerations for the seller, not the consumer (me).

As the consumer, I don't like server side software when running locally is a
more natural fit.

Client side programs will work forever, even after you go out of business. As
long as the system it runs on doesn't evolve out from under it.

It has a feeling a permanence. Of an heirloom. Not some ephemeral service. A
feeling of ownership like a hammer in your hand.

It may not be as good for you, but if it's software I want, where running
locally is the most natural fit, I will glady pay several hundred without
blinking. If I really need it I'd pay a few grand without blinking.

------
jasonkester
SaaS pretty much addresses every downside of selling Desktop software. To the
point where everybody who sells Desktop software these days is trying to
convert to a subscription model for it.

Desktop software sees its entire Customer Lifetime Value handed over on day
one, and is constantly competing against a free, pirated version of itself
that anybody can download if you dare set that CLV value above $50 or so.

Software as a Service keeps paying you money every month regardless of what
happens, and generally pays you more each month as new customers sign up. And
it is by definition un-pirateable.

The only downside you mention is that you have to run a webserver. But you
have to run a server anyway. And if you pick the right tech stack, those
things don't tend to go down all that often. You don't need "Five Nines" of
availability for most types of business software, anyway. Three Nines is fine.
Even Two won't generally lose you any customers.

And, of course, Scaling Problems are a Good Thing in the SaaS world. That
means that so many people are giving you money each month to use your thing
that they're overloading an entire server. That takes a lot of people, so you
can use a tiny fraction of the piles of cash they're throwing you to add
another machine to your cage. Let's hope that happens a lot.

So yeah, this is not a question that needs asking anymore. Build your thing on
the web.

Good luck!

~~~
stephenr
> So yeah, this is not a question that needs asking anymore.

Clearly it is a question that needs to be asked, because... it was asked.
That's how questions work.

> Build your thing on the web.

You literally side-stepped all the maintenance bullshittery that is required
for a _reliable_ SaaS app with "but you need a website anyway", as if desktop
app developers don't use GitHub Pages, SquareSpace, static HTML served from
S3, or any number of other "zero maintenance" web SITE hosting solutions that
will not in any way support running a web APP.

~~~
jasonkester
> You literally side-stepped all the maintenance that is required for a
> reliable SaaS app

My post was only a few paragraphs long, but one of them does in fact address
this. I've spent maybe 400 hours this year working on my little handful of
SaaS products. Zero of them were spent maintaining the server that they run
on.

On the effort scale, it's nothing compared to writing the software and
supporting customers.

~~~
stephenr
> The only downside you mention is that you have to run a webserver. But you
> have to run a server anyway.

Not necessarily. Plenty of desktop app 'brochure' sites use a hosted solution,
so zero web server maintenance required.

> And if you pick the right tech stack, those things don't tend to go down all
> that often.

What's "the right stack"? I'm sure Amazon and Google would love to know your
secrets to maintenance free SaaS.

> You don't need "Five Nines" of availability for most types of business
> software, anyway. Three Nines is fine. Even Two won't generally lose you any
> customers.

Two nines is >7 hours a month downtime. That's basically one business day per
month, the app is unavailable. Given that this is _in addition_ to any
scheduled downtime for things like upgrades, server maintenance, I'm not sure
I'd be aiming for that as your baseline.

I _get_ that the OP wants passive income from this endeavour. The way to
achieve that is _not_ to half-ass the infrastructure on a SaaS product.

~~~
jasonkester
I'm having trouble understanding where you're coming from with the hostility.
It sounds like your experience must be a lot different than mine.

I run a fairly standard Microsoft stack of ASP.NET, IIS, C#, SQL Server.
Chosen for its boringness and reliability, because as I've said before, I
really don't like having to worry about hardware:

[http://www.expatsoftware.com/articles/happiness-is-a-
boring-...](http://www.expatsoftware.com/articles/happiness-is-a-boring-
stack.html)

I'm also speaking from experience about the downtime thing. I used to have a
rather sketchy ISP, and would see those 7 hour downtimes from time to time. I
would occasionally get an email or two from customers who noticed, but never
lost a single paying account as a result of downtime. Maybe it's just picking
a market that can live without your thing for an hour if need be, but then
that's the goal we're talking about of a SaaS business that runs itself
without your intervention.

People worry about a lot of things before starting a business. They use things
like "what if the server goes down" and "what if my customers call me every
night at 3am" as excuses not to even try. But when you actually do try, you
find that none of those things you worried about end up happening.

That's not to say it's easy. But the things you're raising as issues just
aren't. In my experience.

~~~
stephenr
Servers absolutely do "go down", and it absolutely is an issue.

How this is even a discussion point is beyond me.

~~~
donovanm
Sure, but as a one man operation trying to get Google level reliability is out
of the budget.

~~~
stephenr
There's a lot of difference between running a webapp on a single unmaintained
server and "google level reliability"

------
oblib
The real problem with SaaS is that offline use is still sketchy and users
really do need that functionality. I'm working on an "Offline First" app now,
but it's not really offline "first" because "App Cache Sucks" and "Service
Workers" are not fully implemented yet.

For example, in my test with Safari, Chrome, and Firefox, on Mac OS 10.11 my
app using "App Cache" for offline use requires the user to click on a page
that loads a resource before it can be used offline, even after the "cache
manifest" has been updated and all the files downloaded. And Safari doesn't
support "Service Workers".

Beyond that, Safari doesn't really use the updated files when you update the
cache manifest. I have had to use the "Empty Cache" link under the "Develop"
menu to insure that when testing.

So, if a user empties their cache for whatever reason they break the app for
offline use so that's yet another issue that presents a problem.

That said, Service Workers do look promising and the apps I'm working on are
blazing fast and work great offline when everything is working as designed.

The age old problem with desktop apps is developing for multiple platforms.
You either spend the time and money to do that or you lose out on the market
you ignore.

There is another promising viable option that's been mostly overlooked...

That's shipping your app on a Raspberry Pi and integrating that into the
user's office. They can use it as a stand alone desktop PC or as app server
connected to their LAN, and/or the internet. This approach is getting a lot
easier, but since it's not being done yet it will require some hand holding
for most end users to integrate into their LAN or set it up as an internet
server.

To me, that is really the most interesting option when looking forward.

~~~
ajeet_dhaliwal
I haven't found offline to be much of a concern but I may encounter this in
the future so this is interesting to hear - what reasons makes offline
necessity so important?

In my experience security/privacy is the greatest concern. This is actually a
fairly big concern actually and for saas there's no solution other than
developing trust. In my case in particular, working on Tesults
([https://www.tesults.com](https://www.tesults.com)) we don't even store
customer's real data, it's all test/fake data and it's still a concern for
some so I'd say it's a huge problem compared with desktop/on premises.

~~~
oblib
As to offline concerns, it depends, I suppose, on how the app is used. Some of
my users work away from their offices and use the apps while in transit or on
a job site so internet access can be iffy.

Shoot, my access was down from last Friday afternoon until Tuesday afternoon.
CenturyLink kept telling me it was working and finally on Tuesday I insisted
they send a service tech out. They found and fixed it. I live in a rural area
so this is pretty common.

Think about how you could improve both your product and your customers
experience if you could tweak your software just for them and both the app and
all their data was onsite at their location?

I've given this a lot of thought and now view it as potentially the next big
shift in how software is designed and delivered and used. The advantages are
huge and the total hardware costs don't even amount to a half day's pay for a
decent developer.

------
stephenr
Without knowing what functionality you intend (i.e. if it's even
practical/reasonable for a web app - lets skip that and assume it _could_ work
for either environment), if you can see people in your segment will pay for
desktop apps on whichever platform(s) you intend to support, I'd say try that
approach.

Given your specific goals, a desktop app seems like the obvious choice to me -
the _only_ difference might be, if it's a multi-user app (let's say its an app
to vote on the colour scheme for an office renovation), you could also go the
'appliance' route, and build it as a web app, but distribute it as a VM image
that customers run on their own hardware.

------
tixocloud
I think you should start your approach with your target audience. Depending on
what you're planning to build and where your users are, that will drive your
decision as to whether you should build a desktop product or a SaaS product.

All the hype about desktop software being dead is fluff. Some products are
meant to be desktop and some products are meant to be SaaS. There are
advantages and disadvantages for both so you'll have to see what value you're
providing for your users.

