Most of GitLab functionality is and will be available for free in Core. 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 Core 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 a Starter, Premium, and Ultimate tiers. The price difference between each of them is half an order of magnitude (5x).
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 .com 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.
Our pricing philosophy is aligned with our GitLab Values.
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.
We have four pricing tiers. How we make decisions on a day-to-day basis is specified on our stewardship page.
|Per user per month||$0||$4||$19||$99|
|Who cares most about the feature||Individual Contributors||Manager||Director||Executive|
|Main competitor||GitHub Free||Atlassian BitBucket||GitHub Enterprise||Collabnet|
|Type of sell||No sell||Feature||Benefit/solution||Transformation|
When considering buyers as part of product tiering decisions we use the following 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 core 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 be intentional about planning the user journey from core to paid tiers for these features.
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 Core tiers 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 Core-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 capabilities resulted in improved conversion performance on our pricing page. While it is how we present the value of our tiers, this capability based representation serves as an additive filter for, and is not a replace of, our Buyer Based Tiering decision.
Here is a video of the CEO discussing this concept with a Product Leader.
The following are our current set of capabilities:
Premium/Silver (all above AND):
Ultimate/Gold (all above AND):
Because capabilities are filters for our Buyer Based tiers, there can occasionally be instances where a feature's tier and its natural capability don't match. In that case we should either:
Note - it is OK for the features of a capability to be in the listed tier and any lower tier.
Our lower tiers have:
Our higher tiers are 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 lowest 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 have separate names for .com and self-managed tiers because:
That being said, we want the .com and self-managed tiers to be as similar as possible. For example if a feature is in premium it should be in silver instead of bronze or gold.
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 comes from 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 $8, for example. But we want to make a our hybrid model work for the following reasons:
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, as we introduce more features. In 2016, sales people focused 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 customers who are not aware of this discount, and most customers 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 many 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 too 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 infinitely more value than the gratis Core 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.
A low price for the lowest tier is also how we mitigate the first risk of only selling a suite.
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.
We considered selling multiple plans to the same customer, allowing them to have some users on every plan.
The advantages are:
The disadvantages are:
We currently think the disadvantages outweigh the advantages.
Counting different types of users, roles for users, or other modifications of a user definition tends to lead to the same problems as above.
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:
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 four tiers are differentiated based on the buyer persona or IC who buys GitLab, from individual contributor, to manager, to 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:
Also see fork and commoditize in the list of our biggest risks.
A customer asked why merge request approvals where not included in core:
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: /handbook/ceo/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 higher tiers, but open source features should never move to paid tiers.
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 Core), 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: