The Rise and Fall of the Rails Contract Labor Market

Posted by Dan Grigsby
on Monday, June 18

The Rails contract labor market has gone through four phases thus far:

Phase One – Boutique Shops

During the first phase, boutique web-development shops used Rails to win “competitive bid” contracts over other firms by over-delivering on features at the same bid-price as the alternatives.

Typically these contracts were “soup to nuts” (or, in MBA speak, vertically integrated) projects involving design and development for companies whose web-presence was to supplement/support an existing business. The customers didn’t much care about platform, had light-to-non-existent integration needs, and certainly didn’t ask for Rails by name.

Hourly/project rates were upper-middle-class, solid and defensible thanks to over-delivering on features. Ultimately most companies have a project budget, not an hourly target rate, so moving deeper into the nice-to-have features for the same dollar cut back on the cheaper cheeper squabbling.

Phase Two – Late-to-Market Web2/Social Networks

The second phase of the Rails contract labor market arrived with the late-to-market Web2 sites and social networks.

Backed by investors, but often without their own development teams, these companies selected Rails based on the visible success of Rails during phase-1. Hoping to get into the market quickly/catch-up, these companies offered premium rates to contract devs.

Premium rates attracted (1) “gunslinger” contract coders and (2) traditional brand/interactive agencies to Rails. This forced the boutique shops to professionalize or lose business to the (1) more experienced coders or (2) better pitchmen.

Phase Three – Influx Of Cheap Labor

My hypothesis is that the rate for undifferentiated Rails labor probably peaked six to nine months ago – marking the entrance to the third phase – and has been on a downward slide since then.

The word “undifferentiated” in that last statement is important. For developers, Rails is a double edged sword. Rails extends capabilities that would previously have been inaccessible to designers and junior programmers. These folks are, quite rationally, drawn into the market by the money attached to Rails, bringing the supply up and forcing the price down. This manifest itself most obviously when heavy-hitter developers started failing to renew their contracts based on price pressure. After launch, these sites turned to lower-end labor.

Initially, I wrote the preceding paragraph with a “market confusion” angle, citing proposals for the same project that varied by as much as 300% for the same hourly labor. Ultimately, though, I decided that that I was confused. There’s a back-side to the “get what you pay for” argument that I’d intended to propose. Sometimes good-enough is, well, good-enough.

At drinks after meetings, we kid about an “acts_as_social_network” plug-in. In a way, junior developer/designer-turned-developer labor /becomes/ the acts_as_social_network plugin. There are tagging plug-ins, comment plug-ins, photo-upload plug-ins, etc. Most of the standard components of social applications are trivial in Rails; a room full of senior contract developers is an expensive way to lash those together.

Phase Four – Mainstream

Undifferentiated labor isn’t normally filled by contract labor. Rails is becoming mainstream, as evidenced by the giant turnout for RailsConf. Combined, these two explain the shift from project-work to full-time positions (including, perhaps, long-term full-time equivalent contracts) that appears to be underway on the job/project boards.

Combatting Downward Price Pressure

As contract developers, we’re entering a market where reputation and specialization have significance in combatting downward price pressure. I’m going to illustrate this point with two companies and two people who’ve been in – and adapted to – the changing Rails contract labor market from the beginning.

Unspace Interactive is Toronto’s premier Rails shop. Launched during the boutique era, Unspace developed an early reputation for productivity and speed-to-market.

Traditionally, developers in a corporate or start-up setting work on a single product/project over the course of many months. At Unspace, they’d turn over project every couple of months. Getting to work on a series of projects, each from the start, compressed into a short period produced a useful side-effect for the Unspace guys: they recognized places in the Rail development process that were un-DRY: they found they were repeating themselves in views, stylesheets and controllers. The widely discussed HAML and SASS projects, and new-to-the-scene make_resourceful project were developed to make these parts of Rails more DRY. Open-sourcing these projects and actively evangelizing them at the worldwide Rails conference circuit cemented Unspace’s reputation.

Slantwise Design, also founded during the boutique era, is developing a reputation as the goto guys for multi-media based Rails apps. Keeping pace with the changing market, the Slantwise team was hired by a late-to-market video startup to build a large scale video transcoding system with a Rails interface. This experience, and the exposure generated by their accompanying RailsConf presentation, has kept them in work and above the rabble of low-rate Rails monkeys.

McClain Looney is a great example of specialized Rails labor. He is the “Rails deployment guy.” When anyone in the Minneapolis/St. Paul area, and increasingly anyone nationwide, wants to go from development to production McClain’s the guy you call. From building a scaleable production environment to database redundancy to optimization, McClain has a set of skills that are rare amongst Rails developers. The concept of a performance/ops engineer isn’t new, but one who works within the Rails framework is. This skill set is high-value, but the work has to be spread over a larger number of clients because projects tend to be episodic and not very long term.

Bruno Bornsztein is the final example of a person adjusting to the changing Rails labor market. Bruno became an expert at building social web applications as a contract coder on a late to market MySpace competitor. Recognizing an opportunity for a specialized social network for home-decorating enthusiasts, Bruno launched Curbly. This is a case of specialization with a twist: his work product becomes an annuity, paying with ad revenue instead of an hourly rate.

Your Input

My observations on the Rails labor market are drawn from examples I’ve seen first hand in Minneapolis, Toronto and San Francisco.

I’d welcome a broader view: has the market played out this way where you work/live? Have some other comment, observation or hypothesis? Add it below in the comments. We’ll all benefit from recognizing changes in the market and positioning ourselves accordingly.

