Settings/Plans should show billing date (== plan hours reset date) for plans having limited hours

[david-bakin]

Since the Open Source and Personal plans have limited hours, and reset the counter based on the billing date, I suggest (for convenience) that the Settings/Plans page for those types of accounts show that date.

[gtsiolis]

@david-bakin Although a bit hidden, we do show the billing cycle dates when hovering over the remaining hours.

Also, @ionutale has opened a community contribution to improve this area and make it clearer and more accessible, see relevant comment #9716 (comment).

[david-bakin]

ooooh ... that's not obvious! or at least it wasn't to me - somehow my mouse cursor never went there ...

One of the very nice things about the gitpod UI (dashboard, and other pages) is that it is simple and straightforward. I'd like to suggest you keep it that way! Everything should be visible. The video-game approach to UI design, where you hover or click at random, to discover what you can do, should be avoided for production services like this one! IMO! 🙂

[gtsiolis]

Thanks, @david-bakin! Agree, the plan is to remove as many on-hover tooltips as possible in plans and in the product in general, hence the proposal in #9716 (comment). 🗺️

[ionutale]

hi @david-bakin,
@gtsiolis said "We're currently working towards a usage-based pricing", so I think that the billing period will start from 1st of the month for everyone.

I do agree that is not very obvious to hover to see the billing period.

@gtsiolis and @david-bakin what do you think about an info button next to the remaining hours?

(this is just a mockup in inspector tools)

[david-bakin]

The info button looks good to me: it's a visible thing, and people are used to that circle-i style icon as an "additional information" button on many websites so it's an obvious target for a click.

---

And now for an off-topic remark: I didn't want to comment right on the "usage based pricing" epic - since it's a long-term tracking issue - but I'm hopeful that there will still be room for the independent individual working on individual - not team - projects in the pricing structure. Obviously the company needs teams at companies to pay the ongoing bills and for expansion/development, and also obviously the individual developers probably all together don't add that much revenue and perhaps use resources out of proportion to that revenue, maybe, and aren't easy to market to anyway, but still: that's where I am.

And I'm perhaps atypical in other ways too: As a C++ developer whether or not my elapsed hours of usage are out of the ordinary or not my load on systems when I'm using them might very well be higher than usual, making my workspaces resource intensive relative to others, and possibly a bad neighbor on a VM, plus prebuilds might be heavy too. Or at least that's my impression, doing compiles of projects with make -j14, recompiling an entire project with different compiler options, etc., without actually having access to any performance dashboard. And on the other hand I do keep only one workspace active at a time, I stop workspaces manually when I know I'm going to step away rather than let them time out, and I constantly prune my stopped workspaces, keeping only the last 2, generally, so maybe my storage requirements are less than others.

Anyway, I'm on the $9/mo plan for the last month as I've started using Gitpod and can see moving to the $25/mo plan as my usage ramps up to get past the 100hr/mo limit (I don't need the parallel workspaces or teams features of that plan). I believe I like the certainty of a fixed monthly subscription better than a usage-based metered system. Easier to explain the bill to the spouse. But I could be wrong ... depends on the structure and pricing that gets set up.

[gtsiolis]

@gtsiolis and @david-bakin what do you think about an info button next to the remaining hours?

@ionutale Using an icon with a tooltiop could be a viable solution although it'd be preferable to avoid using icons, tooltips as much as possible for accessibility reasons, etc. Let's move this discussion to the open PR in #9716 instead of using this closed issue.

🍊 🍊 🍊 🍊

I'm hopeful that there will still be room for the independent individual working on individual - not team - projects in the pricing structure.

Thanks for the feedback, @david-bakin! I'll circle your feedback also internally with the team. FWIW, The current plan of the usage-based pricing is to continue providing individuals and teams similar capabilities when using the product for free, create a smoother transition for existing paying customers, and more.

[jldec]

Hi @david-bakin,
Regarding usage-based billing, if we charged you monthly by usage and provided a "Spending Limit" mechanism which you could configure with a fixed amount (to prevent surprises), would that alleviate some of your concerns?

[david-bakin]

Yes, @jldec , that would work, especially with the dashboard pricing page (or something else) keeping a fairly current track of where you were on your various limits. (Not necessarily real-time, but, say, no more than a daily accounting run out-of-date.)

BTW, I certainly do not object to paying for services received! I'm a professional independent developer and that's how I make a living! But I personally have an interest in "so how's it gonna work for me?" - as you might expect! (And at the same time you don't have to tell me how you, as a project manager or business owner, have to make tradeoffs between one set of business needs and another which necessarily impact different customers differently ...)