Pricing

On this page

Departments

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: CE EES EEP EEU
Per user per year $0 $39 $199 $999
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$, $39, $199, $999 per user per year, a price difference of infinite, 5x, 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 $99. 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 raising the price of the lowest tier will prevent people from starting with GitLab. It will raise sort 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.

Charging $99 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.

Selling per main feature

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.

True-up pricing

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, EES is sold to the single stakeholder of development teams, EEU 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.