11 ms·

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

77 points by max_sendfeld 3y ago

ocdtrekkie 3y ago
If I have a choice between a company that sells SaaS and a company that offers an on-prem option, the latter gets my business. If you aren't confident enough in your software to hand me that code in an install file, I guarantee I don't want to rely on your janky startup's hacked-together spaghetti.
rco8786 3y ago
As the pendulum swings :) I love the idea of on-premise for small startups (or solo startups) because it shifts the operational/oncall burden to the customer. Also "on-premise" in 2023 can easily mean something deployable to a customer's AWS/Azure/GCP account.
- wolframhempel 3y ago
  I think that's actually exactly right. On-Premise might arguably be a wrong name - but for most customers it just means "software that you can run yourself in an environment that you control". And that environment is most often a cloud deployment.
- deleted 3y ago
  [deleted]
hyggetrold 3y ago
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 that team. We had to develop custom management interfaces for the software that were only deployed in an On-Premise environment. It wasn't crazy hard or anything but it was time and effort. Upgrades and installation were also a big track of work unto themselves. When you deploy into an On-Premise environment you are completely at the mercy of the clients infrastructure. One support call I did was clocked at 14 hours - there are so many things that can come up. Plus there's the whole hassle of actually getting the calls scheduled and making sure clients aren't too many versions behind. Sometimes we had to spend a lot of time waiting on support calls because the customer didn't have their stuff together. Like sitting and waiting for a network team to open up the firewall so that bits could be downloaded from our distribution server. And of course the firewall had to be closed up right afterwards, so this was a common thing. Another time we spent weeks troubleshooting a client installation. In the end it turned out that the client had our software talking to two different internal NTP servers which were slightly out of sync, which caused our SSO/SAML integration to break. Database migrations were also challenging - in a cloud environment you often have flexibility to migrate things live while the system is running. But often with the on-premise upgrades, you had to take the whole system down while the migration was running (back to the 14 hour support call). This could mean scheduling the support calls at really weird hours. On-premise also has challenges if you start selling to the US government, especially defense. There are super strict requirements that support personnel must be US citizens on US soil - so hopefully you have more than one person on the team meeting this requirement! All in all, I am not a detractor of offering an On-Prem solution. It can be a real differentiator and it will open a lot of doors. There are some companies that simply won't buy SaaS, either due to internal or regulatory reasons. Once you land these clients it can be very lucrative and long-term. But, it almost always requires dedicated staff to support and manage.
- zdragnar 3y ago
  > 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.
