Hi everyone, OP here (Pete at ZeeMee). Thanks for all the discussion around this! The point of the article wasn't "How to get the most performance per $" - I w

Hi everyone, OP here (Pete at ZeeMee). Thanks for all the discussion around this! The point of the article wasn't "How to get the most performance per $" - I would never recommend Ruby, Rails, or Heroku for that. Rather, it was "If you're using Rails on Heroku, this is what it looks like to scale, and this is how far we could get it to go" For us, it's great! We can sit nearly idle (cheap), most of the year, and can crank it up to "expensive" a few days a year when needed. If you need more/bigger/better scale than that for most of the year, then this article is still helpful because you know which technology to not use. At ZeeMee we currently have about 2.5 people working on backend/rails stuff, and right now it makes more sense for us to work on features at this scale, rather than work on scaling itself. We were happy with how easy it was to crank up to this scale when we needed without really optimizing anything else. Of course we'll switch off of Rails+Heroku when the (cost to swtich) < (cost to continue). Keep in mind that the cost to switch includes engineering costs, and opportunity costs (other things we could be working on). Love the discussion, thanks!