Remember when you make a pricing model for your company: you can never change it without some kind of backlash unless you can make things cheaper. So it's fine to charge a bit more initially and figure things out as you go, you can then lower the price once you've worked the numbers and/or have to respond to competitive pressure.
But changing your model will upset your customers, no matter how well you intend it and there will always be a backlash, especially from developers for tools because there is always going to be someone else that does it cheaper. Rely on the 'cost too switch' once too often and you will shed users and users that leave will never come back. It is easier to attract a new user than it is to get someone that got burned to return.
Do what you can to get it right the first time and build in some room. And if you do have to change it be willing to grandfather in the users that got you there for ever.
Everything you said makes sense -- but at the same time, when building a SaaS offering, your initial product may have much less functionality than what you eventually plan to build.
If you start at the price you want to charge in the end, people will look at the product and say, you expect me to pay $X for that?
One thing that may work is to offer early adopters a lower price, and keep them at that price forever, while charging later customers more. But to do that, you need to raise the price for new customers early and often -- otherwise you'll end up with too many people at the lower price. And if your costs scale with the scope of your product, that could mean you're losing money on a large fraction of your users.
* Grandfather current customers, which gitlab did at near minimum here (current year / ~no changes ?). ~Lifetime / tier would be better, esp as a growing co should be fine here revenue wise. Better current customers sing your praises internally + externally than say you're yet another couldn't-care-less quarter-driven bigco / sales-driven vc co: growth wins.
* Put new stuff in new plans/tiers. Gitlab VPs seem to be choosing a weak balance here.
I'm all for offering higher prices. Trick is, when adding stuff, people should pay more for more, and same / less for standing still. Let hungrier/spendier teams spend more, and cost-sensitive ones happily spread the good word.
Not what happened here? Gitlab seems big enough that all this doesn't really matter though, they are probably reaching a customer size and capital-intensitive enough moat that they don't care toooo much.
---
A good contrast is github / microsoft, which also is way into clever pricing:
- Way cheaper per-user at all tiers. We got tier-shifted at some point, but don't recall any pricing funniness during that.
- Adding customer abilities to spend infinite amounts, but via new layers, like pay-as-you-go CI/CD offerings that do not gauge existing users. I expect the prices to go down, not up, as they figure out more scaling tricks / computing improves and they try to get users more addicted.
GH/MS is probably working on a much bigger timescale than GitLab, as GH doesn't need to look at juicing numbers to fundraise / sell while buyers are willing, and instead focus on being a friendly shift-left answer to AWS/GCP
My last employer had been on the same GH tier for over 6 years or something like that, and was on a much older tier.
It lacked some of the new features, but the price-point was right for our team size, and we weren't yet at the point where the newer features (ci/cd stuff like Actions) were worth the cost hike.
We were planning on switching tiers to get the new features, which is exactly what you described. Let those who want the new things pay for them if/when they decide to make the switch.
Looking at their pricing page, it seems that the Ultimate tier, and even the premium tier, has a lot of features that many of their customers will never use.
I am assuming that the pricing plan is set by deployment and not by user, otherwise a company could buy 5 Ultimate seats, 20 Premiums, and the rest join for free. There is no point in buying Ultimate for 100 users when only 5 of them would ever want to use the Ultimate features.
From the FAQ on their pricing page:
"Can I acquire a mix of licenses?
No, all users in the group need to be on the same plan."
Which is frankly stupid. You make more money from 20 devs on ultimate and the rest of the company (100) on silver than you get from having 25 devs + essential managers on the ultimate plan and no one else using it at all.
Let alone the number of customers who will look for 120 licenses for the entire company and dismiss the entire product suite as they can't afford it.
> You make more money from 20 devs on ultimate and the rest of the company (100) on silver than you get from having 25 devs + essential managers on the ultimate plan and no one else using it at all.
That only has to be true WRT revenue. Depending on the margins (which, in the case of loss-leaders, are negative), it might not be true for profits
There's a difference between changing the pricing model and raising prices.
gitlab is changing their pricing model; as near as I can tell, they want to be a source control / jira / CI all-in-one environment. My guess is the willingness to pay vs github for just plain source control isn't there.
:shrug:
This is the risk with saas though. Customers are adults; they can choose to continue using your product or not. If customers don't want the saas they buy to be able to change models or raise prices, their choices are (1) don't use it; or (2) sign annual or even multiyear agreements. And if a company evaluates software that won't make multiyear commitments to them, they should take that unwillingness into account when choosing which vendor to use.
In other industries for example gaming and desktop tools, people eventually just ship a new version that existing users have to buy again. For continuously deployed web products a repricing is the only way to frame it in customer's minds.
It’s a subscription, so you’re rebuying it every month/year whether you want the new features or not. I miss the days when you bought something and could use it forever, and only had to re-up if the next version was actually so much better as to be worth the cost.
One approach for solving that can be (but might not work always) to add new features only to more expensive packages. Of course the lower tier users won't be happy with that either, but if there are notable new features they can make an argument.
I’m by no means a marketing expert, but showing your early users respect, courtesy, and-dare I say it-loyalty, seems intuitive to me but also less and less common in today’s Anything As A Service (pronounced like “ass”) tech environment. I don’t miss months-long sales cycles, prohibitive up-front costs, oppressive support contracts, etc., but I do miss having companies that will bend over backward to retain long-time customers. Everything has become a transaction, and every customer is just a fraction of a company’s overall revenue. I’m not dissing GitLab as I am not (yet) a paying customer, just commenting on the state of software in general.
I generally agree. We've always taken the "grand-fathering" approach, but it can get a bit more complicated as your product and offerings grow. If someone was paying $XX /mo for your initial offering, and a few years later, you're able to provide a number of new features within that product, I don't think you necessarily need to continue providing those extra features simply because someone signed up earlier.
To your point, you may face a backlash. But it also costs a lot of time and $$ to support new development and features. Therefore, having some backlash may still be the right decision in the medium/long term. Can be hard to weather that storm initially, though.
The features that they paid for in the first year have already been paid for by the customers. While it costs the vendor time and money for new features it doesn't cost them money for old features. Therefore under a subscription model that payment should be covering the cost of new features.
I think I'd reply to this with a "yes and no" kinda thing. For us, maintaining anything requires time and $$. This is, in part, because technology changes. Even in a vacuum with no new active development, money and $$ is required to ensure everything stays up and running.
eg. as our use base has grown, so too has our database. And so while the optics of it from the end-user POV is that the product has remain unchanged, we've had to invest in database and scaling services in order to continue to meet the initial offerings.
It's not as simple as that, but you probably get the gist of it.
A more relevant example might be a web service that emails you once a week. If the mailing service that powers this requires DNS or integration changes to help fight spam, over time that will require time (and perhaps $$).
If I'm misunderstanding your point, let me know :)
I remember an in-person presentation by Unbounce talking about their pricing model. They realized that anyone paying less than $99/month was not worth their time, so they removed those plans, barely reducing their monthly revenue, and focused on the high-end customers.
Looking at their pricing structure today, I see $80 being the lowest tier, going all the way to $300
Depending on your market, killing off cheaper plans might barely impact your revenue at all... right up until you stop getting bigger contacts because there's no on-ramp customers to try your services before going all-in.
I can't tell if this comment is meant sarcastically but if 100% of your customers leaves you are dead in the water. Most companies would not survive a 50% drop, especially not companies where network effects and evangelism are a strong factor in their survival. Gitlab is one of those.
But changing your model will upset your customers, no matter how well you intend it and there will always be a backlash, especially from developers for tools because there is always going to be someone else that does it cheaper. Rely on the 'cost too switch' once too often and you will shed users and users that leave will never come back. It is easier to attract a new user than it is to get someone that got burned to return.
Do what you can to get it right the first time and build in some room. And if you do have to change it be willing to grandfather in the users that got you there for ever.