Hacker News new | ask | show | jobs
by JakeWesorick 2297 days ago
Lots of the SaaS products we use mean we don't have to hire more employees. So I'm not sure if dollars per employee is a meaningful stat.
4 comments

For a lot of companies I think it's actually the key to being able to expand and hire in the first place. Most startups aren't choosing between "should I hire someone to do this, or buy a solution?"--they're choosing between "Can I do this by buying a solution or do we go without? (either this, or something else because we need to build this)"
Just an interesting idea, if no one wants to have employees (lets face it, they are a mess, they waste oxygen, they fart, producing CO2, are corona virus friendly, produce road accidents... and you need to pay them so they can live) maybe everyone is having wrong bussiness plan. Whole world should transform to produce only SAAS products for SAAS people as they are the only customers who will in long term still have money to buy SAAS. /s

This is becoming a joke.

In my whole life I didnt buy a one single software product, that is based on subscription model (unless necessary as there are ongoing costs for its development like antiviruses (which I dont use, but this is another story)). Why? As it tells me, the product is at the end of its inovative phase and has nothing more to offer. I am fine with paying for update hunderds of dollars if, and only if, i need the added functionality. Or in different words Microsoft Office 97 was more than enough for 99% of its users (I dare you to install it and find something that you miss, it wasn't perfect but it did get the job done).

But there is more. I wont pay for cloud products either. Why? I believe that what is giving you the "edge" is your knowlidge. Using, for instance, gmail is taking you the chance to increase it. Yeah sure, time to market, but if you stick to DIY logic, this is not going to be a problem (I can set up a mail server with left hand while coding with right hand... and offer it as a SAAS to those that ignore DIY and earn extra bucks ;) /s ). If you ignore the lack of knowlidge, you will end up always paying to someone else or stuck in a problem that wouldn't be a problem if you wouldn't be ignoring it for so long. Not to even go into lack of inovation and reinventing / copying the solutions that were solved long time ago, but this is just another story.

I like your first sentence, but unsarcastically. Companies should always strive to do more with fewer employees by automating them away.

As for the rest of your argument, most people are not like you, as they will not want to spend time setting up their own mail server. For companies this is doubly true, as they will likely spend more money setting it up, maintaining it, and upgrading it, than the subscription actually costs.

> Companies should always strive to do more with fewer employees by automating them away.

I wonder if those same companies intend to socialize the wealth generated by their automation.

Of course not, there is no incentive to do so. Until there is, nothing will change. I am all for socialization of wealth, as money in circulation boosts the economy more than hoarding it, but I just don't understand how people can say that companies should (morally) socialize their wealth "out of the goodness of their hearts" without some incentive. Companies, like all organizations of individual agents, do not have collective morals. They are merely machinations that have the sole fitness function of increasing wealth, at whatever cost. If we take this to be true, why exactly would, without another fitness function, a company socialize wealth?
I think we've reached peak Hacker News. This is now looking like Slashdot.
I'd actually prefer slashdot's moderation/meta moderation model to the one used by HN, though it's hard to fault the job dang and co. are doing with their hands-on approach.
Horizontal integration of business processes means a lot of external stakeholders have you by the balls.
This. Bunch of crappy apps which meet the minimum rqt to keep you in the ecosystem. Teams is the business equivalent of imessage. Keeps people on msft products vs. switching platforms. That plus finance folks cant not have their Excel for their 30-tab whatevers.
You've attached a sarcasm tag to your first paragraph, but I do think the market is actually going there. Notice how many products around you get replaced by services.

I don't like it at all.

Hmm, there are many companies where what you proposed make sense. But there are also many that I think it's hard to debate that SaaS doesn't offer value.

Running the mail server is simple enough, but then you need to set up storage. Emails are sensitive and often can't afford to lose. Then you need to set up backs, monitor and regularly test DR scenarios to see if your failovers, recovery plans are operational. Of course you need to maintain your data centers as well if you don't want subscriptions.

Then think of login. Employees don't want to log in to 15 different software. So they are going to ask for SSO. You are going to have to deploy and maintain something like active directory. Sometimes they need to be maintained across networks between different offices that are far from each other. After all this, you will still have to buy support packages from principle vendors for times when things go wrong (and they go wrong all the time when you host your own stuff). Shit escalates mate.

