Hacker News Reader

You raise a valid point. I think what it ultimately boils down to is to give your users the feeling that even if your service stops (and there are many reasons why it could), all the hours they put into your product are not lost. The criteria I listed are factors after all, and how I factor them in depends on the available alternatives and the work I will put into it myself and whether a online-solution actually makes sense there.

A good example are note taking apps. My notes should be private and I want to be able to read them ten years later. For me your product would need to add something valuable to this that a filesystem and a bunch of files that I synchronize myself can't do. As for now there is no note-taking app I found where the benifits outweight the preceived loss of privacy and reliability. The online thing can make sense, but syncing my phone with Nextcloud works even better, so I don't really see why I'd need it.

This is potentially different with an app like yours, because the benefits of using your app vs using e.g. a spreadsheet seem truly tangible. Using JSON and allowing export at any time is a huge plus. Having it a web-only kinda makes sense, as your app seems to be geared toward teams (and any serious parts managment makes a lot more sense when you are not alone).

While the additional work that would have to go into documentation and programming if you were to offer this as a self-hosted variant is non-trivial, from my standpoint offering the option to self-host can also be seen as an act of communicating: "Don't worry, whatever happens to this project, you will not lose the time invested".

I am not obsessed with this kind of reliability, but I just want to avoid the future hassle of having to deal with this, especially when I put a lot of time into it.

That's not an unreasonable assumption, right? It's just an extrapolation from how desktop/local software has always worked. Demanding a subscription for something that doesn't, technically, need any maintenance or ongoing costs on your part is a relatively new thing. Yes, of course, people expect a stream of updates these days for security if nothing else. But you could sell a version of your app that's static - urgent bug fixes only - and then sell it to them again when a new major version is released, old school style.

A lot of devs have moved away from that because subscriptions provide better peace of mind and smooth out the income stream, but it's not clear it's really better for users. Certainly they lose some optionality and there's less market pressure on the suppliers to ship big new features that motivate upgrades.

I believe a one-time fee for software is fundamentally unsustainable, and a relic of the past, when we had no networking and our operating systems did not evolve quickly. Every piece of software needs maintenance and support.

Also, a lot of people seem to forget that even if we pretended that support isn't necessary, just the existence of a standalone version imposes ongoing costs: there is more testing, and the scope of changes that can be made is more limited.

Subscriptions are the only sustainable way of maintaining software in the long term. We can either accept that and move on, or keep pretending we "buy" software that will work forever, and then pay every year for a "major new version", which apart from the fundamentally fictional nature of the deal, results in developers cramming in new and unnecessary features instead of focusing on software quality.

> a relic of the past

I could be a potential customer, since my company works on the embedded market and we design and manufacture all our PCBs.

There was a time the company has a moment of big growth, and we looked into solutions like yours. The question was: what would happen if this guy (not specifically you, others similar to you) closes tomorrow? The answer generally was: you can export all your data and then you feed it into your local database. So the matter ended with: OK, we'll stick with our current database. Goodbye.

At the end of the day we saw such services as a glorified data-entry/store/search database that hardly will suffer many modifications or require updates, and since pretty much of our distributors (apart from mouser, digikey, avnet, etc.) won't support data exchange and PO/Offers will be negotiated in the traditional way (also negotiating price reductions). No need for VC funding or anything else.

We need to be able to open an schematic/BOM/whatever in 10 years and be able to operate as if it was just created yesterday, so much of the software we use is "a relic of the past" (in SaaS vendors eyes), but effective and "the way is supposed to be".

Online/cloud or subscription-based CADs? Also kicked out of the door.

With this I want to say that people like the article author seem to live in a little box, thinking on what they use daily as web-service-saas-whatever developers, without realizing the world is much bigger than they think it is.

"...I believe a one-time fee for software is fundamentally unsustainable..."

It is pretty much sustainable. Except few natural cases SAAS is just a wet dream of vendors trying to have constant revenue stream the easy way.

If software needs support/new features you pay for upgrades. Or not if the old version works just fine for you. In my case I use tons of software for which I only paid once (sometimes I pay for upgrades as well). If I had to pay monthly fee for each title I use I'd be spending insane amount of money.

> I believe a one-time fee for software is fundamentally unsustainable

I strongly disagree. I have always, up to this day, sold software on that model, and I will probably always do so. There's nothing unsustainable about it.

What is true is that rent-seeking can be much more profitable. But fortunately for those of us who find it very distasteful, it's not necessary.

what do you do when you've saturated the market?

one-time fee only works if you have a constant stream of new customers into your niche that is sufficient to pay your salary.

with upgrades or subscriptions you can have a group of users who love what you do and are happy to support you without having to hope for new users and constantly market to get them.

> what do you do when you've saturated the market?

