On this page


Pricing affects product, marketing, and sales. Therefore general pricing decisions are made by the CEO.

Product makes most decisions on a day to day basis about what feature should go in what plan based on the Enterprise Edition Tiers . Therefore this pricing page is in the product handbook.

Four tiers

We have four pricing tiers. How we make decisions on a day to day basis are specified in what goes in what version.

Version: Free Starter Premium Ultimate
Per user per month: $0 $4 $19 $99
Market segment: SMB Mid Market Large Strategic
Buyer: None Developers IT CIO
Main competitor: None Atlassian GitHub Collabnet
Type of sell: None Feature Benefit Transformation

Type of sell

Hybrid sales model

There is a big price difference between the different tiers (0$, $4, $19, $99 per user per month, a price difference of infinite, 5x, 5x). For GitLab Inc. the majority of revenue is coming from the large enterprises buying the top two tiers.

Most companies in a similar situation would focus only on the highest tiers. There will be pressure to increase our lowest tier to for example $8. But we want to make a our hybrid model work for the following reasons:

  1. We want to keep being a good steward of the open source project.
  2. The lower two tiers are a scalable way to create future customers.
  3. If organization are already using Atlassian JIRA we want to be competitive with BitBucket on pricing. If they buy BitBucket it is hard for us to win them back. If they buy GitLab they discover that it can replace JIRA and over time they might buy a higher tier.

Raising the price of the lowest tier will prevent people from starting with GitLab. It will raise short term revenue at the expense of our long term market-share. Instead of raising prices we should focus on communicating the value of the higher tiers. This will get easier over time when we introduce more features. In 2016 sales people focussed on free vs. starter, in 2018 on starter vs. premium, hopefully in 2020 on premium vs. ultimate.

Charging $8 for the lowest tier and discounting aggressively when we're up against BitBucket doesn't work. It is unfair to customer that are not aware of this discount and most customer are self-serve, we never talk to them.

You can also check the viability of the different tiers by the conversion from tier to tier. For example if 5% of users upgrade from free to starter, starter to premium, and premium to ultimate your prices are balanced. If much more people upgrade from free to starter than from starter to premium then starter is underpriced. Please note that when a customer chooses starter over premium that is much more visible to us than users not buying at all and this might cause us to focus to much on the first case.

A conversion rate of 5% for installations / organizations should not be confused for 5% of the market revenue. There are organizations of different sizes and larger ones are more likely to pay and purchase a higher tier.

A 5x higher price doesn't mean there is 5x more value, just like the Starter tier doesn't provide infinite more value than the gratis Libre tier. When deciding between tiers organizations should look at the ratio between how much extra value they get divided by how much extra they pay. If this ratio is comfortably above 1 it makes sense to move to a higher tier. The value is in making people more effective, save time on integrating tools, faster time to value, and retiring other tools. This should more than pay for the increased price of a tier. An analogy would be the Iphone: it is twice as expensive as an average Android phone, and while it doesn't deliver twice as much value, the extra value is worth it the extra cost.

A low price for the lowest tier is also how we mitigate the first risk of only selling a suite.

Combining features in plans

We tried selling one feature at a time but this was was not feasible. An improved version of that would be selling 7 main features instead of 3 plans. Examples of main features would be High Availability, Security, Service Desk, etc.

The advantages are:

  1. Gradual upgrading to more expensive features.
  2. Pay only for the features you use.
  3. Add-ons are a common way of selling this.

The disadvantages are:

  1. It is suboptimal for both the buyer and GitLab Inc..
  2. It is hard for the buyer to estimate how much of each feature they will need.
  3. The complexity lengthens the sales process.
  4. For users it is unclear what features they can use.
  5. The true-up process becomes more complex.
  6. The customer has to administer a process how users can get more features.
  7. Features get less usage and therefore the improvements are slower.
  8. It is hard to do with a hybrid sales model where there is a 25x difference between the lowest and highest paid plan.

We currently think the disadvantages outweigh the advantages.

Multiple plans for one customer

We considered selling multiple plans to the same customer, allowing them some users on every plan.

The advantages are:

  1. Gradual upgrading to more expensive features per team.
  2. Pay only for the features you use.

