This is a very informal, off-the-cuff survey of some web applications in the Rails ecosystem that have varying payment plans, how they present them, and some of the differences among them.  The idea is not to compare the services, but to start to get a handle on how to price services on the web.

Background

I’m working on launching a small, very niche Rails-based web application in the near future, and am looking to charge a small amount per-month for it.  Mostly as a way to make ends meet while I’m unemployed, but also because I’d like to provide a few extra features to those users who already donate to the free JBidwatcher application, and because the web application uses S3 and I have to defray those costs.  While I’m very grateful my users are contributing because JBidwatcher itself is useful to them, I’d like to offer a ‘premium’ value both for folks who have already donated, and for people who don’t feel comfortable just sending money, and want to see something extra for it.

This led me to be curious about pricing.  I pay for several web applications already, and expect that eventually I’ll have to pay for more if Google starts actually asking for money.   I decided to dig into the applications that are out there, and see what kind of pricing models I should be looking at.

From my informal survey, a lot of the subscription plan models used by Rails-oriented companies naturally grew out of 37signals and their fanatic devotion to the concept that web applications should be good enough to charge for, and should be charged for.

The products I’ve looked at for this are Lighthouse, Tender, GitHub, Highrise, Basecamp, Campfire, NewRelic RPM, CrazyEgg, Hoptoad, Thunder Thimble, and Pingdom.  I’m sure there are many others out there, but those are the ones I deal with on a semi-regular basis.  I have paid accounts with GitHub and Pingdom, and have used (at other companies) paid accounts on Hoptoad and NewRelic RPM.

One specific attribute of all of these applications is that they have varying levels of paid accounts, not just a free/paid[/lifetime] like many other services (LiveJournal, Flickr, LibraryThing, to pick a few that I personally use).  I like the spectrum approach as it gives users a choice as to how much services they’ll need, and what the amount they’re willing to pay for it is.

Raw Pricing Plans

First I want to present the ‘raw data’, a link to the plans and a brief table with the plan names and the monthly cost.  Then I’ll point out a few things I found interesting about the data.

So what’s interesting here?

Lighthouse, Tender, GitHub, Highrise, Basecamp and Campfire all differentiate on disk space used.

Lighthouse, Tender, GitHub, Highrise, Campfire, Hoptoad and Thunder Thimble all have some variation on the concept of ‘user’ that you can pay more for more of.

In everything except NewRelic and to a lesser extent Hoptoad, all the capabilities of each application are available to all user levels, just at varying quantities.  Feature distinction only exists in those two applications.  In Hoptoads case, the distinction is between free/non-free; if you’re paying, you get all the services.  This leaves NewRelic as the only one that deeply distinguishes between features available to different paid levels.

GitHub, Highrise, Campfire, and Hoptoad all have SSL support as an ‘add-on’ feature; it’s not part of the free accounts, and in some cases it’s not part of the basic level paid accounts either.

Discounts

When I signed up for Pingdom, they sent me a ’70% off the first year’ invitation, which reduced the price to roughly $3/mo. for all the basic plan amenities; presumably under the theory that they will be able to re-subscribe me in a year at full price.

NewRelic is running a 20% off discount currently, which lasts as long as you have a paid account.

Pricing Plan Layout

Historically I seem to recall most of these sites had the table style of comparison chart (still used by NewRelic, Hoptoad, Thunder Thimble, and CrazyEgg), but most have converted to the ‘box’ style of comparisons.  GitHub still has the table when you view the plan chart from your account settings, but other than that Lighthouse, Tender, GitHub, all the 37signals products, and Pingdom are using separate boxes for each plan level.

The 37signals products and Pingdom use an outsized box to emphasize one of the plans, presumably to drive signups to that plan.  CrazyEgg does the same thing within their table style, also.

I kept the order the various products displayed their prices, and it’s noteworthy that all the 37signals products, CrazyEgg and Lighthouse start with the larger plans on the left, and go down from there.

It’s also interesting that all the ones marked as ‘and a free plan’ de-emphasize the free plan by putting it in small text under the large table of paid options.  Two of them, Tender and Thunder Thimble offer a 30 day free trial, but no ongoing free plan.

GitHub and NewRelic are the only ones whose plan details go below the fold.  GitHub’s plan upgrade doesn’t, but their new sign-up plan list does.

Disk Usage

So for the applications which differentiate on disk usage, how much does $50/mo. get you?

This pattern is roughly the same for the $24 price point for all of them. 500MB for Lighthouse and Tender, 2.4GB for GitHub, and 3GB for the 37signals products. This suggests that limiting on disk usage ranges from 20MB-200MB per dollar per month, a pretty wide range. Estimating based on S3 costs suggests a per dollar per month storage amount of around 2.3GB, but that relies on one upload, one download, and ongoing storage. If your usage is asymmetric, or storage is temporary, the S3 based cost can vary a lot.

Users

For the applications which vary pricing based on users, how much does around $24/mo. get you (I chose this number since Hoptoad doesn’t have a $50 price point)?

