GitLab CEO Sid Sijbrandij Shares Insights On How To Develop A Self-Hosted Application

We had the opportunity to chat with Sid, the CEO of GitLab, on what it takes to offer a self-hosted version of your software a few weeks ago. GitLab is a single application for the entire software development lifecycle. From project planning and source code management to CI/CD, monitoring, and security.

In addition to a SaaS product, GitLab offers a self-managed/self-hosted version of their app that has been a great business model for them. We’ve been working through the idea of offering a self-hosted version of CloudForecast and knew that Sid would be a great resource to learn from.

TL;DR summary:

• Leverage third-party software to deploy faster: Look into third party software such as Replicated to help speed up your deployment process.
• Support is important: Keep it simple and include support for all your pricing tiers.
• Offer a freemium version of your app: Consider a free version of your software with a few limitations in place. That limitation can be a 30-45 day free trial and flexibility to extend further. This will help you get your foot in the door and create sales opportunities.
• Focus your messaging around data security: “Data does not leave your network” is the single most important thing you need to focus on while building a self-hosted version of your software.
• Build a product that saves time: Engineers do not want to fiddle with tools; they want to build software. Focusing on an out of the box experience that can get them results in 5 minutes or less is very important.

Here are a few highlights from our conversation. We hope this can help your company if you are considering building a self-hosted version of your app. The full interview video is available after this post.

There are a lot of technical challenges involved with building an self-hosted version of your software. We found a third party company called Replicated, that makes it easy for SaaS and software companies to make the move into selling modern, on-prem software. What are your thoughts with using software like Replicated?

Faster is better, especially if you are not sure if there is a giant market. It makes a lot of sense to go that route. I know the people from Replicated – they are good and they know their stuff. When we first started packaging GitLab, Replicated was not there yet or we were not aware of them at the time.

There are a few lessons that we ran into while doing it on our own and things you need to consider. First of all, it’s A LOT of work to package up your stuff. We have an entire distribution team that is focused on this. We based our packaging on a technology from Chef called Omnibus. The end user experience is great, the team did a great job, but it is a significant investment. That speaks for using a third party tool like Replicated to speed up your process.

Few things to be aware of in the Enterprise space, not everyone uses Docker and Kubernetes. That might be different for your customers. But, we found that a lot of our customers do not like running them in production. They might have other tools that assume a boring Unix app. Examples: “Oh! I want to provision it as expected user”, or “I want to run an agent on the system”. They cannot accept a black box but they want more flexibility. With that being said, I think time is the most important thing you have in a startup which makes going with a solution like Replicated makes sense.

How should we consider pricing if we were to go with a self-hosted version of CloudForecast? What are the lessons you’ve learned while trying to figure out a pricing model for GitLab?

We’re frequently bought by companies that don’t do a consumption pricing model. They want a predictable amount and they know what they will be charged at the end of the month.

They get a budget for it and they have to put in a dollar number when they request it. Making it variable makes it difficult to purchase. It might not make it difficult though if you can figure out a way to lump it into the existing cloud provider bill. Cloud providers are starting to offer marketplaces that allow you to bill for your software. In that case, your offering of variable pricing can lump right into cloud provider bill.

A boring solution would to have a few tiers with fixed pricing based on their monthly spend with their cloud provider. It’s not ideal, but it makes it a lot easier to purchase because they know exactly what they will be billed using your software.

How do you all handle and price support out for GitLab? Any lessons there with approaches you’ve tried out?

You should never sell without support. You should always include support because you’ll end up with a situation like, “Well, I can’t use it I have a problem with it and they say well tough luck you didn’t buy support.”. The reverse can also be true with ONLY selling support. We did that with GitLab in the beginning. People didn’t have any problems and they cancelled their support contracts. It made sense for them since they were able to use the product with no issues.

To handle both scenarios, we just include support if they want support or not. They will pay the same price for either/or. I am a huge proponent of building it in no matter what. There is one subscription pricing and it includes support. There is a scenario with support with a good, better, best model. Example for us: the best model means that you’ll get better support that is more timely, more extensive and with more hand holding.

What is the sales process like selling into enterprise companies? Who should we be talking? Any tips on ways we can start selling into these companies?

GitLab is an open core company so lots of people that we get to sell into start with our open source offering. This has really helped us get our foot in the door early on and helps speeds up the sales cycle because they are using your product. Typical sales cycle on average for GitLab: Less than 10k is about 60 days. 10k – 100k is about 90 days. 100k and more is about 120 days.

If you don’t want to open source your software, you should consider a free-tier version of CloudForecast. There is a whole big thing called “Shadow IT”, where people don’t like going through the process and want to run something that can help them. They’ll frequently use free tools since so they don’t have to expense it.

However, you still have to consider that they might not be able to use the free SaaS version since they cannot share confidential data or credentials. If you had a on-premise, free version of your software, they can use your tool and still be good stewards of the private data. You become an approved vendor since the data is never leaving the network, which becomes less of a problem.

To follow up on a free version of your product, would you recommend maybe offering a limited version of your software? What are some variants you’ve seen that has worked well?

There can be many variants to a free version of your product. For GitLab, we’re open core, so our free version will always be free and then we charge for additional features on top. With a lot of proprietary software, the limited version might be a fixed “time limit” and you cannot continue after X days. It doesn’t have to be 30 days and it can be a whole year as an extreme example.

With someone who has a problem of spending too much with their cloud provider, their boss has tasked them to solve that problem right away. They have to go through a purchasing process of 30-60 days to get the vendor approved when they need a solution right now. They might not object to a 30-45 day free trial to see how the product can work for them. From what I’ve seen, that seems to be the industry standard and it makes a lot of sense. For GitLab, we’ve settled to offer 30 days and if people ask for an extension, we are happy to oblige and extend their free trial.

What are some messaging and important features to consider that resonates to decision maker looking for an on-prem solution?

The most important thing to highlight with messaging is “Data does not leave your network”. Maybe with CloudForecast, focus on getting your first cost report in less than five minutes should be key. You also want to highlight average percentage someone can save. Highlighting pricing is also very important. We’ve found that the pricing page is the most popular page on any website.

With your experience at Gitlab, what are your customers looking for and considering as an on-prem solution?

GitLab wins because we’re a single application for the entire DevOps life cycle. We save them time because they don’t have to combine a chain of other applications together and spend a lot of time integrating them all. All this leads to a subpar experience anyways since they are all still separate apps.

You’ll start to understand quickly that people have very limited time. They have this assignment to save cost and they need to get results quickly. People want to make software, not string 50 different DevOps tool to get it. That out-of-the-box experience that can get you results in 5 minutes or less is very important. I’d encourage you to show a video of you downloading and installing your software, them putting in their AWS credentials and the result is getting a super cool cost report. That is insightful. If you can make that video in less than three minutes, that is awesome.

Do you have a rough idea how long it takes from signing up to installing it and having a working GitLab on your servers? Is there any manual processes involved or is it fully automated process that takes less than 10 minutes?

Five minutes including registering the subdomain is what we are shooting for. In previous years I went online and I live streamed myself doing it. I learned a lot from that.

Not a customer and interested in trying us out? Sign up today and get started with a risk-free 30 day free-trial with us: Start 30 Day Free-trial

Please reach out to us if you have any feedback for us or have suggestions on what we should build next. We would love to hear from you: [email protected]