Like this this article? Give it a bump:



Leave a response

  1. MathiasJune 19, 2007 @ 01:42 AM

    Well said! I think in Germany, we’re on the verge of getting into phase three. And that’s not a good thing, since low-quality development will have a bad impact on people already working with Rails for a longer time.

    And you couldn’t be more right about phase two. That’s in full effect right now. Rails is not selected based on technical decisions, but based on hype. I know several start-ups who just chose Rails because everyone does it, strap a tight schedule around their business plan, head off to investors, and then start looking for people willing to work for them. Several had to make the experience you mentioned and put a lot of money into a group of inexperienced developers, only to have to look for an investor and new people afterwards. While I’m all up to doing things in Rails, that’s definitely not the way to approach a project.

    So far so good. I’m pretty excited to see where Rails is going, but I’m afraid the phase of the cheap labor will hit hard. That all reminds me of the days when PHP became the new kid on the block. Inexperienced people swarmed the market, programmed new shops, guestbooks, forums and whatnot by the hour, and drowned the market with low-quality software. I hope I don’t see that happening in Rails. But as you said, there are always ways to fight price pressure.

    Nice post!

    Cheers, Mathias

  2. Colin HendersonJune 19, 2007 @ 07:50 PM

    I don’t buy the four phase thing, and you may be short changing Rails.

    Phases 1 and 2 are business cycle (Demand) driven. 3 & 4 are Supply (of developers) driven. So, yes 3 & 4 will drive down prices but the next business phase will drive up prices, and force out developers with insufficient business accumen.

    After 1 & 2 (Social networks) will or at least should be large enterprise scale applications such as online banking, or merchant inventory systems. Those cannot turned into a high level code by juniors.

    I don’t know where the net effect is, but its not a one way street.

  3. bexJune 19, 2007 @ 08:07 PM

    What about “Value Based Fees?” I always felt that Agile developers never did enough with this. Rails simplifies the code side of many projects so much, that it emphases the people aspect of the problem much more clearly. Thus, people implementing Rails solutions need to be MUCH more than typical geeks.

    Example: you’re not creating a Rails-based sales portal, you’re implementing an overall solution to increase sales by 10%. How much is that worth to your clients? Probably a lot more that $100 an hour…

    Naturally, you’ll need to add a business analyst to the mix who’s familiar with selling value-based fees. That helps tie solid value to the resulting application… as opposed to being yet another web application.

  4. Dan GrigsbyJune 19, 2007 @ 11:41 PM

    Colin said, “After 1 & 2 (Social networks) will or at least should be large enterprise scale applications | such as online banking, or merchant inventory systems. Those cannot turned into a high level code by juniors.”

    Agreed. I’d expect those applications to be built by FT or FT equiv people—note my discussion of “gunslingers” as “more experienced coders.” You’re suggesting something completely different, though: you’re suggesting that large organizations will embrace Ruby and Rails to build big dull corporate applications. I’m not convinced of this for a number of reasions, but don’t want to fight that battle. I’ve simply suggeted that Rails labor, thus far, has come from a set of sources that won’t continue to provide high income to undifferntiated labor.

    Bex said: “Example: you’re not creating a Rails-based sales portal, you’re implementing an overall solution to increase sales by 10%. How much is that worth to your clients? Probably a lot more that $100 an hour…”

    Not the world I live in. If I’m going to gamble like that I’d do it in the form of my own company; pinning my compensation on the performance of a company that I have little overall control over doesn’t thrill me.

  5. Tom BriceJune 25, 2007 @ 11:00 PM

    I agree with Bex. I’m unclear why there is always such a focus on particular technologies. A developer is ultimately not selling Rails (or ruby or Java or whatever) they are selling a solution to a problem. How much is that solution worth? I suppose it matters how you frame the marketing or your services.

    I don’t think Bex was implying that you tie your compensation to the performance of the company, rather I interpreted it as providing service and products based on their perceived value to the client’s business rather than your estimated price of your work based on their requirements. Perhaps the resultant figures are the same but I think the dialog between the consultant and the client in Bex’s example is very different than simply selling a Rails app. In thinking about differentiation maybe consultants in this space will begin to think more about reaching their clients’ business goals and less about marketing a framework.

  6. DanJune 26, 2007 @ 12:14 AM

    Tom: I think you’re right and that I mis-interpreted Bex’s words. I read that as “we partner and share the increase” when it was more of a pure ROI based thing.

  7. sunjayJuly 05, 2007 @ 09:45 PM

    Dan – a very interesting post. Accepting the anatomy of your 4 phases above as fact, I’m still not sure I agree that we’ve gone through them all in the past 3 years—especially, on average, across the entire country.

    Furthermore, I believe larger widespread adoption of the technology and its promise (read: productivity and time-to-market) will, infact, make inroads into the Enterprise. This will give another 3-7 years for the rate/demand cycle to play itself out. Otherwise, what we’re looking it with Rails is a fringe technology that is more embraced than PHP, but less so than Java. A “fringe” technology that will be relegated to start-ups and emerging business … I don’t buy that

    While I have doubts about the uptake for Rails in larger settings, Assuming DHH and crew soften their stances on some things, I believe it will cross the chasm.

    FWIW, we work on “neato” social networking apps and “boring” enterprise projects … It would behoove people to understand that the workforce entering the “enterprise” is influencing the applications that are being built—not all of them are boring …