I believe this is a wide range mainly because per-user data is usually relatively light, and so it has more to do with how complex the application’s interaction between users is, rather than a real per-user cost. Still, some numbers do come out of this. The cost/user ranges from $0.78 to $4. At the $50 price point, the cost/user for qualifying apps is $0.82 to $3.27.

Summary

I don’t pretend to know pricing, or sales, but I like to believe that in aggregate the people putting these sites together do.  I see a pretty good argument here for feature parity among price points, but finding quantities that can vary between prices.  There is a clear value to users and disk space used, so those are early things to look at when pricing an application.  SSL support is a common feature of paid plans, and not of free plans.

There’s a definite movement towards boxed plan details, over tabular feature comparisons.  Ongoing free plans still exist in the majority of applications, but are de-emphasized in most, guiding users towards the paid plans.  Overall, the plans are simple, only falling below the fold in two cases, and relatively easily consumable in all.

The lowest payment point plans are $5-40, with a bare majority falling in the $5-12 range, and all the rest but NewRelic falling in the $19-$25 range.

Closing

I hope this has been an interesting and potentially useful survey of a few pricing plans for applications generally in the Rails ecosystem.  Any mistakes are mine, and I’d very much like to hear about them so I can fix them.  Other data points are welcome, and points I might have missed that would be valuable to folks thinking about pricing are welcome, and even encouraged!

I did this for my own edification, but I’d also very much like to know if others find it interesting!

Best of luck, and may figuring out pricing not be as much of a pain for you as it is for me!

–  Morgan Schweers, CyberFOX!

[Edit: Since writing this article up back in early March, I've moved on from this job. The folks who are now maintaining it at least know where the pain points are, can run migrations safely, deploy it locally, and to dev servers, and to the main deployment area.  It's a working app, although I never got code coverage above about 45% at least the coverage was decent in the core app areas by the time I left.]

Mike Gunderloy had an interesting article entitled ‘Batting Clean-up‘, which was very timely for me.  I’ve just started maintaining and trying to improve a Rails app developed by an ‘outsourced’ group. The only tests were the ones generated automatically by ‘restful authentication’, and they were never maintained, so they didn’t come close to passing. Swaths of the program are written in terribly complex (and sometimes computed) SQL, migrations didn’t bring up a fresh database (poor use of acts_as_enumerated causes great hurt), and vendor/plugins should have just had one named ‘kitchen_sink’.

It hurts to see Rails abused like that; you want to take the poor application under your arm and say, ‘It’ll be okay…we’ll add some tests and get you right as rain in no time!’, but you know you’d be lying…

I did much of what Mike described (half the gems it used were config.gem’ed, the other half weren’t), vendor’ed rails (it breaks on newer than 2.1.0), and brought the development database kicking and screaming into life. There was no schema.rb, it had been .gitignore’d, and the migrations added data, used models, and everything else you can imagine doing wrong. (Including using a field on a model after adding that column in the previous line…I don’t know what version of Rails that ever worked on…) I didn’t want a production database; who knows what’s been done to that by hand. I want to know what the database is _supposed_ to look like; I can figure out the difference with production later.

Once the clean (only data inserted by migrations) dev database was up, I brought the site up to see if it worked. Surprisingly enough, it did; apparently they used manual QA as their only testing methodology. I appreciate their QA a lot; it means it’s a working application, even if it’s not going to help me refactor it.

I ran flog and flay and looked at the pain points they found to get an idea how bad things might be. I picked an innocuous join table (with some extra data and functionality) to build the first set of tests for, which gave me insight into both sides of the join without having to REALLY dig into the ball of fur on either side. I viciously stripped all the ‘test_truth’ tests. I looked for large files that flog and flay hadn’t picked up to pore over. Check out custom rake tasks, because those often are clear stories and easy to quickly understand in a small context.

Checking out the deployment process tells you a lot also, although it turns out this was stock engine yard capistrano.

Skimming views (sort by size!) will tell you a lot also, especially when you find SQL queries being run in them…

Use the site for a little while, and watch the log in another window. Just let it skim by; if you’ve looked at log files much, things that seem wrong will jump out even if it’s going faster than you can really read.

In my case, the code’s mine now, so it’s my responsibility to make it better before anybody else has to touch it. I’ve got about a week of ‘free fix-it-up time’ before I need to start actually implementing new features and (thankfully) stripping out old ones… At my previous company, I was the guy pushing folks to test, now I’ve inherited a codebase with zero tests. Poetic justice, I suppose…

Good luck!

— Morgan Schweers, CyberFOX!

As with everything else, it’s not that simple…

In the successful startups I’ve worked at, a core of people staying late, working long hours, was a symptom of having an idea that people can believe in.

I have not seen any very successful startups where the developers weren’t at least a little monomaniacal about their work.

On the contrary, I’ve been at two successful startups (defined here as wildly successful IPO’s) where having those fanatic developers was a core reason of why they were successful.

