How to choose a Rails contractor

Recently we picked up a client that had a site developed by another Rails firm, and the project was not going well for them. The project was way behind schedule, and the site had lots of mysterious, unexplained errors. The previous developers had a fairly consistent answer to some of the basic tenets of Agile development, like testing: “We wait until the end to do all that stuff.” Documentation was an “extra” that needed ordering up-front. The entire development process was opaque to the client, leading to many sleepless nights filled with anxiety.

The tendency is to blame the original development firm. After all, they’re the ones jerking the client around, right?

Not entirely.

As a consumer of development services, its entirely incumbent on a client to do their homework and make sure that the person or firm they’re hiring is fully capable of delivering on what they promise. If you hire a firm filled with developers who are new to the Rails scene or who don’t take the time to stay current on their art, then you shouldn’t be terribly surprised when their work turns out to be sub-par. However, our client, like most people in their position, were not fully educated on what to look out for. There’s a a few good ways to tell whether you can trust the person or firm you’re hiring to deliver the product you want in the timeframe you’re asking for.


This is (or should be) somewhat obvious. Ask to see the developer’s portfolio, or to talk to some previous (hopefully satisfied) clients. The easiest way to know whether a shop is capable of delivering your website is to know whether they’ve done it before.


This is a core principle of Agile development. If the firm claims to have an agile methodology, whether they use Scrum or Agile or XP, then a test-first philosophy should be at their core. Ask them lots of questions on this one. What do they test with–Rspec? Cucumber? Test::Unit? Shoulda? A mish-mash of these, or some new framework? Great! Get specific. How large is the test suite on their last customer’s site? Dig deep. For example, if they’re using cucumber, ask how many steps the full suite runs. (For any but the most trivial site, this should be in the hundreds–for more complex sites, thousands.)


Speaking of testing, how do we verify what a potential contractor tells us? One phenomenally great way of doing so is to see what kinds of open-source contributions they might have made, either as a firm or as an individual. This gives you the opportunity to see not only whether and how they test, but also what their code looks like. OSS authors also tend to stay current on the state of the industry and best-practices, both out of pride and necessity.

Bedside Manner

If you can't explain it simply, you don't understand it well enough.

**Albert Einstein**

How do they treat you? Does everything sound terrifically complicated and difficult to understand? If so, I’ve got bad news for you: either your contractor doesn’t fully understand what he’s doing, or he doesn’t want you to. Call it “Job Security.” This isn’t to say there aren’t things in web development that are complicated. There absolutely are, and you as a client have to understand that just because its a box on a web page that it doesn’t mean there aren’t some crazy magics going on back at the server to get it there. But if every single request is met with a long, convoluted explanation that makes your ears bleed by the time he’s done, then you need to find someone who is better able to communicate what he does for you.


This can be somewhat subjective, but one thing I think our clients appreciate when we work with them is that we get invested in a project, and as a result we’re not shy about offering advice about proposed features and changes. Clients always have the final say, of course, but when we see them going down a road we know from experience is fraught with peril, we’re not afraid to speak up.

This list is by no means exhaustive. Let us know your own experiences with selecting a contractor in the comments section!


  1. June 14, 2010 at 9:41 AM

    One the greatest determining factors I have found when people hire me is trust. Most of my clients have very little knowledge about how the web works, so they want someone they just trust. And I think the questions you are helping to answer are, as a client how to find a developer you can trust and as a developer how to establish that trust.

  2. June 14, 2010 at 17:35 PM

    Torey Heinz: Yes. Trust and honesty are the best things you can have. I have a no B.S. policy.

  3. June 16, 2010 at 12:07 PM

    I agree, clients generally f this stuff up.

    Most of clients don’t seem to do the following:

    1. The people who are doing the work at actually experienced in the tools required to do the work
    2. They develop a close relationship with the people who will actually end up doing the work
    3. That the workers actually understand the needs and priorities of the client such that they can make most decisions in the client’s interest.

    As a result, you end up having god knows who work on your project and often time spend a fair amount of time figuring out how to implement something intead of figuring out the best way to implement something.
    It’s astounding, really.

  4. June 16, 2010 at 17:42 PM

    torey: great point–gaining the client’s trust is a critical part of the development effort for us.  Part of the way we do that is by doing our best to give them good advice when it comes to deciding what features to spend time on and what’s less valuable.  I think its also important that we don’t treat our clients as though they’re completely tech-naive.  Maybe they don’t understand the finest details about what we do, but we usually try to explain things with the presumption that they’re tech-savvy and don’t dumb it down unless they ask us to.

    Scott: Also agree.  One of the biggest mistakes I see clients make is that they just want to turn over their idea to a developer and come back in 6-12 weeks and have their idea completely refined as they see it in their head (because we know how often that happens!), which is why I think the Agile methods are critical to success.  That continuous feedback loop is so important.

  5. June 18, 2010 at 9:21 AM

    I’d just like to add that I don’t think these points only apply to Rails contractors.