#ronnysteelman_best-practices

1 messages · Page 1 of 1 (latest)

polar quarryBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1351984144896360630

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

night plume
lyric mulch
#

More details:
The solution has three subscription tiers (Standard, Professional, Enterprise). Each tier comes with a set number of seats (three types of seats/three user types), a metered number of Active Projects, one of three support packages (SLAs), and a few other things.

Outside of the three tiers, users can add on additional products (either at the time of initial purchase or by upgrading). This might be more of any of the three types of seats/user types, metered number of Active Projects, upgrade the support package, enable API, enable Snowflake sync connector, and any future addons we might add.

My question is around best practices: Do I create a product for each tier and then a product for each addon? Then, when I create a new subscription, the subscription automatically includes the tier, plus any add-ons they purchase?

Or do I create everything in a tier as a Product and apply those as individual products to the tier, plus any additional products they purchase as an addon?

I guess the second solution I mentioned would mean that the first bundle of Products that are included in the tier would have to have price-overrrides (or discounts) because the tier is a set price that includes a few different things, and then additional add-ons are upcharged at a higher rate than what the breakdown price is within the tier itself.

Or am I completely off on both approaches in terms of best practices?

night plume
#

Looking at the context, thank you for the added details

lyric mulch
#

I did read that link prior. I guess I was just wondering if it is best practices to mesh multiple of the models defined there together. Like I'd have the flat rate model, the per-seat model, and the Tiered model.

lyric mulch
night plume
#

Ha, makes sense

lyric mulch
#

If it helps, this is early beta but so we don't know all of the "features" that will hit within even the first year. But we have 5 potential customers lined up and a target of high double-digit thousands in the first year.

We want to make sure we aren't only following the best practices of stripe for management of products/pricing/subscriptions, but that it is flexible enough to continue adding features (either as a part of one of the base tiers or through addons, based on the feature) as we continue developing our way out of beta

night plume
#

So this all depends on how you'd want to track these on your end.

I still think creating a Product since these are tiers would make the most sense. Then, you create prices representing Standard, Professional, Enterprise.

As for the additional add-ons, you can create another product and then add prices for the various amounts. Then, when you create the subscription you pass that in: https://docs.stripe.com/api/subscriptions/create#create_subscription-add_invoice_items

If they choose add-ons later, you can update the subscription and pass that add-on: https://docs.stripe.com/api/subscriptions/update#update_subscription-add_invoice_items

Finally, I recommend that you review this document, https://docs.stripe.com/billing/subscriptions/upgrade-downgrade which talks about upgrading/ downgrading an existing subscription if your customer decide to change price after the initial sign up.

lyric mulch
#

So have three products (Stand, Prof, Enter) with monthly and yearly pricing...and use my actual platform code to key the functionality they have off of the type of product they bought, as a starting point?

Then have three products for Full, Lite, and Viewer Seats with monthly and yearly pricing...and then treat those as addons for either "at time of purchase" or later through upgrades, and have the platform manage the functionality based on the product type & quantity?

Repeat the second paragraph for any other products they can purchase more of as add-ons outside of what is included in the standard subscription?

Finally, for customers, it all goes on a single subscription as individual pricing IDs?

polar quarryBOT
lyric mulch
#

So at a minimum their subscription record associated to their customer record will have a Tier pricing...but could also have additional product pricings added to it to represent the add-ons?

bleak arrow
#

Hello 👋 , my colleague is stepping out but I can help. Catching up to your thread...

lyric mulch
bleak arrow
#

Yep, sounds like you summed that all up right. Exactly how we recommend breaking things up by product. I think the general rule of thumb is that products are different things one might pay for (a level of service being a thing here) and prices are different amounts/cadences for that thing.
And for the metered pieces of your subscriptions, are you clear on how you want to define that with our metered billing offering? That can be a bit complicated so I am definitely happy to speak to questions on that.

lyric mulch
#

Yes, metered actually does make sense to me from the documentation. Just making sure it was "best practice" if I mixed three models (flat rate (good/better/best), seat, and metered).

Because the only other way I could think of for the flat rate would be to roll all of the features into seat and just combine the test and metered models, but then I'd have to manage pricing overrides and discounts (standard includes 2 full seats, as an example, but the standard price is $100/month for all of that plus the 2 seats, whereas 2 additional full seats are $45 each...so stacking a lot of seat and metered pricing into the initial subscription woudl require discounts, which seems harder to manage)

bleak arrow
#

Ah gotcha, yeah definitely makes sense to keep those as separate products so you can just swap out the price when need be. Glad we could confirm your understanding!
And one more thing in case you haven't seen them but we have test clocks in test mode, which let you simulate the passage of time so that you can see how things would play out over months. You seem like you've read up on a lot of our docs but I always like to mention them because they are way nicer than setting short cycle times and having to wait a whole minute or more every time you test.
https://docs.stripe.com/billing/testing/test-clocks

lyric mulch
#

Very helpful. I wasn't aware of Stripe Clocks yet (a lot of new features have been added since I last did a Stripe integration). I was just going to simulate it with backdates, but this looks like it'll be much easier to simulate time-based activities

#

Thank you

bleak arrow
#

Happy I mentioned it then! It is a much nicer experience

lyric mulch
#

Yes, thank you!

#

I think that is all for my questions at this time. Going to screenshot everything out and I do appreciate you taking the time to walk me through this

bleak arrow
#

Sounds good, this thread will auto close but it is retained for a good amount of time. So you can also just save the URL

lyric mulch
#

Okay, thank you. Have a great rest of your day