The people who were putting in overwhelming hours at those companies weren’t doing it because they’re workaholics. They were doing it because they were true believers. Both in the company itself and the product they were building.

It’s not about the workaholics making the company successful, it’s about the company being one that the employees can believe in, to the point of _wanting_ to be there, wanting to be making it better.

In those cases, you don’t fire the people who are passionate about building your company. You support them, and accept that they’re going to crash occasionally, and try to nerf the crash some…

In my experience, it’s the fervent employees who are the core of successful startups. This was true at McAfee Associates (went public in 1992), and PayPal (went public in 2002), both successful startups that I was part of.

You also need people who aren’t as fervent, who can see a wider view, so it’s always a balance. So you can’t really ‘fire’ either of them, out of hand.

I’ve been that true believer, focusing everything into a job or project that I deeply care about. I’m a much calmer, more balanced person now, though. We’ll see what happens in 2012…

– Morgan

I’ll pass along a piece of advice for anyone looking to start a company, from someone (me) who’s been through several startups.  (McAfee Associates and PayPal being two very notable, very successful, and very different, ones, in different decades.)  The advice is useless ever since 1994 because the ‘free money’ vibe of the VCs has infused the business world and made it hard to follow, but it’s free advice anyway, and worth whatcha pay for it. 

If you’re going to start a company, be profitable FIRST, before you ever talk to VCs.  If you don’t NEED their money, but you’re on one of the beautiful adoption curves, they’ll fight each other to be the one who gets the right to give you money.  Sure, you don’t need it, but if spent right, it can (1) pay for the dog’n'pony ‘going public’ show, and (2) move you one or two rungs up the doubling curve.

The funny thing to me is that people take the money out of the get-go, to move them up 1-2 rungs when the power curve is low, boosting them from 1000 users to 4000 users.  What they should (in my oh-so-not-humble opinion) do is grow slower for a little while, then take the money when jumping the power curve would mean the difference between 250,000 users and 1 million users AND you’re not dependent on the VCs for your existence.

This means growing slower at the start, only growing as fast as you can afford to, keeping yourself as close to cash-neutral as you can, and always being one cost-cutting exercise from being profitable.  It’s not the preferred method for a class of folk who were raised and bred on tales of overnight millionaires, and ‘get big fast’ (which only works for a very SMALL subset of companies) but it’s the way to build a sustainable, exit-strategy-free business.  (Exit-strategy-free meaning you don’t NEED one, not that you don’t HAVE one.)

I saw it done at McAfee Associates, and we completely dominated the conversation with the VCs.  It wasn’t a request for money, it was a bidding war on the part of some top-notch firms, and that was in 1992, before the first bubble even started to be blown.  We were chugging in about $10Mil/year as I recall, and spending less than a quarter of that.  I don’t believe that company was EVER unprofitable, from the quarter it was founded.

McAfee Associates took the company from “the three Fs” (family, friends, and fools) to profitable without really going through the intervening step of angels or venture capitals.  (Now, for what it’s worth, some of those 3Fs were…understandably upset that they didn’t see any return when the company made it big, but that’s just part of the darker side of the history of McAfee Associates, and not directly relevant to the point I’m making.)

Now McAfee Associate’s distribution model was nearly free (distributed by BBS), advertising was ‘make a good product and get people to talk about it and show its use off’, the product was…well, you could joke that it was viral.   People used it, found it was useful and necessary, and handed it to other people who probably needed it.  The product was free and fully functional, but every run it put up a message, basically that ‘if you’re using this in a company, educational institution, or government organization, you must purchase a license’.  End users paid the registration fee sometimes, which was a nice base source of income, but companies leapt to license.  Mostly because their employees were using the software, needed the software, and were handing it around inside the company.  Someone would point out the license issue, and the company would call us to pony up.  We never had to call anyone to sell the software, it sold itself, and our users sold it for us.  Most people wouldn’t imagine it, but companies really are decently minded when it comes to dealing with other companies.  Or at least so afraid of lawsuits that they’re willing to be decent citizens.  Sometimes a big company would use their size to pressure us to give them a discount, which we were happy to do, because it was nearly free money anyway.  Our overhead was fixed, we didn’t advertise, we told them to download themselves a copy each quarter, or if they paid enough we’d send them a floppy once a quarter.
What’s changed in the world since then?  Well, a lot, but I’ll put forward that mainly the scale has changed.  Free distribution through BBSes reached a large percentage of the computer using population back then.  Distribution through the Internet reaches a HUGE percentage of the computer-using population now.  If you make a good product, people can talk much more widely about it with blogs.  Companies are still looking to be good citizens, primarily, and there are a LOT more of them out there.  Oh, and you probably don’t have to mail them a floppy each quarter, no matter how much they pay.
So the one of the biggest things I’d suggest to ‘start profitable’ is to target your product at corporations, but make it attractive to end-users as well, so they’ll bring it into the company.  As Willie Sutton didn’t say but is said to have said, when asked about why he robbed banks, “That’s where the money is.”

–  Morgan Schweers, CyberFOX!