Reasons Why Your Startup Should Use Ruby On Rails (RoR)

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Reasons Why Your Startup Should Use Ruby On Rails (RoR)


Warning:  If you came to this article expecting a glowing endorsement of Ruby On Rails (RoR), you’ve been misled.  I thought about titling this article “Why Your Startup Shouldn’t Use Ruby On Rails” but figured that that would attract all the RoR fanatics out there who would then take time out of their busy days and come flame me.  I didn’t want that.  I took a risk and intentionally wrote the article as a spoof.  If you are put off by this, feel free to stop reading now.  I won’t be offended.
This article assumes that you are a software startup founder and considering RoR as your core product platform.  Please note that these view-points are not a critical analysis of the Ruby language or the technical merits of the underlying framework,.   The article is intended to be a bit humorous so please don’t take it too seriously.
Reasons Why Your Startup Should Use Ruby On Rails
  1. Less Is More:  You’ve totally bought into the mantra that less complexity is by definition better.  Your product is relatively simple and fits nicely into the RoR framework including its data persistence layer.  You’re trying to intentionally avoid solving hard customer problems that might involve complicated database models  In fact, you may have even come up with your startup product idea based on one of the RoR tutorials or samples.  You’re convinced that the world does not yet have enough web-based, AJAX-driven, database-oriented CRUD applications for managing bugs, wine lists, CD/DVD collections or whatever.  In this case, your product was made for RoR.
  1. It’s Cooler:  Lets face it, Ruby is just cooler.  Java, C#, PHP are soooo last year.  Who wants to work on old technology that’s already been out there for more than 5 years?  Besides, you’d miss out on all the priceless learning that comes from experimenting with a shiny new framework.
  1. Cheaper Programmers:  Since RoR is so cool (see above), people will be willing to work for your startup for less money just so they can get a chance to work with RoR.  In fact, you might even be able to attract star developers from big companies that are looking to do some resume building, um, I mean learning in your startup.  
  1. Programmer Productivity is Top Priority:  Clearly, being able to get a product to market faster is the top priority.  In fact, if you can get your productivity high enough, you can afford to be going after the totally wrong or non-existent market opportunity.  If your product doesn’t sell, it only took you a couple of months to build it anyways, you can just start over and get it right the next time. 
  1. Impress Venture Capitalists:  By this point, all VCs have read about the huge Ruby On Rails movement in their in-flight magazine on the way back from their vacation in Hawaii.  Clearly they are going to lean towards startup founders that are looking to push the envelope on new technology and leverage the synergies that come with the seamlessly integrated and psychotically intuitive and elegant coding style that is inherent in Ruby On Rails.  This aligns nicely with their focus on funding startups that are curve-jumping, paradigm shifting and market exploiting.  All things being equal, you’re more likely to raise funding if you’re on RoR than if you’re using one of those other web platform/frameworks.
  1. Guarantees Good Design:  Given that the whole MVC pattern is “baked in” to RoR, it keeps sub-par programmers from shooting themselves in the foot.  Sure, you can do MVC with Java and C# but those languages give you way too many choices and you don’t want to have to trust your development team.  By staying within the nice, cozy confines of RoR which makes all the standard default choices for you, you can even tap into this whole global development pool thing you’re heard about because RoR will make even that developer with 6 months of Javascript experience all of a sudden a valuable member of your top-notch development team.  In fact, because of the productivity of RoR (see #4), you get the benefit of accelerated experience.  The entry-level programmer with just 3 months of RoR experience is almost the equivalent of a programmer with 3 years of experience in one of those other frameworks.
  1. You Understand Risk / Reward:  You didn’t have to go to business school to know that wherever there is great risk, there is always great reward.  And, what could be riskier than building a business on a relatively new technology platform?  Of course, if things go downhill, the project is open source so you could always fix it yourself and dig yourself out of whatever hole you might find yourself in.  Given that all startups involve risk, you’d much rather take risk on things you can control (like your technology platform) than taking on “market risk” and things that you can’t control.  
  1. You Do Not Compete With 37signals:  The fact that RoR just happens to be led by the absolutely brilliant David Heinemeier Hansson who just happens to work for 37signals is not relevant.  Lots of open source project leaders work for software companies as their day jobs.  Besides, you don’t compete with 37signals anyways because they are in the “lightweight project management” space and you’re thinking about something “completely different” which is unlikely to ever really compete with 37signals anyways.  And, even if you did wind up competitors some day, so what?  The RoR community is large and growing and there’s no way that 37signals would be able to unduly influence the product roadmap.  You are on equal footing – that’s the power of open source!
Clearly, startups would be well served to look at Ruby On Rails as a key differentiator for their startup product.  In fact, this decision should be made quickly because as more and more people adopt RoR, there’s less and less opportunity for differentiation.  In fact, if this whole thing goes too far, it will cease to be “cool” and all that investment in training your development team will be for naught and you’ll have to start again with whatever the shiny new framework is next year.
Summary of My Point (seriously):  Choosing a technology platform is a key decision for all startups and the choice should be made both strategic and technology reasons.  When tempted to adopt the newest “silver bullet” technology that promises immense gains in programmer productivity (which RoR does), understand what the tradeoffs are.  To get even keener insight, study a little bit of history and find out what has come before.  It’s possible that in your situation RoR is indeed the best choice, but likely not for the reasons above.  If you find yourself agreeing with one of the eight reasons above, we really need to talk.
What do you think?  All joking aside, is there enough advantage to RoR from a startup’s perspective to outweigh the risks?  What situations would RoR make a good choice?

Posted by Dharmesh Shah on Mon, May 29, 2006


thanks for sharing, got this from HumDigg.

Paul Graham's quote on RoR: "During the Bubble, a lot of people predicted that startups would outsource their development to India. I think a better model for the future is David Heinemeier Hansson, who outsourced his development to a more powerful language instead. A lot of well-known applications are now, like Basecamp, written by just one programmer. And one guy is more than 10x cheaper than ten, because (a) he won’t waste any time in meetings, and (b) since he’s probably a founder, he can pay himself nothing."

posted on Monday, May 29, 2006 at 10:57 AM by Shaji

1. "Sure, you can do MVC with Java and C# but those languages give you way too many choices and you don’t want to have to trust your development team. "

The last bit of the sentence is not meant literally (I understand that) but is still problematic in my world. No blind trust, but trusting their professional instincts once they have been verified and tested upfront is the only way I could have time to focus on the business goals.

2. RoR is said to be much slower than Java 5 and CLR 2. I do not believe they have JIT or hotspot optimization as of yet.

posted on Monday, May 29, 2006 at 12:32 PM by

Pick whatever technology is the most comfortable for your core development team. If they're comfortable with RoR, then so be it.

But don't let them cut their teeth on your deadline. An expererienced team in most any environment is productive. They're productive in not chasing down black holes or learning new or unproven technology. They're productive in that they know how to make A + B = C. The rest is basically labor, not the hard part of the unknown or creative areas of system development.

With web applications, it is almost never the fault of the tool choice that a product fails. It is typically something far far beyond the scope of the development tool. Successful sites are running everything from C, Perl, Lisp, RoR, Java, ASP, PHP, etc. on Oracle, MySQL, Postgers, SQL Server, Sybase, etc. They all work.

Also, you can always change out the back end later.

Simple example is eBay. Started off on Windows using a C++ DLL and are now today running Java on Sun hardware. Yet the site still works, the URLs still work, etc.

The language used is but one component to a very complex process, and typically it is not the most important one.

Just make sure that your team has someone who is fluent in the technology you're using, whatever it may be. You don't want to fund a research project. You want your site to just work.

posted on Monday, May 29, 2006 at 1:24 PM by Will

It's clearly evident that you are ingorant of the subject matter. Perhaps you should actually learn Ruby and use Rails before spouting off. Each has strengths and weaknesses .... but one has to understand them first before one can adequately crtiicize them. Here's an example of just one of the very simple errors you've made.
Ruby, the language, had an intial interpreter working in 1993 and public release in 1995. It may seem new to many but agewise it's roughly a sibling to Java and PHP, and older than C#. A language which easily shows Ruby's limitiations is Lisp, which is older than any of the ones on this page. Shiny and new != better. But hey, don't let facts get in the way of your rant.

posted on Monday, May 29, 2006 at 3:57 PM by Hitesh

I think that "less is more." But, I don't think it applies to the overall functionality of a program, more to the complexity with which the program can be used to complete the task of the user. If the user could be provided with a big button that said "Work" and it did exactly what they wanted, then that would be an incredibly successful product, and clearly much more complex below the surface than a single button implies. So, it is not the complexity of the product we are minimalizing, it is the complexity of using it.

Also, having done some very trivial stuff in Ruby, it is cooler. It is much cooler than C# (my day job language). It's up there with Python, Lisp and Perl in terms of coolness. Is RoR cooler, I am not sure, but I am willing to give anything a try that is written in a more productive language, and isn't ASP.NET.

posted on Monday, May 29, 2006 at 7:47 PM by Joshua Volz

I'm sure RoR is as great to use as most people say but its still just a language and framework.... just like all the other options. Another 3G language. There are no truly fundamental differences. I'm a little worried when someone thinks that it will solve all of their previous problems. It reminds me a bit of when VB came out and it was easy to write a simple windows app... and everyone thought they were a windows developer for about a year or two.

Some linguistics research searchs for an optimal human language, which is cool, but the stuff more important than syntax and semantics is the creativity and expression in literature that an individual creates.

posted on Monday, May 29, 2006 at 8:57 PM by Ryan Dewsbury

"Some linguistics research searchs for an optimal human language, which is cool, but the stuff more important than syntax and semantics is the creativity and expression in literature that an individual creates."

