GitPrime, don’t commit to selling SaaS

This is a guest post by Kathryn Murphy, EVP and General Manager of Pluralsight Flow, an engineering analytics platform that leverages data from code commits, pull requests, and tickets to help engineering leaders and teams move faster, optimize work patterns, and improve engineering workflows.

Enterprise SaaS startups face a common dilemma when it comes to the decision of whether or not to develop an on-prem version of their product. All the signs from pundits and analysts say cloud services are where the world is heading. Your investors are worried another product will affect the company’s focus, and you’re worried that staffing up a separate team to build a new product will destroy your budget (not to mention your corporate culture).

And yet …

… anybody who’s been in this game for a significant amount of time knows that enterprise buyers don’t always share your enthusiasm around managed services. The chances are, you’ve had your fair share of prospects who have conceptually bought the product, but made it clear they can’t, or won’t, actually buy the product until it’s delivered on-prem (or at least on IaaS resources they control). They’ve seen your security audits, met your team, and trust you know what you’re doing.But they’re not about to bet their jobs on any of those things.

This puts startups in a tough place. To use a football analogy, it puts startups at 4th-down-and-2 on the 50-yard-line, in a close game with little time remaining. The safe thing to do would be to punt and trust your defense; the bold move would be to go for it and try to secure the win right now. Stick with the SaaS business model you chose because it was easier, or try to secure those big deals by building a new offering.

The historical case against going on-prem

Historically, this has not been an easy decision. Those fears about burning money and losing focus aren’t unfounded. If you don’t plan correctly, the profits from your on-prem business can easily be subsumed by the costs of hiring engineers and salespeople. If deadlines start slipping or, in the worst-case scenario, the on-prem version is no good, that money is wasted.

You also have to think about the cultural implications of having two separate engineering teams competing for budget, marketing, and sales support. And about salespeople who have to learn two products and resist the urge to automatically push the one that makes them a bigger commission. In the case of GitPrime, we have a couple dozen employees and have raised just about $2 million in venture capital, so any disturbance in the force was going to have an outsized impact.

Why we did it anyhow … and don’t regret it a bit

Nonetheless, we made our decision to deliver an on-prem product in 2016—really, not too long after we launched the company in early2015. Our head of sales was getting deep into discussions with enterprise buyers, only to be told that on-prem availability constituted a go-or-no-go situation. She analyzed the data and ultimately convinced my co-founder and I to seriously investigate an on-prem product.

The good news for us is that we had previously been introduced to a company called Replicated, which specializes in helping SaaS companies deploy their applications on-premises. Replicated takes advantage of cloud-native architectures and development practices to package applications and manage releases, so we were able to avoid most of the headaches and risks that going on-prem historically entailed.

The one catch is that we hadn’t yet containerized our existing application and codebase, and Replicated requires that you use Docker. Still, hiring a contractor for a couple of weeks to Dockerize our existing application so we could integrate it with the Replicated platform was a far cry better than hiring an entire engineering team.Had we been a Docker shop, to begin with, that step might have taken a day instead of a couple of weeks.

After that, the process pretty much consisted of uploading our application’s YAML file to theReplicated portal and then updating it when we push new releases live.Because we’re still transitioning toward a container-centric architecture, there’s a delta between when the SaaS version gets new features and when the enterprise version does. But that window is very manageable and will shrink substantially as we continue to containerize across the board.

Replicated also provides tooling for managing customer licenses and on-prem installation, and a bunch of other features—things like LDAP/Active Directory integration, audit logs, and customer support bundles—that we didn’t need to build ourselves. Even with containerizing our application and paying the Replicated license fees, we were still able to offer a full-featured enterprise edition for only a small fraction of what it would have cost (in money and in time)to build it.

Focus on customers, not on distinct products

However, on-prem is on-prem, and you’re always going to run into issues with customers that have unique environments or that want features not on your current roadmap. It’s definitely not SaaS, whereyou control the operating environment and everybody can pay for the same features. However, packaging our enterprise version as Docker containers and deploying via Replicated has helped alleviate some of these issues, including by making it simpler to manage patches and releases on a customer-by-customer basis when necessary.

The reality is that offering an on-prem enterprise product is going to be more work than sticking with SaaS alone. There’s going to be at least a little more legwork on the development side, and sales cycles are probably going to be much longer. And then, when you close deals with large enterprises, you need to deliver a level of support that matches the premium those customers are paying.

But for us, the reward has far outweighed any risk and any additional effort, and we owe a good portion of our enterprise-version success to Replicated’s expertise in delivering that experience. The points of starting a business are to help customers solve their problems and make money doing so, not to commit to an orthodoxy on how software is delivered. Today, we’re achieving both those goals.

‍