Rails may be the wrong choice for your startup.

But it probably isn’t.

Most Startups/Projects/Things fail.

We are quick to say it, maybe even believe it. But really, they aren’t talking about MY project? right?

The truth hurts.

The reality is that the biggest risk to your startup is rarely your choice in tech. You’re most likely building, or worse, planning to build something that nobody wants nor will likely ever hear about.

But hopefully you already knew that.

To have avoided hearing the mantras of Eric Ries and Steve Blank by this point in 2013 would be an impressive feat. Simply put, feedback, customer feedback, is paramount. The sooner you get it, the better.

Which gets us back to Rails.

Once you have moved past a paper prototype, Rails is your shortest path from A to B. “B” being the thing you can show someone outside your office your idea and get meaningful feedback. There are a myriad of reasons for this but let’s go over the key ones.

Rails, well ruby, is surrounded by a huge tested ecosystem of solutions (checkout ruby toolbox) in the form of gems. From sending email to managing users, these save you time and let you focus on what’s important.

Rails adherence to Convention over Configuration means that any developer worth their salt will be able to quickly pickup an existing project. Far less true in frameworks which allow for a more free-formed approach in app development and directory structure. This helps if you’re adding engineers to your team or are switching between contractors/ dev shops.

Numerous great solutions exist for deploying Rails—quickly. Be it Heroku, dotCloud, or any of the PAAS-like solutions. Dev-ops should not be your concern in the begining.

You can think of Rails (Rack) as an elegant wrapper around HTTP. It handles lots details that you don’t want to think about in the beginning but will be happy to have solved.

The latest, shiniest, javascript racecar.

Although Rails has not been around as long as PHP or JAVA it has gone through a lot of maturing. Through and Years of building apps and people thinking about the problems with them has lead to cleaner solutions (4 major version releases) and documentation.

If you are building something for fun, then by all means use whatever you wish. However, if you are serious about a product, how is it prudent to shackle your risky fledgling company with increased technical risk. Stand on the shoulders of giants and don’t try to blaze a trail in both tech and your product’s domain.

But Twitter.

Detractors of Rails are quick to mention the well known case of Twitter and the failure of Rails/ruby under the weight of a growing userbase. Saying that Rails failed twitter begs the question if they would have reached a userbase large enough for the app to fail without Rails as the initial tech choice. We can never know. The reality is that Twitter survived and most startups die long before they see this problem.

Rails may not be the final solution for whatever you are building nor does it have to, to be an incredibly valuable tool in starting your company.