Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> You buy a SaaS product then you pay them to install, configure, customize it.

Ok, hold up. That is not a SaaS app lol. That is an on-prem installation. Very very very very much not the same thing.

The entire point of SaaS is you don't install it on prem. SaaS directly competes with what you're talking about.

Before you go declaring an industry is dead, at least understand what it is.

> My work supports a non-software industry. Every minute that I save of user's time translates into more time they can use to make money.

Sure. The corollary to that is every minute your app doesn't work you cost them money. If you fuck up and store protected data the wrong way or lose data because it tipped over, you're also costing them money.

Replacing some tinkertoy nobody relies on is easy. If your app is in the hot path, congrats, you're now critical infrastructure lol. This is the Bad Place.

> When I quit, the app can be easily fixed because it's all standard technologies that lots of people know.

I can tell you have never had to clean up one of these apps. Knowing the technology is not the issue. It's figuring out all the random decisions and details and load-bearing parts and reverse engineering someone's weird tooling without breaking things. It sucks real bad because you don't know what you don't know.

> Just try and switch away from your cloud SaaS product. You might not even be able to get your data out

Sure you can. Getting the data is the easy part. In the very worst case, you might have to pay them or get someone in management to scream at them, but it's the easiest part of that kind of project.

It's the rest of that kind of project that's tricky. Replacing a critical live system without downtime is Srs Bizness.





> Ok, hold up. That is not a SaaS app lol. That is an on-prem installation. Very very very very much not the same thing.

I didn't mean to imply on-prem. "Install" was the wrong word; call that "onboarding" instead. There is always some integration component as well because nothing lives entirely on it's own. Some SaaS providers are really good; no complaints on this part. Some are terrible. I believe one new vendor is going to try and charge us almost $100,000 to integrate their product with our other products. The entire purpose of this product is the integration. This is one I'm pushing to do internally because it's so fiddly.

> The corollary to that is every minute your app doesn't work you cost them money. If you fuck up and store protected data the wrong way or lose data because it tipped over, you're also costing them money.

So? You seem to think SaaS software doesn't go down, break it weird ways, get slow for no reason, etc. Across everything we probably had half a dozen small outages last month. But none of our internal (also cloud) products went down at all. Hell, one of the biggest most common SaaS products in our industry released an undocumented change last month to their API that subtly returned incorrect results. As far as I can tell, they still haven't acknowledged it.

I'm not saying we don't have bugs or bad things don't happen but I don't see why you think that externally purchased software is automatically better.

> I can tell you have never had to clean up one of these apps. Knowing the technology is not the issue.

Good developers produce good results. I have a new intern on my team who's currently still in school and she's absolutely killing it working on our apps. So maybe the problem isn't internal development, it's just shitty developers. Those exist in SaaS products as well; I look at some of their shit and I wonder what we are paying for. It can be well hidden behind nice marketing and big brands but it's still crap.

One vendor tried to sell us a product that was actually sneakily split into two pieces -- one developed in North American in .NET and the other half in India in PHP! They nightly sync the data between them. At the time, we had multiple products for this job and we were looking for one integrated product to replace them. I just happened to notice when looking at the URLs during the sale pitch and that's what caused them to spill the beans. We didn't buy that product.

While a lot of our internal development is complete products, a good chunk is actually filling out the functionality holes or working around bugs in our SaaS products.

> Sure you can. Getting the data is the easy part.

The last one we dropped, we definitely didn't get our data out. In fact, as soon as we cancelled the contract (3 month lead time) we were basically dead to them.


> I'm not saying we don't have bugs or bad things don't happen but I don't see why you think that externally purchased software is automatically better

If you staff an entire team to build apps, update, maintain and deploy changes to them, and run a call rotation, and that's all you do, there's no problem. You just have an internal development team. That's completely fine.

What's not fine is the people going "how hard could it be to replace Y" and slapping something together. Those sort of skunkworks projects have a couple common common failure modes:

1. the project fails after a lot of wasted effort 2. the project succeeds...but is never productionized. The person who wrote it is now stuck writing it forever. Which they might like, but it's miserable if they quit or retired or get hit by a bus aka the bus factor.

If the bus factor is one, that is pretty much always pain.

The point of SaaS and service-contract type enterprise software is not that they are perfect and great and not buggy. Enterprise software sucks a lot. SaaS is usually "you get what you get".

The point is you can't halfass it. Either you go whole ass and staff out a big enough development team (with all the expense and difficulties implied) or you go none ass and buy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: