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 Ruby.mn 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 programming.reddit.com bump:

Thanks!