But this work scales better than linearly. One sysadmin, if doing their job properly, can configure a robust backup solution once and it will apply to many different programs. Machines in a DC can be set up once and host many programs.

Login is surely one of the best arguments for non-SaaS solutions. SSO is a total mess in the SaaS world. Everyone ends up with a billion passwords that they manage individually, change at different times, have to use a password manager to keep track of (but they all use different ones), etc. Active Directory is actually a solution to that which got lost in the move to SaaS-in-the-cloud.

It feels like the more meaningful measure would be the change in profit over the change in SaaS utilization.
No, total cost would be a better measure since there is no per-person cost to the SaaS provider.

If you have 10,000 employees that's $100M per year in expenses. If you're just renting payroll, purchasing, etc software for that price it'd be far cheaper to roll your own, or pay a few people to work on OSS full time.

> If you're just renting payroll, purchasing, etc software for that price it'd be far cheaper to roll your own, or pay a few people to work on OSS full time.

This is the kind of hubris I come to this site for.

Hubris is half of software development ;)
Is the other half the hole of legacy support you dig yourself into supporting the bad decisions and naive assumptions you made driving with that hubris?
Nah that's when you leave the company and leave some intern to clean it up so they can develop their own sense of hubris over your bad decisions. And the cycle repeats.
Read up on the history Chrysler Comprehensive Compensation System (C3). The team worked for 7 years and although they achieved some technical goals they never managed to deliver a working payroll system.

https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...

Payroll is harder than it looks due to all the edge cases. For example, it is literally possible for an employee to have so many payroll deductions including court-ordered wage garnishment that net pay would be negative. How do you handle that in all legal jurisdictions where the company operates?

> For example, it is literally possible for an employee to have so many payroll deductions including court-ordered wage garnishment that net pay would be negative. How do you handle that in all legal jurisdictions where the company operates?

By issuing a error and demanding that a human deal with it. Obviously.

Surely you jest? If that was a serious comment then you obviously have no understanding of the business and legal requirements for payroll systems.
If you're legally required do your payroll with a buggy computer system rather than manually (and not even "this specific buggy computer that we gave you", just any old buggy piece of crap), then, uh, I don't really know what to say to that. My condolences, I guess?

If you mean it's impractical and error-prone to do payroll manually, well that's the point of automating >99.999% of it. For the remaining <0.001%, someone is going to have decide how to deal with it, and I'm sceptical that a programmer seven years ago will know better than a lawyer today what the legal requirements today are.

The level of aggressive ignorance in HN comments can be quite shocking. There is no legal requirement to use any particular payroll system. The payroll rules are written by domain experts including lawyers and others, and encoded into rules engines.
Well, how do existing manual systems deal with it? Why not just make do with partial automation and fall back on the existing methods for those thorny legal edge cases?
Except for the smallest local businesses, there is literally no such thing as existing manual systems anymore. It's simply not possible to do manual payroll while maintaining compliance with laws, regulations, civil orders, labor contracts, and company policies. Every significant enterprise has either built up a custom automated system over decades, or has customized a commercial ERP payroll module, or outsourced the entire thing to a specialized payroll company.

You could argue that payroll shouldn't be so complex but that's the reality of it today.

Rolling your own payroll is about as good an idea as rolling your own crypto.
However, if you roll your own crypto payroll, the risk of one project perfectly offsets that of the other. It's a perfect hedge.
Ah, but what if they add rather than cancel?
Two negatives make a positive, right?
It depends whether payroll theft is part of your business model, or something you're trying to avoid.
One large company (170k employees) I worked at switched from an in house payroll system to an external month.

Second month was a disaster in the end they had to physically cut the tape on the last remaining partially destroyed copy - about 20% got paid on time.

Switching a large enterprise software system is almost as time consuming, expensive, and error prone as developing a replacement in-house. You would have experienced substantial problems even if it was in-house -> in-house-rewrite or external->in-house or external-a -> external-b.
If rolling your own crypto, you mean cryptocoin, that sounds like a great idea to increase wealth :)
Cryptography not cryptocurrency.
That was the joke.
We wanted to build our own payroll system, but engineering is too busy milking the cows to restock the fridge to learn the tax code for multiple countries.
Has anyone thought about asking engineering to implement or build an interface for someone else (business side?) to manage country level differences in taxes?
I would be interested in engineering something like this, my email is in my profile if you want to share more.