Live data from Hacker News

I want to convince you to have an on-premise offering

hivekit.io

21–30 of 93 posts

Re: I want to convince you to have an on-premise offering

#21
post #16

There's a lot of really great SaaS products that get no traction in companies I've worked in. Largely because "control your workflow" (a-la the toyota method) requires that a vendor is unable to change things on your behalf without your knowledge. "On-prem" is about being permitted to invest your own resources into ensuring that your $thing will work during the hours it needs to work and you can pour as much or as li…

On prem is easy if you are willing to pay 100K a year. Once 6 figures come into play, any SaaS company would be willing to do on-prem. I find that those complaining about on-prem are mostly small business customers that are more trouble than they are worth. Serious B2B companies won't blink at those prices.

Re: I want to convince you to have an on-premise offering

#22

Nice writeup and plenty of good points made. However, the author left out one huge item in terms of why On-Premise is challenging: ongoing support and maintenance. I was an engineer on a product that had an On-Premise (OP) offering. Some of our biggest moneymaker accounts were On-Premise and liked the product. The downside was that we had to have a dedicated team just for On-Prem stuff. I was one of the engineers on…

> There are super strict requirements that support personnel must be US citizens on US soil

That's not unique to either on-prem or the government, alas. Get involved with HIPAA, SOC2 or a few other funny acronyms and the restrictions around who may access production data or servers gets very tight indeed, even if you are a SAAS company.

Re: I want to convince you to have an on-premise offering

#23
post #5

"Third: Package it nicely. Ideally, your customer should be able to download a zip with an executable and some config files from a well designed enterprise page - or get a URL to a Docker Repo. When your on-premise version starts for the first time, it should set itself up as autonomously as possible: Check if it has the required access and permissions, connect to the database to set up tables, have sensible log outp…

I really disagree. On-Premise software is frequently bought by large customers with significant resources - including a competent ops team. Yes, there may be some initial handholding, but once things are up and running, there is little support necessary. Basically, if you want to build an on-premise offering, look at the way Nginx, Postgres, Redis and similar projects are packaged and do the same.

This highly depends on the industry… I worked on projects for large F500 companies who had neither ops nor where willing to spend resources… as I mentioned in another thread, on prem can be a world of pain… but it can also be a lot of fun if you have customers like you mentioned

Re: I want to convince you to have an on-premise offering

#24
post #9

Building an on-premise deployment requires a maturity of company that is quite rare for a startup to have: * It’s much easier to do on-prem if you do a monolith, or at least a small number of services. * You have to build and test your application against a range of OS and hardware combinations. You’ll almost certainly need to support RHEL, and probably Windows Server 20XX. Many companies won’t let you use Docker. *…

Seems like everything is rare for a startup to have. Productisation, infrastructure expertise? Why do anything?

I'm not saying that it's impossible, but it's the sort of thing that requires a technical cofounder with a fairly clear vision of what they want to achieve and with the knowledge and experience doing so.

I worked until recently at a traditional engineering industry focused startup company which decided to deploy a Python application on-premise to a big customer. From the use case it was very clear to me that an on-prem deployment of the software was likely to be on the cards, but there was nobody there in the non-technical leadership to say at the beginning "wait a second, maybe we shouldn't write this in Python for this use case".

Re: I want to convince you to have an on-premise offering

#25

ObNote that in standard English it's "premises," even for a single building. Some explanation here: https://ahdictionary.com/word/search.html?q=premises

TIL. I think it's a common mistake due to overcorrection; people tend to use singular words in compound adjectives (e.g. two-year contract).

Re: I want to convince you to have an on-premise offering

#26
Just bear in mind the kind of enterprise customers that tend to want on prem software _do not_ want to spend a lot of time deploying or maintaining it but the _do_ want you to support the old version that they're running (meaning security updates and probably fixes for major bugs). It's a very different world from your typical CI/CD SaaS product that deploys frequently and only supports the latest version of the software.

The company I'm with supports our releases for two years, most of our products release quarterly, and many of our customers are kind of annoyed because we release too often (in their eyes). We're looking at getting out of supporting the on-prem game, but personally I think it's unlikely because many of our clients are in government and defense.

Re: I want to convince you to have an on-premise offering

#27

Building an on-premise deployment requires a maturity of company that is quite rare for a startup to have: * It’s much easier to do on-prem if you do a monolith, or at least a small number of services. * You have to build and test your application against a range of OS and hardware combinations. You’ll almost certainly need to support RHEL, and probably Windows Server 20XX. Many companies won’t let you use Docker. *…

There are still plenty of customers who still run 32 bit windows 2000 or xp installations :( on prem support is often a world of pain :(

Yep. In one past job we had an issue with a large well-known semiconductor company who were very angry at us for releasing a version of the software compiled on RHEL7 despite RHEL6 having been out of support for a long time by that point. We ended up having to spin up a VM and compile them a bespoke version using an old enough version of glibc that they could still run it.

Re: I want to convince you to have an on-premise offering

#28
On-premise is a sales & tech support minefield. That's why SaaS vendors don't like it. No matter how well documented an on-premise solution is, the customers won't read the docs and when something goes wrong the customer will be unhappy and blame the vendor. And unhappy customers are bad for business.

This is why consumer electronics products have those stickers that warn you you void the warranty by opening up the device. It's because nobody wants to deal with those customers who open up their device, break something, and then demand a replacement because the product is defective.

Re: I want to convince you to have an on-premise offering

#29
I just hope everybody knows that "on-prem" means about 10,000 things when it comes to installs and integrations. And that's why small b2b teams should focus on SaaS first. You don't want to build 10k versions of your product. Just one. It's easier to iterate to get to PMF, and to maintain once you reach it. When enterprise customers ask for on-prem, that is sometimes a signal that they a) want lots of consulting professional services (sometimes free), and b) are not sophisticated customers. You want to serve the laggards last, once you can take cash flow from a more efficiently sold product and adapt it to idiosyncratic environments.
Post reply on HN