Rails - Jul 2006 - Handling a tiered subscription service

Hi all,

I''m working on a project that involves a tiered pricing structure for  
various features, all of which are accessed via a secure admin area.   
The features available in each tier, the tier structure and pricing  
will change over time, so new tier schemes will come into play,  
requiring feature/pricing schemes to be timestamped.

I guess what I''m aiming for is something similar to BaseCamp, but  
with a more varied feature set available between price plans, rather  
than just quotas on the ''amount'' of stuff you can do.

I''m just working up some initial ideas for how to handle this, and it  
seems like a good way would be to have a yaml file for each pricing  
scheme, with the tier information within that.  I reckon I can get  
away with making each feature equivalent to a controller and action  
(or set of actions), so for each controller I could list the actions  
and the subscription level they require. Controllers/actions not  
listed would require a default subscription level.

A constant in environment.rb would point to the tier version  
currently in use for new signups.  Already-subscribed users continue  
to use the pricing scheme that they signed up to.

I also want to display ALL available features in the admin navigation  
(with unavailable ones indicated), but redirect insufficiently- 
subscribed users to an upgrade page.  I thought this could be done  
using a helper file and a link_to_tiered_feature type method.

This is the kind of thing I''m thinking of for the yaml:

# tiers/tier.alpha.yml
#
details:
     version: alpha
     start-date: 2006-07-01
     end-date:
     default-tier: 0

tier0:				# ''free''
     monthly-cost: 0
     max-users: 10

tier1:				# ''bronze''
     monthly-cost: 10
     max-users: 20

configure:			# the configure controller
     data-export: 1		# data-export action of configure controller  
requires tier1 subscription
     alerts: 1			# alerts action of configure controller requires  
tier1 subscription


So... Has anyone else done something like this, and are willing to  
share some tips?  Can anyone see any glaring flaws in my plan as it  
stands?  I''m very much at a planning stage, so any ideas are welcome.

I''m not sure why I want to store stuff in yaml rather than in the  
database... it just feels... nice.

Thanks!


     Andy

I had a similar (if not the same) objective with Tesly (http:// 
www.tesly.com/).  I created a Plan model that has project_max, cost  
and booleans like allow_attachments, etc.   This makes it rather easy  
to associate a User with a Plan through a Subscription, and any Plan  
can be deactivated or changed at any time via the CRUD that we all  
know and love.  This approach has worked well for me, and I''d  
recommend it.

--
Benjamin Curtis
http://www.bencurtis.com/
http://www.tesly.com/ -- Collaborative test case management
http://www.agilewebdevelopment.com/ -- Resources for the Rails community



On Jul 21, 2006, at 7:29 AM, Andy Triggs wrote:
> Hi all,
>
> I''m working on a project that involves a tiered pricing structure
> for various features, all of which are accessed via a secure admin  
> area.  The features available in each tier, the tier structure and  
> pricing will change over time, so new tier schemes will come into  
> play, requiring feature/pricing schemes to be timestamped.
>
> I guess what I''m aiming for is something similar to BaseCamp, but
> with a more varied feature set available between price plans,  
> rather than just quotas on the ''amount'' of stuff you can
do.
>
> I''m just working up some initial ideas for how to handle this, and
> it seems like a good way would be to have a yaml file for each  
> pricing scheme, with the tier information within that.  I reckon I  
> can get away with making each feature equivalent to a controller  
> and action (or set of actions), so for each controller I could list  
> the actions and the subscription level they require. Controllers/ 
> actions not listed would require a default subscription level.
>
> A constant in environment.rb would point to the tier version  
> currently in use for new signups.  Already-subscribed users  
> continue to use the pricing scheme that they signed up to.
>
> I also want to display ALL available features in the admin  
> navigation (with unavailable ones indicated), but redirect  
> insufficiently-subscribed users to an upgrade page.  I thought this  
> could be done using a helper file and a link_to_tiered_feature type  
> method.
>
> This is the kind of thing I''m thinking of for the yaml:
>
> # tiers/tier.alpha.yml
> #
> details:
>     version: alpha
>     start-date: 2006-07-01
>     end-date:
>     default-tier: 0
>
> tier0:				# ''free''
>     monthly-cost: 0
>     max-users: 10
>
> tier1:				# ''bronze''
>     monthly-cost: 10
>     max-users: 20
>
> configure:			# the configure controller
>     data-export: 1		# data-export action of configure controller  
> requires tier1 subscription
>     alerts: 1			# alerts action of configure controller requires  
> tier1 subscription
>
>
> So... Has anyone else done something like this, and are willing to  
> share some tips?  Can anyone see any glaring flaws in my plan as it  
> stands?  I''m very much at a planning stage, so any ideas are
welcome.
>
> I''m not sure why I want to store stuff in yaml rather than in the
> database... it just feels... nice.
>
> Thanks!
>
>
>     Andy
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060722/b6ca50a9/attachment-0001.html