The disadvantages are:

  1. The current plans have a blended price assuming 75% of users should pay for the 5x less expensive plan so plan prices would increase by 2.5x 1/(0.25+(0.75/5)).
  2. It is hard for the buyer to estimate how much of each tier they will need.
  3. The complexity lengthens the sales process.
  4. For users it is unclear what features they can use.
  5. It is not common in the industry, buyers don't expect it, and it isn't a boring solution (a sub-value under our efficiency value).
  6. The true-up process becomes more complex.
  7. Some features are can't be disabled on a per user basis, like High Availability (HA).
  8. The customer has to administer a process how users can get a higher plan.

We currently think the disadvantages outweigh the advantages.

Counting different types of users or other modifications of a user definition tend to lead to the same problems as above.

True-up pricing

Price difference between self-hosted and SaaS

Arguments to charge more for SaaS:

  1. The costs of SaaS are higher for GitLab.
  2. It is more logical in revenue recognition.

Arguments to at least make them equal:

  1. Self-hosted pricing in general tends to be higher.
  2. There is more market demand for self-hosted.
  3. No incentive for sales to sell SaaS over self-hosted.
  4. Self-hosted tends be be a better experience.
  5. We want to incentivize customers to move to SaaS with us.

Not sure what is normal in the market, Adobe did a good job but they moved from perpetual licensing to subcriptions but it is hard to compare the two prices.

When is a dollar not a dollar?

This is the title of a great article of which we'll apply the 8 points to GitLab below:

  1. Cost vs. revenue: we can help both to reduce costs and increase revenue, make sure you align to what the priorities of the prospect are.
  2. Principle agent problem: for a VP of Engineering you probably want to highlight our features that give her more visibility over features that save developers time.
  3. Existing expense vs. new expense: we can make use of existing budgets, be aware that multiple can apply (dev tools, security, operations, DevOps transformation).
  4. Above vs. below discretionary spending limits: one more reason to have multiple pricing tiers.
  5. Selling services vs. customized products vs off-the-shelf products: we're selling a high margin product and augment with services when needed to make the customer more successful.
  6. Selling to many stakeholders vs. one stakeholder: this is another reason for our multiple tiers, Starter is sold to the single stakeholder of development teams, Ultimate is sold to multiple stakeholders and will need the CIO to enforce the transformation.
  7. Monthly vs. upfront payments: that is why we only do yearly upfront, sometimes even multi-year upfront.
  8. Selling vs. upselling: this is why we have multiple tiers.

Only sell a suite

Most companies evolve in the following way:

  1. Sell one product
  2. Sell multiple products
  3. Sell multiple products and a suite of them
  4. Only sell a suite

An example is Microsoft Office where it is costly to buy components of Office365 separately, although higher tiers include more products. At GitLab we decided to skip the intermediate steps and immediately only offer a suite that includes all our products. Having our complete scope included in our open source version is even part of our stewardship promises.

Selling only a suite has risks, after the => is how we mitigate those at GitLab:

  1. Lose potential customers if people want one product. => Offer a Starter tier that is prices competitively with single products from competitors.
  2. Leave money on the table if people want all products. => Offer an Ultimate tier that is great value if you adopt everything of GitLab.
  3. Discount because people don't want all the products. => Make a discount conditional on not using part of the product.
  4. Tiers are harder to define than if you would have separate products. => Hard to mitigate, we have to work extra hard on communicating the differences.
  5. No revenue feedback from customer about what products they value more. => The product function focusses on usage data as our best proxy for value.

Companies evolve to selling only a suite for the following reasons, after the => is how this applies to GitLab:

  1. Makes it easier for organizations to adopt the other products. => This is essential, organizations have official solutions and GitLab grows with organic adoption from developers.
  2. Show customers the benefit of a single application. => This is essental since people are skeptical, showing beats telling.
  3. More usage of all the products. => This is essential for us due to our breadth over depth strategy
  4. Harder to displace the suite once it is in place. => This will help if competitors offer a service based on our open source code.

We're going even further than selling a suite by integrating everything in a single application. We do that because of the advantages mentioned on our direction page section about us being single application. A secondary effect is that the user doesn't have to make a buying, or even an adoption, decision.