Social coding gives developers a better way to work together and collaborative code service GitHub helps make it possible. Built in 2008 on the ethos of peer coding and bringing people together, GitHub currently has 34.7 million users and was reportedly doing $300 million in revenue this time last year when it was purchased by Microsoft for $7.5 billion (last updated 6/10/19).

In this episode of Pricing Page Teardown, Patrick and Peter dig into how GitHub tailors their pricing strategy to the technical aptitude of their buyer, and how that often-overlooked idea helped define their overall user-based pricing model.

GitHub understands the technical aptitude of their buyer

“A lot of us in a B2B marketing environment, if we are technical, we think our buyer is just as technical and they're going to understand this. Even just doing some basic qualitative testing and putting your pricing out in front of your target qualitative buyers, all of a sudden you're going to realize that, oh my God, this is so confusing and people can't understand it. I need to better explain it or I need to come up with a totally new pricing schema in order to go forward with those particular buyers.” - Patrick Campbell

Understanding your target customer and how they interact with your pricing isn't something that we talk about nearly enough. While a technical buyer will have no problem understanding exactly what they need from a service, the non-technical buyer is more likely going to need more guidance. The ability of a buyer to handle a certain level of complexity should dictate how your pricing schema is laid out on the page.

GitHub used to be all about solopreneurs and indie developers. Now Airbnb, Spotify, and even SAP have their code on GitHub. To keep up with this shift in the market, GitHub has had to adjust their pricing. Gone is the private repositories value metric; in is a per-user pricing model.

As these organizations grow, the need for more repositories and more developers grows as well. When a team reaches 16 or more developers, the pricing preference shifts drastically against pricing per repository. 

Solo developers and teams up to five share similar preferences – the number of repositories they need is very easy to predict and likely won't be that many. Once the team grows into the 6 to 15 developer tier, we see the trend start to shift more towards pricing based on user, features, and functionality. While still not as strong a preference as even larger teams, the shift from repository-based pricing to per-user or feature- and functionality-based pricing is apparent as teams grow.

In their move to a user-based pricing model, GitHub is tapping into the need of these larger organizations to project their relative spending. It's much easier to figure out the number of potential developers needed to accomplish certain projects than to know exactly how many repositories it will take to house and manage the code.

We see a different relationship than usual when breaking down preference on a per-repository basis. Typically as the size of a team increases, so would the want for more repositories. That's not the case with the 3,311 current, former, and prospective GitHub customers we surveyed. We see a level of understanding in these customers that speaks to their ability to plan out exactly how many repositories are needed as the team grows.

For teams of one to five developers, people don't want that many repositories, and for teams of 16 or more, it trends towards as many repositories as they can possibly get. But, as the team is growing through the 5 to 15 range, the need for additional repositories isn't there, and GitHub's customers understand that.

This helps support the move GitHub has made from a repository-based pricing model to one based on users. Their prospective buyers are much more technical and really comprehend the needs of their team going into the buying decision.

Feature differentiation is the key to a better pricing strategy

When we look at the willingness to pay per user in relation to GitHub's pricing page it's pretty much spot on. 

At the solo-dev level, willingness to pay sits at $9.43, which is slightly higher than the $7 Developer plan listed by GitHub. As the size of the team increases, the willingness to pay trends up as well. For two to five developers it comes in at $10.38 and flexes up to almost $15. The biggest increase comes in at the 6 to 15 developer team, where the willingness to pay is $17.43, a more than 60% increase.

As the team grows to 25 users or more, buyers are looking for more features and are more than willing to pay for them on a user-by-user basis.

When comparing relative feature preference against overall willingness to pay on a user-by-user basis, we see GitHub offering features that land all over the map. The perceived value gaps between Differentiable Features and Add-Ons speak to the potentially different kinds of GitHub users.

What's really interesting is the overall development-focused preferences like team and user permissions and unlimited private repositories. As an organization grows over time, these kinds of features become more important, and the willingness to pay is evidence of that.

Of the 3,311 current, former, and prospective GitHub customers surveyed, we found a lot of opportunity in the Add-Ons section of this value matrix. While a feature like 24/7 support might appeal to some customers, most technical buyers aren't really all that concerned with it as a feature. So, it would make more sense to offer it as an additional upsell as opposed to a core feature on the pricing page.

Feature preference does change, and something like multi-factor authentication is creeping closer to being a differentiable feature in the future. GitHub could learn a lot from services like Dropbox and Box and look into how their pricing differs. A lot of GitHub's competitors are starting to focus on these kinds of features.

Finding room for improvement in a growing market

“This is a pretty solid foundation but I think that it keeps me wanting more. I don't think there's enough feature differentiation, I don't think the feature differentiation is deep enough to necessarily justify the changes.” - Patrick Campbell

Depending on where GitHub sees its place in the market moving forward, they could potentially be missing out on the expansion revenue that can be expected from what is becoming an ever-more-crowded market. By focusing more on add-ons and expanded revenue from their current customer base, they can make the overall pricing experience better.

Neither Patrick or Peter is really the target buyer for GitHub, but from their standpoint the current pricing structure is a good jumping-off point. With more feature differentiation between pricing tiers and a targeted effort on what should be a core feature and what should be an add-on, GitHub can really make their solid pricing model into something great.