> Mostly, performance is an issue with large apps and their rspec run times I hear you! I hate long test suit runtimes, and they are easily grown. I made a gem

> Mostly, performance is an issue with large apps and their rspec run times I hear you! I hate long test suit runtimes, and they are easily grown. I made a gem to address this, by running your test suite across a cluster of cloud VM's and reduce test times from 30 minutes to 30 seconds. http://github.com/meesterdude/cloudspeq http://github.com/meesterdude/cloudspeq > but that's where the "convention over explicit configuration" stuff becomes a hindrance rather than a help I feel It just gets you going - you have a foundation you can run with - and one that other devs will know "out of the box", which means onboard is easier/faster. But it's never meant it's not configurable. You'll still need to cache, to adjust web servers and background jobs and all of course. But rails makes it possible, easy (and fun!) for one person to do all that. > Our big old Rails monolith (started on Rails 2, currently on 4.2, and hopefully on 5.x in a few months) has carried us to about $500mil projected revenue this year. Dayum! Well done! Do you know how many requests a second you serve and the avg. response time? > Could other stacks have done the job better? I think so long as you haven't been severely bitten by scaling or performance issues; the product itself is what matters so long as the technology can deliver on it. Clearly you're doing pretty well regardless! Proof is in the pudding.