5 ms·
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 even
by jonas21 6y ago
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.
- x0x0 6y agoThere'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.
- afterwalk 6y agoIn 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.
- OkGoDoIt 6y agoIt’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.
- lmeyerov 6y agoNot so bad -- * 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
- ajford 6y agoAgreed. 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.
- jacquesm 6y agoThat's the correct way to do this.
- itronitron 6y agoLooking 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.
- stirlo 6y agoFrom 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.
- webmaven 6y ago> 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
- apple4ever 6y agoTheir whole pricing scheme is ludicrous, which they defend as "its better for GitLab!"
- johannes1234321 6y agoOne 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.