Comment by Silhouette | Hacker News Reader

Comment by Silhouette | Hacker News Reader

Parent Full thread

Then what happens is somebody making $100+/hour would spend several hours to do the job that would be covered by a tool that costs under $50/month.

It's never that simple, though, is it? Suppose that tool solves a problem that a $100/hour employee would have solved manually in a day. How long did it take the employee to identify and choose the tool, arrange the purchase, and then learn to solve the problem using it? Probably a few hours too. So that $50/month tool had better be useful for replacing that job several times in a year or it's unlikely to be a net win in terms of time and money. It's certainly possible that good tools are far better than that cost/benefit ratio and using them is easily justified, but I'm guessing that in these organisations with hundreds of different SaaS subscriptions only a few of them are in that class.

Of course the elephant in the room is that there used to be another alternative, which was buying a tool outright for say $1,000 and then using it indefinitely, which would be a financial win compared to an equivalent $50/month SaaS tool in well under two years. Yes, there are factors like CAPEX vs. OPEX to consider so this isn't so simple either, but ultimately paying much more money for the same thing is still paying much more money, however you slice it.

The other gain you get from having the employee build the tool is that now the employee is better at building these tools, so you fundamentally have a better employee than the one that had to spend the time learning the non-transferable one-off tool.

Which is valuable, if your company builds those tools... otherwise you just trained your employee to work at that SaaS vendor.

On the other side of that equation, what you would hope is that your $50/month is buying you a subscription to steadily increased functionality over time. That's something your $1000 up-front payment wouldn't get you, and it helps offset the initial on-boarding costs. It's also probably true that once your one employee has gone through the selection, learning, and purchasing process, getting subsequent users on-boarded is much quicker, because there's someone sat next to them to say "just do it this way".

On the other side of that equation, what you would hope is that your $50/month is buying you a subscription to steadily increased functionality over time.

Some people might hope for that. Personally, if I'm buying a tool for professional use, I want to choose my preferred one and then have it be reliable and future-proof. Things like security updates are one thing, but the last thing I want is random changes in functionality or UI being forced on me.

This worked just fine in the traditional model where you bought a version of some software, and then if there was another version released later with something more that you wanted and adequate compatibility, you bought the upgrade too. The user gets stability and new developments if they want them. The developer gets paid for new developments, though only if they are actually valuable to users. No-one gets forced into anything unexpected changing, or going missing, or breaking compatibility.

Tragically, the whole SaaS, insta-deploy anything we feel like culture that has evolved in recent years has utterly destroyed that stability and reliability. I regard this as possibly the biggest retrograde step in the history of personal computing (and that "possibly" is mostly because the walled garden culture that has also become so powerful in recent years might be a larger backward step).

I don't disagree: there's a reason I prefer Debian Stable on my servers. But when done well, and in the right place, it can be a worthwhile avenue. Github is a pretty good example: they've not stood still (ok, they also haven't moved that fast either), but the core of what worked 10 years ago still works today.

Reply on news.ycombinator.com