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:


version: alpha
start-date: 2006-07-01
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.



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 C.
http://www.tesly.com/ – Collaborative test case management
http://www.agilewebdevelopment.com/ – Resources for the Rails community