Startups on Rails

I met my good friend Ryan Heneise over lunch Monday, during which we were discussing what sort of FUD we get from startups regarding Ruby on Rails. Rather than go through the volumes of past debates about why Rails is better or worse than XYZ, I’ve decided simply to document why I recommend Ruby and Rails to startups. YMMV.

Startups require happy developers

The platform your startup will use for the first version can either drive your developers crazy or make their life easy. Happy developers in the early days of a startup are essential to success. Select a platform they are comfortable with using and that will make them happy when they are working late to hit a critical feature or goal. Don’t select a platform just because you used it last time – rarely is that a valid reason. Ruby on Rails makes me and my team happy, so you’ll likely get better productivity from us because you let us use it.

Startups require quick ramp-up

As your startup grows, you may need to add new people to the development team. The conventions of Ruby on Rails provide for a rapid ramp-up time, even if your team threw lots of code together in a short period of time. RoR developers know where to look for the database code, where to look for the HTML templates, and where to look for third-party plugns. I once performed a complete architectural and code review on a RoR codebase in about two hours because of these conventions. It also told me what patterns and plugins were being used within minutes, not hours or days.

Startups require flexibility in the code

A dynamic language such as Ruby, PHP, or Python often provides better flexibility required by a startup than other languages that I’ve worked with (Java, C#). No matter what you choose, make sure you are selecting a language that offers the most flexibility to change over time, as you’ll change your application often during the first version of your startup. I like the Ruby language, so that is what I’ll often suggest.

Startups require us to listen first

As the development phase of your startup exits the honeymoon phase (the first 6-8 weeks of fresh development), priorities can change and new features may emerge. During that time, it is critical to focus on the core needs of the startup but this can require time from developers to assist in examining the priority list.

Ruby on Rails can often reduce time-to-market of features, which allows for time to stop and reassess priorities without jeopardizing the schedule. This accelerated development time doesn’t mean we can cram more features in with less time, though some people have made this claim. That approach often just causes more problems in the future. Instead, it allows us to listen to our customer, not just blindly plow through a list of coding tasks.

What startups often don’t need

Notice in this list that I didn’t focus on scalability, performance, or other factors. While I think these things are important to consider, I find that these topics are often not as critical for version one startups with a smaller customer base (and if they are, we’ll identify it during our discovery phase). Should you find that your startup takes off, then revenue or venture capital can be used to make adjustments to your approach or select a more appropriate platform for the next version.

My advice: select a dynamic language with a flexible platform or get left in the dust when your competitor does!

[tags]startup development, Ruby, Ruby on Rails, Startup on Rails[/tags]