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

SaaS is phenomenal. Investors love it for its predictable, recurring revenue streams and easy scalability. Founders love it for its quick, low touch sales process and high levels of customer analytics. Users love it for its ease of adoption and worry free usage. And engineers love it since they only have to build it for one, fully controllable environment.

And they are all correct in loving it. SaaS is awesome.

So - given these overwhelming benefits, why would anyone in their right mind still build on-premise software? Let me explain:

What’s On-Premise software?

Basically, it’s a version of your software that (typically larger) customers run on their servers in their data centers or cloud deployments, as part of their infrastructure. It’s usually sold as an annual or multi-year licensing contract.

Why are so many techies negative about On-Premise?

On-Prem has a whiff of the olden days. Of IBM mainframes, SAP and Oracle DBs. And there’s some truth to that. Sales cycles are long and enterprise-y. They involve navigating procurement, providing certifications and reports, sometimes even code escrow. Engineers have to think about a whole ecosystem that your solution has to work in: Different Linux distributions or Windows-Server, access and permission management with Active Directory, log-service and monitoring integrations,… it’s all very unsexy stuff. And product people will miss the realtime customer insights that SaaS provides.

But I still think it’s worth having an On-Prem version of your SaaS. Here’s why:

Let’s start with the obvious one: Enterprise deals are huge. Even as a small company, you can reliably sell five, six and even seven figure annual licensing deals. It often would take you hundreds or even thousands of SaaS customers to make up for one enterprise contract.

Customers are incredibly sticky: Once they have signed, they are with you for the long run. Not only have they made a significant investment into going through the procurement process with you and rolling your solution out internally, they often assign teams to build on top of your offering, making it next to impossible to ever change to a competitor.

Over time, it becomes pure profit: In my experience, the support and time requirements from your customer’s side drops sharply once the initial rollout is complete. Once everything is up, running and integrated, customers focus on their own value add. And since you don’t have any infrastructure or maintenance cost, the contract value becomes almost pure revenue.

Upselling is much easier: Given the initial investment and existing customer relationship, customers have a much easier time buying more from you. Have some new feature or addon that costs extra? Chances are, the customer can just acquire it through an extension of the existing budget.

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.

But - can every SaaS offering be turned into an On-Premise version?

Maybe. But some much harder than others. Generally speaking, if your internal architecture is heavily fragmented into many small microservices, if you make extensive use of cloud-specific services or third party APIs or if you’ve built a highly bespoke (read: slightly non-standard or wonky) thing, you will have a hard time.

So, how should you approach building an On-Premise version?

First: Decide which part of your offering you want to make available.

For Hivekit, we only sell our clusterable geospatial data server as an on-prem version. It doesn’t come with the fully fletched UI, but instead has a more limited dashboard with some additional cluster monitoring features targeted at developers.

For Arcentry, an earlier company of mine, the on-premise version was the whole thing, with all the bells and whistles.

For you, the right size might be somewhere between these extremes. Pick a unit that provides value by itself, has a clearly defined set of functionality and has little to no external dependencies. (Requiring a common database like Postgres or MySQL is fine, but once your customer needs to roll out Kafka and Zookeeper or - much worse - needs to buy another technology to enable yours, sales will become much harder).

Second: Build your on-premise offering for yourself.

Don’t have different versions for cloud and on-premise, just build one and create your own SaaS offering on top, the same way an on-premise customer would.

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.

Fourth: Choose your channels

Your SaaS might be your best sales channel for your on-premise offering. A free tier provides potential customers with an easy way to test your product. Once they are convinced, they may reach out to enquire about the enterprise version.

If you want to speed up your sales process, you might consider offering your on-premise version through AWS, Azure or Google Cloud Marketplaces. This means you will have to accept a 20% cut, but it also means that your customer can pay you out of existing (and often poorly controlled) cloud budgets.

You can also consider outbound sales. Personally, I’ve found that incredibly hard, especially if your on-premise product is highly technical. Somewhere, deep in the guts of a large organization there will be a team that needs exactly your solution at this moment in time - but the chances for your sales guy to reach out to that particular team are super low. Instead, focus on being present as a thought leader in your space and create awareness of your product so that when the time comes for the customer, they know who to think of.

Closing thoughts

I had very good experiences, selling on-prem versions starting early in my company’s lifecycle. They often provided the initial budget for larger SaaS rollouts and created a reliable base line revenue stream that offset the volatile SaaS subscriptions. If you consistently plan for on-prem from the beginning and make your SaaS a customer of your on-prem offering, the overhead is minimal and the revenue substantial. So - give it a thought!