Wow. Nice one. Register (if you haven't) and join the discussion. It's very quiet, with the forum being less than a month old.

posted on Monday, May 29, 2006 at 9:39 PM by

Thanks to everyone for their comments.

For those that want to continue the conversation, I encourage you to do so in the discussion forums as Marc suggested.

posted on Monday, May 29, 2006 at 9:44 PM by

You say:

"When tempted to adopt the newest “silver bullet” technology that promises immense gains in programmer productivity (which RoR does), understand what the tradeoffs are."

It's not clear to me from your article what you think these tradeoffs are. Could you elaborate?

posted on Tuesday, May 30, 2006 at 5:29 AM by Topper

Thanks for saying a lot of nothing. I'd appreciate more if you can help the Rails zealot (+me) by showing what the trade-offs are.

posted on Tuesday, May 30, 2006 at 9:40 AM by ctran

I'd like an example of a "complicated database model" that rails can't handle. I bet you can't come up with one. It might require you to actually think a little bit to do something that goes beyond the normal Rails conventions believe it or not but most experienced programmers can handle that. If you don't want to be flamed, don't write ignorant and uninformed posts

posted on Tuesday, May 30, 2006 at 10:55 AM by Dallas


I think you missed my point about the humor and the article not being an analysis of the technical merits of RoR.

Having said that, I do like to a little bit of thinking every now and then (amd am working through getting a deeper understanding of RoR as we speak).

The good news is that I'm more representative of the mainstream developer and not as smart as folks such as yourself, so I'll be a better gauge.

Will post back here based on what I learn (or don't learn).

Also, for those that were disappointed with the lack of substantitve material in the article, my apolgoies. In my defense, it was the long weekend and I did make it clear that the article was not a "thought piece" but a humor piece.

posted on Tuesday, May 30, 2006 at 11:07 AM by

Very humorous. I guess I'm not sure whats considered mainstream. Java? PHP? C#? Does mainstream mean that you don't use a framework, or that you don't use Ruby/Python/Lisp? Seems like your more apt at poking fun at 37signals and some overdone "Web2.0" philosophies. When making a web app its kind of essential to use a framework to stay competitive. At least I would argue so. So you can write your own framework or use one already written for you by a bunch of very smart people. The beauty being that its open source and you can look at and modify how it was implemented. If you use alot of stored procedures for crud then go tweak the database layer if you have to. I think this applies to any good open source framework.

posted on Tuesday, May 30, 2006 at 11:34 AM by Dallas

Evey language seems to be "cool" at one point or another. Even VBscript.

posted on Tuesday, May 30, 2006 at 2:24 PM by John Revel

I don't agree with the RoR principle that everything should be simple and achievable by amatures. If you want a professional site, you need to use professionals. Like the current movement to replace graphic designers with easy to use software & templates, what does it achieve? Poor quality generic looking web sites. It also hampers diversity and limits innovation.
If you buy frozen ready meals all the time, don't expect to impress people with your cooking, enjoy the food you eat, or ever understand how to cook anything better based on your knowledge of cooking ready meals.

posted on Sunday, June 04, 2006 at 11:07 AM by simon

Get with it. RoR is SOOOO last year. Use Django (for about another 3 months anyway...). ;-)

posted on Friday, June 09, 2006 at 7:42 PM by

Flavor of the year languages are the path to failure. Two years ago your code was PHP, last year it was Python, this year it's Ruby, next year it's what? Focus on applications, not religion.

posted on Wednesday, June 14, 2006 at 4:07 PM by Randy Charles Morin

A little behind the discussion here but whatever.

Rails is nice. I use it all the time. That said, you are right about the database model more or less; once you get beyond CRUD you are in deep space. That doesn't mean you can't do it, or that it's more work than some other language. It just means you have to do the whole thing yourself. No helps except the bare language.

Also what gets me is people who say, look, here is [application], it's in [some other language], but Rails is awesome, so I'll completely rewrite [application] in Rails! Why? Half of the philosophy of Rails is to avoid duplicating work, not "everything goes better with Rails". It doesn't, because Rails won't magically recreate someone else's years of effort.

And then they advertise on their site that it's written in Rails. How can this possibly be a selling point? There is no consumer in the world who cares what language their website is written in; not even programmers. Programmers are interested as programmers, but programmer interest doesn't generate revenue. When in consumer mode, programmers are no different than anyone else.

posted on Monday, June 26, 2006 at 3:25 PM by evan

I want to make a ROR site just so I can put the shiny logo on it!!!

posted on Wednesday, May 09, 2007 at 4:09 PM by iain

good article from 2006! that is true - Ruby On Rails rules in every aspect.

posted on Tuesday, January 20, 2009 at 11:19 AM by agile ror developers

You do not forgot something important like... performance? Oh wait, now we have big bad ass computers, rigth? 
Bad, bad article... bad developers can make mistakes on any language, trading performance for "easy of use" is simply a really bad idea. But now whe have gigs of RAM, right? why make a small and fast program on a "old" language like C?

posted on Thursday, August 27, 2009 at 8:50 PM by The DarkMaster

Comments have been closed for this article.