search

gitpod-io / gitpod

The developer platform for on-demand cloud development environments to create software faster and more securely.
https://www.gitpod.io
GNU Affero General Public License v3.0
13k stars 1.24k forks source link

Epic: Usage-Based Pricing #9036

Closed svenefftinge closed 1 year ago

svenefftinge commented 2 years ago

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

In scope

No response

Out of scope

Complexities

No response

Press release

No response

Tasks

Skateboard (Alpha version)

Generate invoices for Team Gitpod only (week of Jun 27)

Usage UI (week of July ~4~ 15)

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

Admin views for team usage

Paywall

Usage List View

'Attribution Logic

Incremental Rollout Capability

Other

Polish

Early Access Usage Based Billing for Teams

Early Access Usage Based Billing for Individuals

General Availability

Other related Issues

ChristianHuff-DEV commented 2 years ago

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 commented 2 years ago

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.

ChristianHuff-DEV commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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