Phase 1: Split Between Starter and Premium Tiers

[MarianRaphael]

Description

Phase 1 of this transformation concerns the creation of a "Starter" tier, which we aim to make more of a package than a tier. This new package would allow for 2 Node-RED instances, 2 Devices and 2 team members for a fixed price per month. While SLA’s won’t be provided for the service or support, support will be done through a public forum.

Packaging details: Google Docs

### Tasks
- [ ] https://github.com/flowforge/flowforge/issues/2282
- [ ] https://github.com/flowforge/flowforge/issues/2359
- [ ] https://github.com/flowforge/flowforge/issues/2360

[joepavitt]

Key focal point for design phase here is what the upgrading path looks like - how do we limit resourcing, but advertising next package options?

[MarianRaphael]

Yes, exactly. Key UX paths are:

• What should the information page look like, either directly before or after providing payment information?
• How should we display the limits of the starter package?
• What should the user journey look like when upgrading to Premium?

[joepavitt]

First pass at a new "Billing" view for those on the "Starter" tier. Will be designing a variation of this for "Premium" and working on an "Upgrading to Premium" workflow/screen:

[joepavitt]

Thoughts on how we show the "comparison" as they're going through upgrade, to be explicit about what changes there are to plans, and what they're getting for their money.

[joepavitt]

Couple of variants for the "Premium" Equivalent which requires a deeper breakdown of costs and items (as now paying per instance). The technical challenge here is how do we build something that is friendly on both starter/premium, but without compromising hard-coded statements that are just built to our own billing model on FF Cloud, and dismisses the FF self-hosted option.

Option A: More consistent with the "Starter" design I have, but would probably require tooltip explnation for hte 6/0/0 instance values.

Option B: Tried to group accordingly with the instances, and a broken down statement of sizing.

[joepavitt]

The annoying challenge here is that the number of instances/devices can be split across Applications. The Instances list view is bound to an Application. So we're not sure if they're breaching limit without additional API calls to other applications.

[joepavitt]

On the Instances view, we could mimic the style introduced here, with something like:

Challenge is a configuration/definition of that message, and the rules for display. Easy solution is as we've done the existing checks for Trials, but here it's a little more complex, as would also have consequences for messages being shown to all FlowForge instances. In this case though, I think that's okay? How does OS get affected by this new packaging? Is that still free for all, or are we introducing caps there too @MarianRaphael?

[MarianRaphael]

@joepavitt in this iteration, the open-source version (feature set) remains unchanged. In the Google Docs file, you can see both variants: FF Cloud and Self-Hosted. As a result of the issues here, we end up with two tiers for FF-Cloud (Starter/Premium) and two tiers for Self-Hosted environments (OS/Premium).

[MarianRaphael]

Option B: Tried to group accordingly with the instances, and a broken down statement of sizing.

I like Option B more, it looks cleaner and more structured to me.

[iskerrett]

Will we still have a Free Trial for the Starter package? If yes, we might want to also consider what is the upgrade UX from free trial to paid package.

[MarianRaphael]

@iskerrett Yes see https://github.com/flowforge/flowforge/issues/2282 @joepavitt could you pick this up, or would it basically be like this here:https://github.com/flowforge/flowforge/issues/2328#issuecomment-1612963139

[joepavitt]

Not sure we (for now/1.10) need tk venture too far away from the UX of existing trial users which shows a consistent banner across the top of the platform indicating time left on trial, that they need to setup billing to keep instances beyond 30 days, etc

[joepavitt]

Although, actually I guess now the decision isn't just I want to pay for FF Cloud it's I want to pay for FF Cloud, and need to choose which tier?

In which case, the screen I designed for Starter > Premium is suitable, where each side becomes clickable and customised to the resources used so far in trial (number of instances, etc)

[joepavitt]

Quick thoughts based on https://github.com/flowforge/flowforge/issues/2328#issuecomment-1612963139 (note the empty state graphic will be updated to reflect the page, just put that in as a placeholder), where the rows in the plan options would be driven by what they're using right now in their Team, e.g. in this example we have 2 x Team Members, 1 x Instance and 2 x Devices.

"Upgrade to Tier" options would then go to Stripe.

Figma Prototype

https://www.figma.com/proto/rMB2w5ZZUtTC0nxbwLYKJY/FlowForge-Platform?page-id=0%3A1&type=design&node-id=2493-18259&viewport=-7845%2C-5052%2C0.74&scaling=min-zoom&starting-point-node-id=2493%3A18259&show-proto-sidebar=1&mode=design&t=DhF8dJvDse2TG530-1

Static Screenshots:

[knolleary]

One of the most challenging aspects here is how we apply this to FF Cloud, but not to the OS version and not to EE licensed self-hosted instances which will be free to allow their teams to have whatever resources they want (within the terms of the overall license). We have to remember that FF Cloud is nothing more than a self-hosted EE instance of the platform - it just happens to be the one that we run. We have no code that is FF Cloud-specific. We also need to consider both billing-enabled and billing-disabled workflows.

We currently have a single hardcoded TeamTier in the database. This is injected by the setup process of the platform. Admin's have no way to add/remove/edit that tier. The only thing they can do is provide some stripe product/price info via flowforge.yml to associate with that team.

In order to support multiple tiers, we need to allow the admin to create and configure them however they want. Hard coding them provides no flexibility and would have no way to distinguish FF Cloud from self-hosted EE instances.

So a high level set of tasks includes:

• API end points to provide CRUD operations on TeamTier objects
• Admin UI to manage the platform's TeamTiers.
• Each TeamTier will have a set of properties the admin can configure, including, but limited to:
  • name
  • description (markdown/html to be displayed in the plan selection views)
  • 'active' flag - whether the team should be offered as a choice. This will allow us to mark the existing default team as 'inactive' to prevent anyone picking it in the future, whilst allowing existing teams to stay on that tier (for now) until we do a more managed migration to one of the new tiers. Added some comments on the migration issue #2360
  • maximum instances, devices, users counts (or 'unlimited')
  • what features are available - feature flags the platform can use to control usage
  • If billing is enabled, we also need:
    • stripe price/product for the team, a 'display' price so we know what to display in the cost field
    • free allocation counts for instances (does that break down by InstanceType - s/m/l?) & devices
    • stripe price/product for instances (for each InstanceType s/m/l), and 'display' price
    • stripe price/product for devices
• The 'auto-create team on signup' option will need the admin to also specify what tier the auto-created team is

This is all before we get anywhere close to enabling the UX outlined earlier in this issue.

[knolleary]

On Upgrade path UX - depending on how we migrate existing users, one option is to let them 'upgrade' themselves from the old style starter to one of the new tiers (see my comments on #2360 for which I think this part of the approach we should take).

However it is possible they are already exceeding the limits of the new Starter tier - so the upgrade UX needs to cater for this and not allow someone to 'upgrade' to a tier that is smaller than their current usage.