gitpod
gitpod copied to clipboard
gitpod-io
Epic: Usage-Based Pricing
Summary
Gitpod's SaaS pricing shall be based on usage rather than number of seats (current state).
Context
We believe the value received by teams and individuals is correlated with the time spent using Gitpod which makes usage hours (not seat count) our value metric. While seat count serves as a proxy, we believe usage is a more accurate predictor of customer value. Hence, we believe our current pricing creates friction in turning users into paying customers and limiting the potential upside of large clients for Gitpod (fixed €35 for unleashed plan).
Value
Align value users gain with what they pay. Make it easier for new team members to join a team and grow into the product as they use it more often.
Moving away from the existing user-based subscriptions to usage-based pricing has become more important because we need this to ship Different Workspace Classes as well as allowing for flexible workspace timeouts.
Acceptance Criteria
Users and teams can purchase credits and use them run workspaces.
Measurement
TBD
Growth Area
Expansion
Persona(s)
No response
Hypothesis
- Gitpod is most valuable in team settings (i.e. >1 contributor to the codebase).
- Ephemeral dev environments are mostly useful for projects with 2+ contributors. Single-person projects can easily live in a long-lived workspace.
- Seat-based pricing leads to situations in which the customer pays even though they are not using the product. (Large) companies are familiar and comfortable with usage-based pricing.
- competition used usage-based pricing.
In scope
No response
Out of scope
- Automatic migration of existing subscriptions
Complexities
No response
Press release
No response
Tasks
Skateboard (Alpha version)
Generate invoices for Team Gitpod only (week of Jun 27)
- [x] https://github.com/gitpod-io/gitpod/pull/10227
- [x] #10316
- [x] #10317
- [x] https://github.com/gitpod-io/gitpod/pull/10249
- [x] #10319
- [x] https://github.com/gitpod-io/gitpod/issues/10430
- [x] https://github.com/gitpod-io/ops/issues/2554
- [x] #10322
- [x] https://github.com/gitpod-io/gitpod/issues/10642
- [x] #10720
- [x] #10753
- [ ] Add integration test for Billing Controller which asserts against mock Stripe
- [x] #10851
- [x] https://github.com/gitpod-io/gitpod/pull/10302
- [x] #10326
- [x] #10327
- [x] #10655
- [x] #10533
- [x] #10856
- [x] #10822
- [x] #10901
- [x] #10973
- [x] #10922
- [x] https://github.com/gitpod-io/gitpod/pull/10995
- [x] https://github.com/gitpod-io/gitpod/pull/10996
Usage UI (week of July ~4~ 15)
- [x] #10323
- [x] #10324
- [x] #10325
- [x] #10328
- [x] #10320
- [x] #10985
Attribution of usage to team, with usage limits (weeks of July 11 & 18)
- [x] #10757
- [x] #11401
- [x] https://github.com/gitpod-io/gitpod/issues/11495
Week 01-05.08.
Admin views for team usage
- [ ] Admin dashboard: Show active billing subscriptions for a team (team-plans or UBP)
- [ ] Admin dashboard: Show detailed usage for a team
Paywall
- [x] #11404
- [x] #11998
- [ ] https://github.com/gitpod-io/gitpod/issues/11692
Usage List View
- [x] https://github.com/gitpod-io/gitpod/issues/11526
- [x] https://github.com/gitpod-io/gitpod/issues/11691
- [x] #11930
- [x] https://github.com/gitpod-io/gitpod/issues/11530
- [x] https://github.com/gitpod-io/gitpod/issues/11783
'Attribution Logic
- [x] #11836
- [ ] https://github.com/gitpod-io/gitpod/issues/11498
Incremental Rollout Capability
- [ ] #10937
- [ ] #11402
- [ ] Ensure end-to-end workflows: signup, usage reporting, limits, invoicing, cancellation
Other
- [x] https://github.com/gitpod-io/gitpod/issues/11836
- [x] #11997
Polish
- [x] https://github.com/gitpod-io/gitpod/issues/11677
- [ ] https://github.com/gitpod-io/gitpod/issues/10960
- [ ] https://github.com/gitpod-io/gitpod/issues/11575
- [ ] https://github.com/gitpod-io/gitpod/issues/11611
- [ ] Store
generationIdwith every record in the usage table. - [x] #10785
- [ ] https://github.com/gitpod-io/gitpod/issues/11640
- [ ] https://github.com/gitpod-io/gitpod/issues/11685
- [x] https://github.com/gitpod-io/gitpod/issues/11688
- [x] https://github.com/gitpod-io/gitpod/issues/11743
Early Access Usage Based Billing for Teams (end of July)
- [ ] Configure selected teams as Early adopters, through feature flags
- [ ] Enable VAT and AR report generation
- [ ] Dark-ship documentation for usage based billing for teams
Early Access Usage Based Billing for Individuals (August 12)
- [ ] Feature flag to enable access to usage based billing for individuals
- [ ] Free usage credit
- [ ] Usage view for individuals
- [ ] Dark-ship documentation for usage based billing for individuals
General Availability (August 26)
- [ ] Documentation
- [ ] Enable usage based pricing for all
- [ ] Stop chargbee personal and team plans (for new users)
- [ ] Announcement, marketing
- [ ] #11575
Other related Issues
- https://github.com/gitpod-io/gitpod/issues/11588
- https://github.com/gitpod-io/gitpod/issues/11587
For me as an individual user this might be a negative change.
Gitpod is most valuable in team settings (i.e. >1 contributor to the codebase).
For me this is not true. I use Gitpod to work on my side-projects. (The might put me out of the scope of the audience you are targeting.) The value arises for me that I don't have to pollute my machine with different setups for different projects and that I can use a lower end machine (MacBook Air) even to develop on larger projects.
Ephemeral dev environments are mostly useful for projects with 2+ contributors. Single-person projects can easily live in a long-lived workspace.
Again even as the single contributor on my projects, Gitpod provides huge value. Especially switching branches couldn't be easier.
Seat-based pricing leads to situations in which the customer pays even though they are not using the product. (Large) companies are familiar and comfortable with usage-based pricing.
For me the fact that I know how much it costs is worth more than the possible savings. I work in a (larger) company but as far as I'm aware most of the tools (Jira, Confluence, GitLab) we are using are seat- not usage-based.
competition used usage-based pricing.
Can't argue with that ;) But it is one of the reasons I prefer Gitpod.
I guess for me it comes down to the pricing model. As long as I get the same amount of hours for what I'm currently paying (8€ for 100h) it doesn't matter if its a fixed or flexibel price. I'd probably rather see an increase in price (maybe 12 instead of 8€?).
But since I was thinking about upgrading to the Professional plan, the question would be what an hour costs.
Hi @ChristianHuff-DEV,
Thanks for the feedback - you make valid points.
Here are a couple of notes about the planned changes from Gitpod. Please note that these plans are not set in stone and may very well change.
- With usage-based billing, Gitpod will continue to offer limited free usage, in the form of recurring free usage credits.
- We're not quite ready yet to share details like per hour costs for different workspace classes.
- When you setup usage-based billing you should also have a way to configure a "spending limit" to avoid billing surprises.
- In future, we may also offer discounted usage credits for prepaid usage.
Thanks for the answer. The spending limit sounds like a great idea. I really came to love Gitpod and hope you'll find a way to make it work for companies and individual users.
Hello! We are a company using Gitpod Unleashed and would certainly be open to paying per usage (and pay more) if we could remove timeouts in certain situations (especially the 2/3-minute timeout triggered when someone closes the browser).
To explain our scenario and why we'd be open to pay for usage: we currently use Gitpod to deliver our coding tests to candidates. As we can't give them direct access to the repo hosting the test project, we generate a workspace for each of them and then share the workspace individually. In most cases, we have to prepare the workspace 30 minutes - 1 day ahead of the tests, as most candidates can't commit to an exact time. Right now, our test delivery team needs to make sure they don't close the browser window so that the timeout isn't reduced to 3 minutes, giving us a 3-hour window to deliver the test. That sounds good in theory, except that in about 75% of the cases we still hit a timeout - either because someone's computer hibernates, they accidentally close the tab or, in some cases, for no understandable reason. Needless to say, people are very frustrated.
Although some Gitpod competitors offer Always-On pods that basically solve all of our problems, we still think that Gitpod is the superior platform in terms of UX and we'd be more than open to paying significantly more (per usage?) just to have Always On pods or some kind of extended timeout that ignores browser window closes (at least it would make timeouts more predictable).
I know we're probably very atypical in terms of usage pattern, but maybe tweaking the current plans and timeouts a bit will enable a lot of other scenarios as well, such as ours.
PS: we'd be willing to pay more per seat if you can create some private plan that disables the tab close timeout and has an extended timeout of around 12-24h.
Thanks!
hey @SecludedL, allowing custom timeouts is one of the main motivations behind going for usage based pricing. So we'll allow that soon. You can follow #9038.
hey @SecludedL, allowing custom timeouts is one of the main motivations behind going for usage based pricing. So we'll allow that soon. You can follow #9038.
Thank you for the prompt response! Will we also be able to remove/extend the timeout for the "tab closed" event?
Since we finally went GA yesterday, I believe, it's time to close this epic and work with new tickets and epics on follow up improvements.
@svenefftinge - Thank you for the update and great job on launching the Pay-as-you-go plan in such a short time!
However, can you please confirm that we'll be able to remove the browser close timeout? We switched to the new plan on Friday and still had the same timeout issues as before, with no option of opening a pod and having it available for the extended timeout duration (3h) even if the browser window is closed.