If I want to continue active development on it, then I sell upgrades. If not, then I'll continue to do free maintenance releases, but my main business will be from different products.

> one-time fee only works if you have a constant stream of new customers into your niche that is sufficient to pay your salary.

You can continue to get income from existing customers. You just have to provide real value to them in exchange for it.

Worth a thought. How does desktop software achieve backwards compatibility? For example Libreoffice can work with arbitrary datastores from the 1990's. Meanwhile with modern web based software we struggle to maintain compatibility within a single datastore.

Libre Office is underrated.

We are working on a self-hosted Nextcloud, Onlyoffice solution. Specs here https://ba.net/office

> Maintaining a self-hosted solution is an enormous cost, which most people forget about. You need to create, document, maintain and support an entirely different version of your software (single-user, no billing/invoicing, different email sending, different rights system, etc).

I think you're not looking at this from a local-first perspective. From that perspective you can have the same app locally as on the server. There's only one version. Yes, it does require more planning and atypical approaches, but it's 100% doable.

I'm in the planning stage of a local first web-app that will have a server side version, and it's literally going to be the exact same code on both.

I can see some arguments for having _slight_ differences between server and client software but nothing that isn't easy for a solo-dev to maintain. Mostly set it up once and never touch it again type things.

thinking local-first has fundamentally changed some decisions i normally make without thinking for web apps, but I think it will absolutely be worth it for my users in the end.

Very exciting. Could you please elaborate on what technology stack you're planning to use? Language, frameworks, etc.

And how do you plan to achieve that? What will be running on a server side? Will it be headless or server-rendered?

Do you have a GitHub repo with that project?

Sorry for lots of questions and thanks in advance!

> The best part is that many people think that an on-premises version should be less expensive than the online version, and come without a subscription.

Which makes sense IMHO, provided they are not expecting any updates to their on-prem installation. It can just be a fork of your current codebase with no new features or warranty. Maybe you can include some terms for critical security updates but that is about it.

But that, unfortunately, is entirely unrealistic. When I discover critical bugs, I can't leave users out in the cold.

I believe that the whole concept of "software without support" is fundamentally flawed.

Agreed. But if a user agrees to be left "out in the cold", you should allow him to. Given that it is not very costly for you to prepare your software for on-prem, it maybe a win-win for all the parties involved.

> Given that it is not very costly for you to prepare your software for on-prem

I have been asserting exactly the opposite in this thread.

Assuming you are not providing any updates (not even security critical ones for argument's sake), you only need to package and add documentation for an on-prem installation. Why is it so costly?

> you only need to package and add documentation

None of which are insignificant.

In addition to that you must now support (and test for) a million configurations, rather than just one.

FUD. Among my products I have desktop software. Sure I got some pains upon initial release but it's been literally years since I really needed to test "for million configurations".

I also have experience developing and maintaining cloud solutions. Total amount of work that goes into large cloud apps and amount of things things that can brake or not work properly is fairly impressive. Definitely not any less then on premises

I think we as engineers owe our users bug fixes, because we messed up at some point. However new functionality or email/phone support? Well, this is what people are not entitled for.

Well, this is what people are not entitled for.

But they will expect it.

And pay for upgrades

Only for a limited time though, releasinga piece of software shouldn't be a lifetime commitment.

And what if your software is mature and you do not discover any critical bugs?

I sell nothing but on-prem software, and have never left my customers "out in the cold" or without support.

A lot of software doesn’t have to be “hosted” anywhere. The first question I usually have when trying out some web-based software is: “Why on earth can’t this be a native application that I just download and run? Why are they shoving a web browser and server into this thing?” With a cross-platform native application, you bypass the whole on-prem vs hosted question entirely.

I wonder how often the answer is simply “We know lots of JavaScript programmers and not a lot of Qt programmers.” Talk about the tail wagging the dog.

As a user, I strongly favor software I buy once, download, and run as-is, forever, untethered to the Internet.

i agree but would add that there are a number of reasons why your browser as the client is a better long term strategy that minimizes maintenance. Unless you want a really generic geeky bare-bones UI. Native UI toolkits don't have a long lifespan. You constantly need to tweak what you've built for changes in the latest version of the OS.

However, that doesn't mean it needs to be "hosted" anywhere. It's trivial to make an app run a little web server that they access with their browser instead of a native or QT UI.

Browser based interfaces are an excellent bet (probably the best bet) for "run as-is, forever" or as close to "forever" as we can reasonably get right now.

> Believe me, if you don't have VC money to burn, you will not be experimenting with CRDTs and synchronizing distributed data from a multitude of versions of your application.

While you're right that doing this is less convenient, I can say with the personal experience of developing a few such projects on a shoestring that doing this isn't as hard or expensive as you're making out. It's entirely doable. It just requires thoughtful engineering.