dangus 3y ago
Big enterprise deals can be a huge burden for a small company. They’re demanding customers and they will probably pressure you into making product customizations that don’t apply to the rest of your target audience. Enterprise customers tend to have more edge cases and scaling requirements, along with a huge workforce with more difficult lines of communication. Anecdotally, they seem to need more follow-ups and hand-holding than smaller nimble companies. An ideal customer is often one that subscribes, pays their bill, and rarely asks you for help. Your product already solves their problem out of the box without needing to go down any rabbit holes.
physicsguy 3y ago
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. * Your software need to be tolerant of infrequent updates. Customers expect some level of stability in practice. * You need to integrate licensing checks. * You need to build an installer (that works out of the box…) * You’ll need to agnostically support the common parts of SAML/OpenID for Auth only, and not rely on any bespoke features from a commercial provider like Auth0 or AzureAD.
- bitschubser_ 3y ago
  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 :(
  - physicsguy 3y ago
    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.
- dijit 3y ago
  Seems like everything is rare for a startup to have. Productisation, infrastructure expertise? Why do anything?
  - physicsguy 3y ago
    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".
macrael 3y ago
"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 output etc." LOL that paragraph hides all of it. On prem means that someone is administering your application that does not understand it. Which means YOU are administering it but via slacking with your customers infra engineers rather than through your own control plane. The article is right that there are customers who require this and if you want them you'll have to figure this out, but it is a huge pain in the ass and should be avoided if at all possible.
- chatmasta 3y ago
  Over 40% of the Web is deployed this way. Wordpress installation is basically "upload some files, complete installation GUI, and then get started." There's no reason other products couldn't do this as well, even those with a complicated stack that requires provisioning cloud resources (or equivalently, SSH'ing into servers on the local network or calling private cloud API endpoints). If you can deploy a commit from a pipeline, then you can make a self-hosted bootstrappable installer for your users. The installer could be a tiny shim running on the user's laptop that's responsible for bootstrapping the rest of the infrastructure and then deleting itself after redirecting the user to the cluster admin panel. The trick is to make it smooth, so even non-technical users can provision and eventually administer a secure, self-updating cluster as easily as they can keep their iPhone up to date. Walk them through the process of getting AWS credentials. Heck, scrape and script the login flows if that makes it smoother (it's their computer running the code so who cares?). Ask the user the minimal questions needed to fill the config. Once all that's in place, trigger your deployment scripts on the cluster, to pull images from a container registry or whatever. Wait for it to be up and running. When the cluster's up, redirect them to its admin panel that's more sophisticated and controlled by you. Let them check for updates, install plugins, run common operations (like "restart," etc). Then just don't ship broken code, make sure your scaling policies work (or at least that they work well enough to avoid phone calls from customers that don't make you any money). And boom you've got a nice product. I'm not saying it's easy. But if you already have automated deployments (you do have automated deployments, right?), then it's not that many extra steps. Productizing it is hard but can be done.
nathanaldensr 3y ago
*on-premises
keithwinstein 3y ago
ObNote that in standard English it's "premises," even for a single building. Some explanation here: https://ahdictionary.com/word/search.html?q=premises https://ahdictionary.com/word/search.html?q=premises
- pesfandiar 3y ago
  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).
- Mindless2112 3y ago
  Yes, please. "Premise" means something entirely different: "A statement that is assumed to be true and from which a conclusion can be drawn."
bob1029 3y ago
We are selling SaaS/B2B and are looking to support both modes moving forward. Our (my) preference is heavily tilted towards cloud, but we've modeled things to minimize our pain for on-prem. Path A: Run a windows server VM and SQL Server somewhere in our customer's infrastructure. Our customer is 100% responsible for the health of these items and provides them as a service to us. Our customer has to notify us of any infra or app issues reactively. Path B: We operate as custodians in our customer's Azure tenant. We deploy our software as a Function app and use Azure SQL. We are 100% responsible for the health of everything. Our customer is notified proactively of any issues. To support both paths, we have two different executable project types (console app and azure function app) that consume a common library type. Only the barest boilerplate code actually changes between on-prem and cloud. 99% of the difference is HTTP Trigger function vs AspNetCore hosting syntax. Everything else is identical. We work with small US banks and we haven't found one that is total stonewall against moving to cloud. Many are cautious but open. The #1 concern is the PII/data. We've been working with a few angles to cast that in a more realistic light. Most of our customers have had some degree of an incident with on-prem infrastructure that could have been made impossible if business was being conducted via a cloud provider.
- dehugger 3y ago
  Path C: Sell installable software with documentation (and training courses if you are big enough). You'll still get yearly revenue via license fees. I don't know why this went out of fashion but it works just fine. Your customers clearly don't want you to manage the infrastructure, based on your comment. Sell them what they want. If the issue is that your system is so complex that a reasonably trained admin cannot manage it, you should probably fix that.
  - bob1029 3y ago
    If you want to go all the way into the rabbit hole: the entire purpose of our system is to provide interfaces into various lines of our customer's businesses. What our customers want is a technology partner who can adapt to their changing business needs over time. A one time cdrom+pdf distribution unfortunately will not get the job done in this case. Our customers are paying for a business outcome. Our software is just a fraction of that puzzle.
dijit 3y ago
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 little into the problem as you deem necessary. If you use a SaaS you must somehow figure out how that factors into their pricing model and it's still largely their whim, and worse: they will still change things without notice. It's also true that a lot of companies do not assume that the internet is always available. Getting 100Gb/s to a server room is easy for 500 people in an office building. But getting 100Gb/s to your SaaS platform might not even be possible without rearchitecting. (IE: Perforce in game dev, usually on-prem.)
- KRAKRISMOTT 3y ago
  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.
  - citrin_ru 3y ago
    SaaS and on-prem software are very different in how they are developed and require different expertise. Even if you would pay a SaaS company enough so they will be willing to adapt their SaaS to on-prem it will be a mediocre product.
  - arccy 3y ago
    try 10x that if your product is any degree of nontrivial
  - marcosdumay 3y ago
    I've rejected plenty of >100k a year proposals because there wasn't an on-premises alternative. (And also another batch because despite being willing to pay yearly for upgrades and support, there wasn't an option of retaining the license in perpetuity.)
tapoxi 3y ago
I work for a Healthcare SaaS, and our requirements around where data can live are so strict we can only use applications that we can self-host. For us this means Helm chart and installed on k8s. I'm honestly shocked that Sentry, for example, doesn't have a self-hosted enterprise option. We're all terrified of PHI being caught in a stack trace and sneaking through any PHI-scrubbing feature. We had to move off of Confluent because CFK's pricing is outrageous compared to Confluent Cloud. It's clearly designed to nudge customers towards Cloud, but we can't use it due to contractual requirements with customers. Everyone is so anxious about breaches that even a BAA doesn't cut it anymore. So there's absolutely a market for this kind of stuff.
- supriyo-biswas 3y ago
  For self hosted Sentry, look at Glitchtip (https://gitlab.com/glitchtip/glitchtip-backend/-/blob/master/README.md https://gitlab.com/glitchtip/glitchtip-backend/-/blob/master...)
montereynack 3y ago
Since this is a topic that’s near and dear to my heart, going to quickly plug my own startup that’s doing exclusively this: www.sentineldevices.com. We make industrial equipment smart enough to self-monitor and self-report issues using AI, but we are specialized in making AI that does EVERYTHING (including training) on embedded devices (think something only marginally more powerful than an RPi 4) so we never call out to a server. As the article notes, a big challenge has been making the AI and all support software resilient and able to “bounce back” from random occurrences in industrial environments (which can be extremely unpredictable and unique). Also as the article notes, this pretty handily opens up the Defense market since we don’t need to clear a cloud component. Feel free to reach out at forrest@sentineldevices.com if you’d like to chat. We’re building and trying to take people on part-time if anyone’s interested in this space! Also if anyone just wants to talk about challenges in the space I’m happy to, HN usually gives really great conversation partners.
Merad 3y ago
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.
- physicsguy 3y ago
  When I worked for a big enterprise company writing simulation software, we did quarterly or bi-yearly releases, but the defense clients wanted to run their own verification and validation tests generally, so they maybe upgraded once every 2 or 3 years. When I went to work at a University as a research software engineer, a particularly memorable incident was a research group getting very angry that we were upgrading the cluster to CentOS 7 thus meaning the ancient version of COMSOL they were contractually obliged to use in a contract with Rolls Royce would no longer run at all. We ended up getting something working using Singularity but it was very painful.
- gomox 3y ago
  We copied the Ubuntu release schedule to deal with this (rolling release for cloud, LTS + security/bugs for on prem). Its not particularly painful (but we don't provide support for 2 full years).
CKMo 3y ago
Not everything should be on-prem, but some things should be. Access control comes to mind
gizmo 3y ago
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.
- stuff4ben 3y ago
  This is where the sales team hands it over to the consulting arm. You charge for that as well as the licensing. It's why companies like IBM are still around :)
blueyes 3y ago
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.
gomox 3y ago
Our company does this and it has become a competitive advantage allowing us to get into customers that would otherwise be out of reach. Pretty much every single current offering is SaaS-only so if you want a modern product on prem we're essentially the only game in town. Operationally speaking we built the products from the ground up to be available either way (at the time, it was a less contrarian take). The resulting cloud architecture is not multitenant (just high efficiency, orchestrated shared hosting). "Multi single tenant" I think they call it these days. I think its an extremely pragmatic albeit unpopular choice for a B2B SaaS company.
ianso 3y ago
Funny that the article focuses on huge corps for on-prem. I work for a non-profit and we deploy stuff to hardware in Afghanistan, Haiti, Sudan... You can't assume the Internet works and if it does, it could be a 1Mbps VSAT connection. Needless to say we don't have a Fortune 500 budget. When I see a nice, affordable app that says "and here's a Docker image!" next to the SaaS options, I am like ( ˘ ³ ˘ ) ♥
legitster 3y ago
> And ultimately, having an on-premise version unlocks certain industries that will simply not buy SaaS under any circumstances. These are specifically security critical industries like Defense, Banking, Insurance etc. - all of which come with sizable software budgets. You're putting the cart before the horse. The only places still making money off of on-prem installations are charging a premium for it. If a big government account comes up and offers to pay you extra for a special service contract, you're going to do it. I get the appeal to developers of just throwing out a self-service experience with minimum commitments. But it's not a good, sustainable business model on its own.
stuff4ben 3y ago
As someone who evaluated software in the CI/CD realm for years working at an enterprisey company, not have an on-prem solution immediately disqualified you. We had to go through so much more red-tape to allow a SaaS offering in the enterprise it just wasnt' worth it. Yes, that's the enterprise for you. It's been a while since I've done that, so hopefully they've gotten better about it.
chias 3y ago
At a previous employer we used an on-prem version of a popular software offering. It was great, but we obviously had to have people managing it. At my current employer I chose to use their cloud offering. I thought, hey, it's just me here, and I don't have time to sysadmin yet another thing. A few weeks ago I needed to enable the REST API, and for them to create a KVstore. On-prem these are 2-minute processes (set a value in a config file and restart the process). In the cloud offering, you need to make a support ticket. It took 17 days, and that's only because I ended up doing half of it myself -- they enabled the REST API first, and I found I could use the REST API to make the KVstore. I have some regrets.
Kwpolska 3y ago
My employer is moving in the opposite direction, we want to move all of our customers from on-prem to our cloud. Not all customers might be happy, but many are. The customer doesn’t need to manage a server. The software gets a controlled, well-configured environment, and the customer can’t mess it up by installing random software or imposing half-assed IT policies. And our support people don’t need all the security theatre involved with accessing the customer network (VPNs, tokens, special laptops in the customer AD domain, etc…), they can just access the customer’s resources in our cloud and get to work.
zubairq 3y ago
Agreed, have on premise and saas paid service
postwait 3y ago
on-premises.... premises... not premise
gms 3y ago
We (www.polytomic.com) have an on-premise offering in parallel with our hosted version. It's worked out fine for us (of course there are tradeoffs but for us they're manageable). Definitely requires an investment by people who know what they're doing as the article alludes to.
EvanAnderson 3y ago
> On-Prem has a whiff of the olden days. Of IBM mainframes, SAP and Oracle DBs. Off-prem feels that way to me. It's "the mainframe" run by the off-prem vendor. I have a dumb terminal. On-prem seems so much easier in today's corporate IT environments. Ship the Customer a VM. Use SAML for auth. Interact w/ clients over HTTPS.
moribvndvs 3y ago
I work where we still have on-premise offerings, and we’re in a crisis because of it. I am not against on-prem offerings, in fact quite the opposite. However, a significant swath of our customers are small-to-medium size businesses, and many don’t have access to qualified IT to run sophisticated software systems. Our contractual stipulations are very lax in terms of requiring customers to keep their hardware, software, and environment in a conducive, working order; we recommend ____ but if you fall out of spec, you assume the risk. Fine, except our contracts still put us on the hook to make sure, with reasonable effort, that the software is running. That means we spend our sparing and critical resources trying to cut pared down or specially tailored copies of our deliverables and trying to log into countless boxes to troubleshoot every banal and tedious tech support issue as to why a package isn't running or won’t install (spoiler: it’s almost always environmental: GPO restriction, firewall rule we told them we need an exception for, antivirus problems, dependencies not installed, excruciatingly out of date system, etc). These two things are not compatible especially as software evolves and becomes more reliant on other services. The problem is that early on the organization decided to bend over backwards to make sales, now we have to choose between letting this problem spiral out of control and drag us down with it, or renegotiate the contract with better/clearer requirements or ditching on-prem which will be a mess and probably result in losing customers. That especially sucks for many of those customers, because they live in areas with poor connectivity. Moral of the story: if you give your customers enough rope to hang themselves with, you’re also measuring out a length for yourself.
- matrix_overload 3y ago
  Why not offer a choice of expensive on-prem with average support costs baked in vs. cheaper cloud with savings passed to the customers?
  - moribvndvs 3y ago
    Indeed, that’s one of the options we’re looking at, just saying we’re probably going to take a hit because of poor decision making in the past as well as whistling past the graveyard rather than making a tough decision much earlier on.
CharlesW 3y ago
FYI, it’s “on-premises” or “on prem”. “Premise” means something very different, so I recommend you use “on-premises” or “on prem” if you’re trying to demonstrate competence to the majority of your audience who will know the difference.
- drewcoo 3y ago
  It irritates me, too. But honestly, how harmful is it to your business unless your addressable market is mostly English majors? And even then, it probably prompts interaction from the English majors, who can finally show off a little with a correction.
  - CharlesW 3y ago
    I posted for people who like to use words correctly and might appreciate the note. The rest can get their prostrate's examined for all I care.
    - cmuhgtwodwbs 3y ago
      My editor would find at least two easter eggs in this hopefully intentional comment. But, excellent point. What is the premise the author is deploying on?
ozim 3y ago
You can sell „private cloud” so you make separate server or servers for that specific customer. On premise goes away and you can also setup private cloud to be filtered on firewall to give access to customer only or connect it via vpn or whatever else. Biggest upside is that you still control deployment and are responsible for uptime but you have best knowledge in-house to deal with it.
MilStdJunkie 3y ago
You really have to have your ducks in a row to roll a cloud solution as an on-prem solution. I've participated in two rollouts like that - where it was a solid cloud product that we arranged to buy as on-prem - and both were pure failures. "Pure" as in "no one managed to even make the thing work, once, and then gave up". This comes back to nontechnical leadership, as business process issues tend to do. Leadership has something cool, they think "what's cool for us is cool for everyone", and then they try to sell into a market that maybe doesn't do cool in exactly the same ways. Take something like SAP B1P or JIRA. Both established or very powerful cloud apps. You'd be tempted to think that anyone in manufacturing would want some of this . . but then you have to build everything so that it's able to be portable-ized, which adds a ton of development time, and an ongoing maintenance cost that also involves headcount/travel/US persons/security clearance. How do you know if that cost could be justified? Well, that's where "nontechnical" comes in. The right way is matching up costs of dev and maintenance with what the industry will minimally pay. The wrong way - which seems dominant - is to use your Leadership Spidey Sense to determine whether or not to take the plunge. Then you get stuck in, you short the dev or the maintenance, and end up with a platform not optimized for either cloud OR on prem.

77 points by max_sendfeld 3y ago

If I have a choice between a company that sells SaaS and a company that offers an on-prem option, the latter gets my business. If you aren't confident enough in your software to hand me that code in an install file, I guarantee I don't want to rely on your janky startup's hacked-together spaghetti.

rco8786 3y ago

As the pendulum swings :) I love the idea of on-premise for small startups (or solo startups) because it shifts the operational/oncall burden to the customer. Also "on-premise" in 2023 can easily mean something deployable to a customer's AWS/Azure/GCP account.

wolframhempel 3y ago
I think that's actually exactly right. On-Premise might arguably be a wrong name - but for most customers it just means "software that you can run yourself in an environment that you control". And that environment is most often a cloud deployment.
deleted 3y ago
[deleted]

hyggetrold 3y ago

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 that team. We had to develop custom management interfaces for the software that were only deployed in an On-Premise environment. It wasn't crazy hard or anything but it was time and effort. Upgrades and installation were also a big track of work unto themselves. When you deploy into an On-Premise environment you are completely at the mercy of the clients infrastructure. One support call I did was clocked at 14 hours - there are so many things that can come up. Plus there's the whole hassle of actually getting the calls scheduled and making sure clients aren't too many versions behind. Sometimes we had to spend a lot of time waiting on support calls because the customer didn't have their stuff together. Like sitting and waiting for a network team to open up the firewall so that bits could be downloaded from our distribution server. And of course the firewall had to be closed up right afterwards, so this was a common thing. Another time we spent weeks troubleshooting a client installation. In the end it turned out that the client had our software talking to two different internal NTP servers which were slightly out of sync, which caused our SSO/SAML integration to break. Database migrations were also challenging - in a cloud environment you often have flexibility to migrate things live while the system is running. But often with the on-premise upgrades, you had to take the whole system down while the migration was running (back to the 14 hour support call). This could mean scheduling the support calls at really weird hours. On-premise also has challenges if you start selling to the US government, especially defense. There are super strict requirements that support personnel must be US citizens on US soil - so hopefully you have more than one person on the team meeting this requirement! All in all, I am not a detractor of offering an On-Prem solution. It can be a real differentiator and it will open a lot of doors. There are some companies that simply won't buy SaaS, either due to internal or regulatory reasons. Once you land these clients it can be very lucrative and long-term. But, it almost always requires dedicated staff to support and manage.

zdragnar 3y ago
> 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.

dangus 3y ago

Big enterprise deals can be a huge burden for a small company. They’re demanding customers and they will probably pressure you into making product customizations that don’t apply to the rest of your target audience. Enterprise customers tend to have more edge cases and scaling requirements, along with a huge workforce with more difficult lines of communication. Anecdotally, they seem to need more follow-ups and hand-holding than smaller nimble companies. An ideal customer is often one that subscribes, pays their bill, and rarely asks you for help. Your product already solves their problem out of the box without needing to go down any rabbit holes.

physicsguy 3y ago

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. * Your software need to be tolerant of infrequent updates. Customers expect some level of stability in practice. * You need to integrate licensing checks. * You need to build an installer (that works out of the box…) * You’ll need to agnostically support the common parts of SAML/OpenID for Auth only, and not rely on any bespoke features from a commercial provider like Auth0 or AzureAD.

bitschubser_ 3y ago
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 :(
- physicsguy 3y ago
  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.
dijit 3y ago
Seems like everything is rare for a startup to have. Productisation, infrastructure expertise? Why do anything?
- physicsguy 3y ago
  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".

macrael 3y ago

"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 output etc." LOL that paragraph hides all of it. On prem means that someone is administering your application that does not understand it. Which means YOU are administering it but via slacking with your customers infra engineers rather than through your own control plane. The article is right that there are customers who require this and if you want them you'll have to figure this out, but it is a huge pain in the ass and should be avoided if at all possible.

chatmasta 3y ago
Over 40% of the Web is deployed this way. Wordpress installation is basically "upload some files, complete installation GUI, and then get started." There's no reason other products couldn't do this as well, even those with a complicated stack that requires provisioning cloud resources (or equivalently, SSH'ing into servers on the local network or calling private cloud API endpoints). If you can deploy a commit from a pipeline, then you can make a self-hosted bootstrappable installer for your users. The installer could be a tiny shim running on the user's laptop that's responsible for bootstrapping the rest of the infrastructure and then deleting itself after redirecting the user to the cluster admin panel. The trick is to make it smooth, so even non-technical users can provision and eventually administer a secure, self-updating cluster as easily as they can keep their iPhone up to date. Walk them through the process of getting AWS credentials. Heck, scrape and script the login flows if that makes it smoother (it's their computer running the code so who cares?). Ask the user the minimal questions needed to fill the config. Once all that's in place, trigger your deployment scripts on the cluster, to pull images from a container registry or whatever. Wait for it to be up and running. When the cluster's up, redirect them to its admin panel that's more sophisticated and controlled by you. Let them check for updates, install plugins, run common operations (like "restart," etc). Then just don't ship broken code, make sure your scaling policies work (or at least that they work well enough to avoid phone calls from customers that don't make you any money). And boom you've got a nice product. I'm not saying it's easy. But if you already have automated deployments (you do have automated deployments, right?), then it's not that many extra steps. Productizing it is hard but can be done.

nathanaldensr 3y ago

*on-premises

keithwinstein 3y ago

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

pesfandiar 3y ago
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).
Mindless2112 3y ago
Yes, please. "Premise" means something entirely different: "A statement that is assumed to be true and from which a conclusion can be drawn."

bob1029 3y ago

We are selling SaaS/B2B and are looking to support both modes moving forward. Our (my) preference is heavily tilted towards cloud, but we've modeled things to minimize our pain for on-prem. Path A: Run a windows server VM and SQL Server somewhere in our customer's infrastructure. Our customer is 100% responsible for the health of these items and provides them as a service to us. Our customer has to notify us of any infra or app issues reactively. Path B: We operate as custodians in our customer's Azure tenant. We deploy our software as a Function app and use Azure SQL. We are 100% responsible for the health of everything. Our customer is notified proactively of any issues. To support both paths, we have two different executable project types (console app and azure function app) that consume a common library type. Only the barest boilerplate code actually changes between on-prem and cloud. 99% of the difference is HTTP Trigger function vs AspNetCore hosting syntax. Everything else is identical. We work with small US banks and we haven't found one that is total stonewall against moving to cloud. Many are cautious but open. The #1 concern is the PII/data. We've been working with a few angles to cast that in a more realistic light. Most of our customers have had some degree of an incident with on-prem infrastructure that could have been made impossible if business was being conducted via a cloud provider.

dehugger 3y ago
Path C: Sell installable software with documentation (and training courses if you are big enough). You'll still get yearly revenue via license fees. I don't know why this went out of fashion but it works just fine. Your customers clearly don't want you to manage the infrastructure, based on your comment. Sell them what they want. If the issue is that your system is so complex that a reasonably trained admin cannot manage it, you should probably fix that.
- bob1029 3y ago
  If you want to go all the way into the rabbit hole: the entire purpose of our system is to provide interfaces into various lines of our customer's businesses. What our customers want is a technology partner who can adapt to their changing business needs over time. A one time cdrom+pdf distribution unfortunately will not get the job done in this case. Our customers are paying for a business outcome. Our software is just a fraction of that puzzle.

dijit 3y ago

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 little into the problem as you deem necessary. If you use a SaaS you must somehow figure out how that factors into their pricing model and it's still largely their whim, and worse: they will still change things without notice. It's also true that a lot of companies do not assume that the internet is always available. Getting 100Gb/s to a server room is easy for 500 people in an office building. But getting 100Gb/s to your SaaS platform might not even be possible without rearchitecting. (IE: Perforce in game dev, usually on-prem.)

KRAKRISMOTT 3y ago
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.
- citrin_ru 3y ago
  SaaS and on-prem software are very different in how they are developed and require different expertise. Even if you would pay a SaaS company enough so they will be willing to adapt their SaaS to on-prem it will be a mediocre product.
- arccy 3y ago
  try 10x that if your product is any degree of nontrivial
- marcosdumay 3y ago
  I've rejected plenty of >100k a year proposals because there wasn't an on-premises alternative. (And also another batch because despite being willing to pay yearly for upgrades and support, there wasn't an option of retaining the license in perpetuity.)

tapoxi 3y ago

I work for a Healthcare SaaS, and our requirements around where data can live are so strict we can only use applications that we can self-host. For us this means Helm chart and installed on k8s. I'm honestly shocked that Sentry, for example, doesn't have a self-hosted enterprise option. We're all terrified of PHI being caught in a stack trace and sneaking through any PHI-scrubbing feature. We had to move off of Confluent because CFK's pricing is outrageous compared to Confluent Cloud. It's clearly designed to nudge customers towards Cloud, but we can't use it due to contractual requirements with customers. Everyone is so anxious about breaches that even a BAA doesn't cut it anymore. So there's absolutely a market for this kind of stuff.

supriyo-biswas 3y ago
For self hosted Sentry, look at Glitchtip (https://gitlab.com/glitchtip/glitchtip-backend/-/blob/master/README.md https://gitlab.com/glitchtip/glitchtip-backend/-/blob/master...)

montereynack 3y ago

Since this is a topic that’s near and dear to my heart, going to quickly plug my own startup that’s doing exclusively this: www.sentineldevices.com. We make industrial equipment smart enough to self-monitor and self-report issues using AI, but we are specialized in making AI that does EVERYTHING (including training) on embedded devices (think something only marginally more powerful than an RPi 4) so we never call out to a server. As the article notes, a big challenge has been making the AI and all support software resilient and able to “bounce back” from random occurrences in industrial environments (which can be extremely unpredictable and unique). Also as the article notes, this pretty handily opens up the Defense market since we don’t need to clear a cloud component. Feel free to reach out at forrest@sentineldevices.com if you’d like to chat. We’re building and trying to take people on part-time if anyone’s interested in this space! Also if anyone just wants to talk about challenges in the space I’m happy to, HN usually gives really great conversation partners.

Merad 3y ago

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.

physicsguy 3y ago
When I worked for a big enterprise company writing simulation software, we did quarterly or bi-yearly releases, but the defense clients wanted to run their own verification and validation tests generally, so they maybe upgraded once every 2 or 3 years. When I went to work at a University as a research software engineer, a particularly memorable incident was a research group getting very angry that we were upgrading the cluster to CentOS 7 thus meaning the ancient version of COMSOL they were contractually obliged to use in a contract with Rolls Royce would no longer run at all. We ended up getting something working using Singularity but it was very painful.
gomox 3y ago
We copied the Ubuntu release schedule to deal with this (rolling release for cloud, LTS + security/bugs for on prem). Its not particularly painful (but we don't provide support for 2 full years).

CKMo 3y ago

Not everything should be on-prem, but some things should be. Access control comes to mind

gizmo 3y ago

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.

stuff4ben 3y ago
This is where the sales team hands it over to the consulting arm. You charge for that as well as the licensing. It's why companies like IBM are still around :)

blueyes 3y ago

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.

gomox 3y ago

Our company does this and it has become a competitive advantage allowing us to get into customers that would otherwise be out of reach. Pretty much every single current offering is SaaS-only so if you want a modern product on prem we're essentially the only game in town. Operationally speaking we built the products from the ground up to be available either way (at the time, it was a less contrarian take). The resulting cloud architecture is not multitenant (just high efficiency, orchestrated shared hosting). "Multi single tenant" I think they call it these days. I think its an extremely pragmatic albeit unpopular choice for a B2B SaaS company.

ianso 3y ago

Funny that the article focuses on huge corps for on-prem. I work for a non-profit and we deploy stuff to hardware in Afghanistan, Haiti, Sudan... You can't assume the Internet works and if it does, it could be a 1Mbps VSAT connection. Needless to say we don't have a Fortune 500 budget. When I see a nice, affordable app that says "and here's a Docker image!" next to the SaaS options, I am like ( ˘ ³ ˘ ) ♥

legitster 3y ago

> And ultimately, having an on-premise version unlocks certain industries that will simply not buy SaaS under any circumstances. These are specifically security critical industries like Defense, Banking, Insurance etc. - all of which come with sizable software budgets. You're putting the cart before the horse. The only places still making money off of on-prem installations are charging a premium for it. If a big government account comes up and offers to pay you extra for a special service contract, you're going to do it. I get the appeal to developers of just throwing out a self-service experience with minimum commitments. But it's not a good, sustainable business model on its own.

stuff4ben 3y ago

As someone who evaluated software in the CI/CD realm for years working at an enterprisey company, not have an on-prem solution immediately disqualified you. We had to go through so much more red-tape to allow a SaaS offering in the enterprise it just wasnt' worth it. Yes, that's the enterprise for you. It's been a while since I've done that, so hopefully they've gotten better about it.

chias 3y ago

At a previous employer we used an on-prem version of a popular software offering. It was great, but we obviously had to have people managing it. At my current employer I chose to use their cloud offering. I thought, hey, it's just me here, and I don't have time to sysadmin yet another thing. A few weeks ago I needed to enable the REST API, and for them to create a KVstore. On-prem these are 2-minute processes (set a value in a config file and restart the process). In the cloud offering, you need to make a support ticket. It took 17 days, and that's only because I ended up doing half of it myself -- they enabled the REST API first, and I found I could use the REST API to make the KVstore. I have some regrets.

Kwpolska 3y ago

My employer is moving in the opposite direction, we want to move all of our customers from on-prem to our cloud. Not all customers might be happy, but many are. The customer doesn’t need to manage a server. The software gets a controlled, well-configured environment, and the customer can’t mess it up by installing random software or imposing half-assed IT policies. And our support people don’t need all the security theatre involved with accessing the customer network (VPNs, tokens, special laptops in the customer AD domain, etc…), they can just access the customer’s resources in our cloud and get to work.

zubairq 3y ago

Agreed, have on premise and saas paid service

postwait 3y ago

on-premises.... premises... not premise

gms 3y ago

We (www.polytomic.com) have an on-premise offering in parallel with our hosted version. It's worked out fine for us (of course there are tradeoffs but for us they're manageable). Definitely requires an investment by people who know what they're doing as the article alludes to.

EvanAnderson 3y ago

> On-Prem has a whiff of the olden days. Of IBM mainframes, SAP and Oracle DBs. Off-prem feels that way to me. It's "the mainframe" run by the off-prem vendor. I have a dumb terminal. On-prem seems so much easier in today's corporate IT environments. Ship the Customer a VM. Use SAML for auth. Interact w/ clients over HTTPS.

moribvndvs 3y ago

I work where we still have on-premise offerings, and we’re in a crisis because of it. I am not against on-prem offerings, in fact quite the opposite. However, a significant swath of our customers are small-to-medium size businesses, and many don’t have access to qualified IT to run sophisticated software systems. Our contractual stipulations are very lax in terms of requiring customers to keep their hardware, software, and environment in a conducive, working order; we recommend ____ but if you fall out of spec, you assume the risk. Fine, except our contracts still put us on the hook to make sure, with reasonable effort, that the software is running. That means we spend our sparing and critical resources trying to cut pared down or specially tailored copies of our deliverables and trying to log into countless boxes to troubleshoot every banal and tedious tech support issue as to why a package isn't running or won’t install (spoiler: it’s almost always environmental: GPO restriction, firewall rule we told them we need an exception for, antivirus problems, dependencies not installed, excruciatingly out of date system, etc). These two things are not compatible especially as software evolves and becomes more reliant on other services. The problem is that early on the organization decided to bend over backwards to make sales, now we have to choose between letting this problem spiral out of control and drag us down with it, or renegotiate the contract with better/clearer requirements or ditching on-prem which will be a mess and probably result in losing customers. That especially sucks for many of those customers, because they live in areas with poor connectivity. Moral of the story: if you give your customers enough rope to hang themselves with, you’re also measuring out a length for yourself.

matrix_overload 3y ago
Why not offer a choice of expensive on-prem with average support costs baked in vs. cheaper cloud with savings passed to the customers?
- moribvndvs 3y ago
  Indeed, that’s one of the options we’re looking at, just saying we’re probably going to take a hit because of poor decision making in the past as well as whistling past the graveyard rather than making a tough decision much earlier on.

CharlesW 3y ago

FYI, it’s “on-premises” or “on prem”. “Premise” means something very different, so I recommend you use “on-premises” or “on prem” if you’re trying to demonstrate competence to the majority of your audience who will know the difference.

drewcoo 3y ago
It irritates me, too. But honestly, how harmful is it to your business unless your addressable market is mostly English majors? And even then, it probably prompts interaction from the English majors, who can finally show off a little with a correction.
- CharlesW 3y ago
  I posted for people who like to use words correctly and might appreciate the note. The rest can get their prostrate's examined for all I care.
  - cmuhgtwodwbs 3y ago
    My editor would find at least two easter eggs in this hopefully intentional comment. But, excellent point. What is the premise the author is deploying on?

ozim 3y ago

You can sell „private cloud” so you make separate server or servers for that specific customer. On premise goes away and you can also setup private cloud to be filtered on firewall to give access to customer only or connect it via vpn or whatever else. Biggest upside is that you still control deployment and are responsible for uptime but you have best knowledge in-house to deal with it.

MilStdJunkie 3y ago

You really have to have your ducks in a row to roll a cloud solution as an on-prem solution. I've participated in two rollouts like that - where it was a solid cloud product that we arranged to buy as on-prem - and both were pure failures. "Pure" as in "no one managed to even make the thing work, once, and then gave up". This comes back to nontechnical leadership, as business process issues tend to do. Leadership has something cool, they think "what's cool for us is cool for everyone", and then they try to sell into a market that maybe doesn't do cool in exactly the same ways. Take something like SAP B1P or JIRA. Both established or very powerful cloud apps. You'd be tempted to think that anyone in manufacturing would want some of this . . but then you have to build everything so that it's able to be portable-ized, which adds a ton of development time, and an ongoing maintenance cost that also involves headcount/travel/US persons/security clearance. How do you know if that cost could be justified? Well, that's where "nontechnical" comes in. The right way is matching up costs of dev and maintenance with what the industry will minimally pay. The wrong way - which seems dominant - is to use your Leadership Spidey Sense to determine whether or not to take the plunge. Then you get stuck in, you short the dev or the maintenance, and end up with a platform not optimized for either cloud OR on prem.