GitLab's pricing strategy is set by the CEO, Sid Sibrandij. Everyone can contribute, and the best way to communicate is on the #pricing Slack channel.
Contributions are part of the day-to-day jobs of the following people:
Most of GitLab functionality is and will be available for free in our Free tier. Our paid tiers include features that are more relevant for managers, directors, and executives. We promise all major features in our scope are available in Free too. Instead of charging for specific parts of our scope (CI, Monitoring, etc.) we charge for smaller features that you are more likely to need if you use GitLab with a lot of users. There are a couple of reasons for this:
Because we have a great free product we can't have one price. Setting it high would make the difference from the free version too high. Setting it low would make it hard to run a sustainable business. There is no middle ground that would work out with one price.
That is why we have Premium and Ultimate tiers. The price difference between them is less than half an order of magnitude (about 3x).
We will charge per user, per application, or per instance. We do include free minutes with our subscriptions and trials to make it easier for users to get started. As we look towards more deployment-related functionality on SaaS it's tempting to offer compute and charge a percent on top of, for example, Google Cloud Platform (GCP). We don't want to charge an ambiguous margin on top of another provider since this limits user choice and is not transparent. So we will always let you BYOK (bring your own Kubernetes) and never lock you into our infrastructure to charge you an opaque premium on those costs.
As a commercial organization, we always want to grow the number of paying customers, therefore we are focused on increasing the free to paid conversion rate. However, GitLab offers a free product, and our free users bring tremendous value to the company beyond just the likelihood of converting to a paid customer one day.
Our pricing philosophy is aligned with our GitLab Values.
We take a value-based pricing approach at GitLab. The core of the value-based pricing is to understand the value proposition that our innovations provide to our current and future customers for that offering. We aim to price our offerings to achieve continued growth and financial success for both the customer and GitLab.
To understand the value that we deliver to our customers, we focus on the benefits that our customers can receive to achieve their business goals. The value to our customers can include:
Defining and quantifying the value being delivered does not happen in isolation. We regularly engage with customers to understand how our solutions help them. These engagements are important as they will provide insights on how our innovations are valued by the customers and how it impacts our customers’ willingness to pay. Willingness to pay is a crucial element when we decide on how to price and packaging our offerings.
We understand that customers have choices when they decide to make a purchase. Hence, understanding the competitive landscape of our products is very critical. With respect to competition, we focus on the key differences between our value proposition and the competition’s value proposition. Our pricing aims to reflect the differential value that we provide. We aim to design the pricing structure that works best for our customers compared to our competitors inclusive of pricing metric.
To following our pricing philosophy, we aim to support long-lasting customer relationships. When we develop our pricing, the target is that both our customers and GitLab become successful together. For long term success, where we can run a sustainable business and meet our company’s financial goals, we do also consider cost to serve and margins as factors when pricing is determined. It is important to note that while costs and margins are factors in pricing, value provided to our customers is the foundational element.
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 paid tiers.
The following table describes how large cross-functional pricing decisions should be made. This decision making method differs from our normal RADCIE method due to the extremely cross-functional nature and business risk of large pricing decisions.
| Responsible | Sr. Director, Pricing | Responsible for analysis and recommendation |
| Agree | Chief Product Officer, CRO | Should ideally agree with the recommendation |
| Perform | Pricing, Fulfillment, Sales Ops, Product Marketing, and Website teams | Executes the recommendation |
| Input | CMO, CFO | Should be consulted and allowed to provide input prior to decision |
| Decide | CEO | Final decision maker |
We have three pricing tiers. How we make decisions on a day-to-day basis is specified on our stewardship page.
| Self-Managed/SaaS tier | Free | Premium | Ultimate |
|---|---|---|---|
| Per user per month | $0 | $29 | $99 |
| Who cares most about the feature | Individual Contributors | Directors | Executives |
| Main competitor | GitHub Team | GitHub Enterprise | Veracode, Checkmarx |
| Type of sell | No sell | Benefit/solution | Transformation |
When considering buyers as part of product tiering decisions we use the following guidance:
When the tiering of a feature is being evaluated, the stewardship promise will override this guidance.
Understanding the distinction of our buyer-based model can be difficult. In it we focus not on the user of the feature, but on the buyer and in what cases a feature would be useful to that buyer even in cases where the buyer is not the user. When making these decisions we ask questions like:
Below we list product categories and the current and proposed features which reside in a given tier to highlight how the buyer-based model works in practice.
While our tiers are based on who leads the purchasing decision there are occasions where driving increased usage takes precedence over the natural buyer-based tiering, always in favor of moving features to lower tiers. Here's why: As GitLab develops new categories that are likely to be in paid tiers, it is still reasonable (and in many cases advisable) to get the early MVC versions to land in the free or lower paid-tier to spur adoption, encourage contributions and gain feedback from the wider user base. Over time, the team can then add more features on top of the MVC functionality that will be placed in the paid-tiers. However, Product Managers should not move features down in violation of the buyer-based model unless there is a concrete high confidence plan to follow up with meaningful additions to the base feature that can be added to and monetized with the right paid tier
When considering tiering, if the feature is geared to be used (not purchased) by individuals and the answer to the question of who cares most about this feature? is today - very few people we should consider open-sourcing it to get more usage and contributors. Regardless of the reasoning behind the down-tiering of a feature, the process should still be followed.
If a feature in the free tier (typically useful to ICs, but also to others) will open up the possibility to circumvent or abuse our tiering policy, we should exercise extreme caution and err on the side of maintaining the feature in a paid tier. An example of this is repo pull mirroring that is useful for ICs and can also be great for adoption (i.e. trying out GitLab.). However, it may also lead to larger instances in Free tier mirroring to smaller instances in paid tiers to make use of paid-tiered features. This goes against our pricing terms & conditions and therefore we chose to keep the feature in a paid tier instead of Free tier.
When building integrations to partners it is possible to make exceptions to our buyer-based model when our tiers don't align well with those of the partner, but only in favor of lower tiers. As an example - a partner who provides a team collaboration tool with a free tier might desire any GitLab integration to be present in our free tier despite it clearly being appropriate for single team usage. The go-to-market benefits of this partnership can outweigh the divergence from our buyer-based model.
We've found that bundling our features within tiers into themes resulted in improved conversion performance on our pricing page. While it is how we present the value of our tiers, this themes-based representation serves as an additive filter for, and is not a replace of, our Buyer Based Tiering decision.
Themes are then bundled into customer value drivers.
The following are our current set of capabilities:
Because themes are filters for our Buyer Based tiers, there can occasionally be instances where a feature's tier and its natural theme don't match. In that case we should either:
Note - it is OK for the features of a theme to be in the listed tier and any lower tier.
Our lower tiers have:
Our higher tier is still the best option for our customers:
There are multiple reasons why our lower tiers have more relative value:
Arguments in favor of raising the price of the lower tier (which we won't necessarily do) are:
Please note that all the above is not a plea to add more or fewer features to lower tiers, we should just follow our Buyer Based Open Core model.
We use the same names for SaaS and Self-Managed tiers because:
There is a big price difference between the different tiers (0$, $29, $99 per user per month, a price difference of infinite, about 3x). For GitLab Inc., the majority of revenue comes from large enterprises buying the top two tiers.
Most companies in a similar situation would focus only on the highest tiers. But we want to make a our hybrid model work for the following reasons:
A 3x higher price doesn't mean there is 3x more value, just like the Premium tier doesn't provide infinitely more value than the gratis Free 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, saving time on integrating tools, driving faster time to value, and retiring other tools. This should more than pay for the increased price of a tier. An analogy would be Apple's 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 the extra cost.
As Stripe documented: hybrid is hard, because "The most common result of attempting both models simultaneously is that only one of the models receives any traction, and (because these models weave themselves into all operations of the company) it typically strangles the other."
This hybrid models is how we bridge the chasm between self-service and enterprise.
We tried selling one feature at a time, but this 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:
The disadvantages are:
We currently think the disadvantages outweigh the advantages.
The advantages are:
The disadvantages are:
We believe having a single plan for one customer works because the advantages outweigh the disadvantages.
For the GitLab sales team and for GitLab customers, we suggest handling the objection by focusing on the value and business outcomes
As our customers adopt GitLab as the single application for their entire DevOps lifecycle, we are hearing more and more non-developer use cases using GitLab for Agile project management. The main functionality that some non-developer roles need aligns fairly well with our reporter permission access, including Managing Labels, Assigning Issues, and Creating and Editing Epics, etc. Those users don’t really need to use much other developer functionality.
Currently, we do not offer a different list price for users who only need the reporter permission because:
We understand that our customers have non-developer use cases. Please contact our sales team or connect with us via this issue to discuss your specific use cases.
Arguments to charge more for SaaS:
Arguments to at least make them equal:
Not sure what is normal in the market. Adobe did a good job, but they moved from perpetual licensing to subscriptions, where it is hard to compare the two prices.
This is the title of a great article of which we'll apply the 8 points to GitLab below:
Annual, up-front pricing is currently our only offering. All internal systems should show only annual pricing to keep comparisons simple. We do show monthly pricing externally.
Arguments supporting annual up-front pricing:
Arguments supporting also offering monthly pricing:
Almost all SaaS products show monthly pricing on their pricing pages. GitLab shows monthly pricing on our website and notes clearly that it is billed annually. This is also a standard practice followed by companies like Salesforce. We previously have tried showing annual pricing on the website, but repeatedly heard from customers that they were confused by it. They often thought our product was priced significantly higher than it actually was because they expected the pricing to be displayed in monthly units and read the annual price as though it were per month.
Most companies evolve in the following way:
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:
Companies evolve to selling only a suite for the following reasons, after the => is how this applies to GitLab:
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.
Charging one price that incorporate all our stages is the perfect bundle.
There are two factors that determine how much value GitLab creates for an organization, in order of importance:
When an organization is larger, the benefits of GitLab are larger because:
Since GitLab is an open core project, we'll always create much more value then we (are able to) capture. Based on the value created, the straightforward way to capture value would be to:
These straightforward ways are not possible for the following reasons:
So we're left with charging for features. We can't charge for each feature separately, since that is unwieldy for the customer. So we charge for tiers that contain a bundle of features. We select features in the (more expensive) paid tiers that:
Adding features to a (more expensive) paid tier is not the only thing stopping users from adopting them, but it is a very important factor.
To simplify the above, we base our feature groupings on champion position (see below).
We make feature tiering decisions based on: "Who cares most about the feature". Our three tiers are differentiated based on the buyer persona or IC who buys GitLab, from individual contributor, to manager/director, to executive. Every person in the company is on the same tier, even if they don't use all the features. The feature is put in the plan based on what champion is most likely to care about it. Buyers make sense, since a higher-cost plan needs a higher-placed buyer.
Alternatives that don't work:
More detail about this in Sid's presentations about Buyer-Based-Open-Core at the Open Source Leadership Summit in 2019 and at Heavybit.
Also see fork and commoditize in the list of our concerns.
A customer asked why merge request approvals were not included in free:
Thanks for asking. We think that managers are more likely to care about merge requests approvals than individual contributors. That doesn't mean that individual contributors don't care about them. And it doesn't mean that in all cases managers care more, just in most cases. For more information please see our Buyer Based Open Core model: /company/pricing/#buyer-based-open-core.
We should not hesitate to open source features. When we put a feature into too high of a tier we should move it quickly because not having it in all tiers limits who can use the feature and this hurts:
In most cases the following guidelines apply:
Below is a video with the CEO discussing the philosophy of this with a Product Manager:
When in doubt, we will default to moving features to a lower tier, moving it down quickly if data shows that this is more appropriate. Not all tier changes will involve moving things to lower-priced plans and paid features may move into the higher tier, but open source features should never move to paid tiers.
Occasionally, a feature may unintentionally become available at a lower-tier due to a bug. This can include the free (open source) tier. When we fix the bug and return the feature to the correct tier, this is not the same as moving an open source feature to a paid tier. The definitive source for a given feature's tier is our documentation.
We should focus on building new features that buyers want and making sure that the initial assessment of new features is never too low. While we reserve the ability to move features up in tier, proving the necessity has a much higher bar since we are constraining the existing reach of a feature rather than expanding it.
Please also note that the CEO is in charge of pricing and tiers; this is delegated to product for the day-to-day work. While other parts of the GitLab organization are consulted, the CEO is the directly responsible individual.
To propose a change that impacts pricing or changes a feature's tier (e.g. moving a feature from Premium to Free), please follow the process outlined in the Feature Tier or Pricing Change issue template.
What is interesting is that GitLab creates more value as you adopt more of it. This shouldn't be confused with DevOps maturity. DevOps maturity is how advanced your practices are and how fast your DevOps lifecycle is, shown in cycle analytics. With the best practices embedded in GitLab, you will mature faster than without it. GitLab enables a 200% faster DevOps lifecycle. But DevOps maturity is mostly about organizational change. GitLab the product is just an enabler of it. Even if an organization uses everything of GitLab (high DevOps score), they can still have a slow process (slow lifecycle). We know there is a correlation between a higher DevOps score and a faster lifecycle; but especially in organizations new to DevOps, it is a trend, not an absolute. Linking our tiers to maturity would mean we don't ask any money from the large organizations that currently have a slow lifecycle but that are making it faster by adopting all of GitLab. These large organizations with a slow lifecycle benefit the most from GitLab, since they can adopt it completely, because they are not held back by an existing toolchain.
As suggested by a user on Twitter. This is a good suggestion to consider given the GitLab approach to adapting to local markets throughout the business. GitLab will assess viability of the idea in our overall pricing strategy planning. It is difficult to do and our assessment of this will consider:
