[sawirricardo]

you're looking at Authorization (Not Authentication, which handles how to get the logged in user).

In Laravel, it's known as Policy. So, based on the subscribed tier, you define the borders, which area of your saas are limited to "pro", "basic", etc.

Since Laravel is an MVC, usually, you'll check this permissions in the controller. Check if user's posts is more than his plan's limit (say, 5). if he already has 5 posts, deny that request and put a nice error with message "You've reached your limit. Please upgrade your plan".

or other alternative flash the session, and redirect the users to the billing page, with a message to upgrade his plan.

What do you think?

[akajla]

I've seen it implemented in exactly this fashion. You can even hook up Stripe (or any other checkout system) in such a way that a successful payment triggers the "feature upgrade" on the back-end and subsequent interactions with your app have the "pro/paid" features unlocked.

I also think that at its core, implementing tiers is an authorization problem, somewhat a hybrid of access control and feature flags. As mentioned above, frameworks like Laravel and Rails have built-in functionality that makes it easier to implement. Once you get to scale, I think the challenge becomes managing and changing the tiers themselves as new features are introduced and managing which customers have access to what (especially with custom pricing/contracts per customer).

Disclaimer: I'm a founder at Warrant, a company offering authz as a service. Given how close this is to authz, we've written specifically about pricing tiers: https://docs.warrant.dev/guides/tiered-saas