Epic: Usage-Based Pricing

[svenefftinge]

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)

• [usage] Initial setup for component #10227
• Deploy usage component experimentally into preview, staging & production environments #10316
• Define db models in Golang #10317
• [usage] Setup controller and reconciler #10249
• Setup dry-run flag for usage controller #10319
• Store workspace size used for a given workspace instance #10430
• https://github.com/gitpod-io/ops/issues/2554
• Write usage report into test-mode in Stripe #10322
• [Usage] workspace.go:68 Error 1390: Prepared statement contains too many placeholders #10642
• Make the frequency at which the usage reconciler runs configurable #10720
• Configure the usage component using a config file rather than command line arguments. #10753
• Add integration test for Billing Controller which asserts against mock Stripe
• Fix experiments configuration between staging & production #10851
• [dashboard] Add Usage-Based feature flag and empty Billing page #10302
• Use Stripe Elements to capture CreditCard information then create a Stripe Customer and Subscription #10326
• Show whether a user has a valid subscription and allow managing it #10327
• Configure usage-based Stripe product IDs (i.e. prices) #10655
• [Usage-based] Attribute workspace instances on start #10533
• [billing] Create a dedicated Stripe account for production #10856
• [Usage-based] Adjust d_b_workspace_instance.attributedTeamId to be not team-specific #10822
• [Usage-based] When payment is enabled, attribute all workspace instance usage to an explicitly selected "billing account" #10901
• Automatically set or unset a user's preferred "billing account" when they join or leave a single team with usage-based billing enabled #10973
• Use attributionId when listing workspace instances for usage #10922
• [usage] Ensure controller ticks are not concurrent #10995
• [usage] Expose metrics for reconciles started and duration #10996

Usage UI (week of July 4 15)

• Setup usage datastore and store usage #10323
• Define usage APIs #10324
• Implement usage APIs #10325
• Show usage details in usage view #10328
• Produce a usage report for a single gitpod team and validate #10320
• Differentiate usage of different workspace classes and types (prebuilds) #10985

Attribution of usage to team, with usage limits (weeks of July 11 & 18)

• [Usage-based] Implement a "Cost Center" entity #10757
• "Spending Limit" UI + storage #11401

---

• Add usage page empty state #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

• Paywall + Notification UI #11404
• Fix gRPC message size error in UpdateInvoices call #11998
• Implement BillingService.GetLatestInvoice #11692

Usage List View

• Allow users to switch between months and update usage page sidebar designs #11526
• Incorporate reverse-sorting arg from the API #11691
• Ensure end-to-end workflows: signup, usage reporting, limits, invoicing, cancellation #11930
• Improve pagination layout, design, and structure #11530
• Replace column sorting icon in usage page #11783

'Attribution Logic

• Fix usage reconciler failure with grpc: received message larger than max #11836
• Improve usage attribution in user settings #11498

Incremental Rollout Capability

• Billing controller excludes WorkspaceInstances which are already included in previous invoices #10937
• Define & Implement Entitlement Service APIs #11402
• Ensure end-to-end workflows: signup, usage reporting, limits, invoicing, cancellation

Other

• Fix usage reconciler failure with grpc: received message larger than max #11836
• Fix gRPC message size error in UpdateInvoices call #11997

---

Polish

• [usage] Adding loading state indicator when retrieving usage records #11677
• Stripe billing validation errors shows alert modal with [object: object] #10960
• Refine Spending Limit modal #11575
• Move usage component out of experimental installer config #11611
• Store generationId with every record in the usage table.
• [usage] Decouple billing controller from usage controller #10785
• Show workspace details in usage list view #11640
• Implement dropdown for the list of billing months #11685
• Usage report upload fails with GCS 403 #11688
• Race condition at usage component startup #11743

Early Access Usage Based Billing for Teams

• 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

• Feature flag to enable access to usage based billing for individuals
• Free usage credit
• Usage view for individuals
• Documentation for usage based billing for individuals

General Availability

• Pre-announcement
• Documentation
• Enable usage based pricing for all
• Stop chargbee personal and team plans (for new users)
• Refine Spending Limit modal #11575

Other related Issues

• Consider hiding usage tab for team members who are not owners #11588
• Improve usage page design when no data is present (empty state) #11587

[ChristianHuff-DEV]

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.

[jldec]

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.

[ChristianHuff-DEV]

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.

[SecludedL]

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!

[svenefftinge]

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.

[SecludedL]

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?

[svenefftinge]

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.

[SecludedL]

@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.