During the dot-com era, a new set of heros were discovered: startups. Rejecting the suit-and-tie of their former lives, brave men and women wore jeans and baseball caps to work and demanded comfortable chairs. They shed the shackles of their soul-stifling 9-5 jobs in Corporate America and worked long hours for smaller companies. Fortunes were made and lost in a matter of weeks. Porsche Boxters littered the California highway, the People’s Car of this revolution.

The story ended in tragedy, but we were all taken on a wild ride, and we enjoyed it. We are chastened now; investment money is harder to come by, and companies are often forced to figure out their product before they figure out their IPO. And yet the idol of the startup founder remains with us, working long hours in jeans and sneakers, drinking too much coffee, negotiating eight-figure venture funding deals. Dreaming of a 12-month concept-to-funding-to-sale cycle (or is it funding-to-concept-to-sale)?

This idol is back, in an upgraded 2.0 form. The names have changed (Digg instead of Lycos); they are often smaller and more frugal; and many of them will succeed.

But the idol needs to be dispelled.

Meebo is a startup in Silicon Valley that provides an in-browser, cross-protocol IM program. Think iChat or Trillian in a browser.

Business Week recently published an article on Meebo. It’s a typical dot-com profile. Meebo has 10 engineers, 7 business types, and is hiring. Their product is fairly complex and cool, with an Ajax front-end, a C++ backend, and a made-up name. Its developers work 14- to 16-hour days to keep the site running and to add new features like Meebo Rooms (kind of like chat rooms, but with 100% more Meebo). The environment is fun and informal, with ethnic take-out, games, toys, inside jokes, and Simpsons posters. Meebo also has serious VC funding from Sequoia Capital and Draper Fisher Jurvetson.

This makes for an exciting Business Week article: our eHeros are back! But two things give me pause.

First, 15 hour days are not a good thing. Long days at a startup sound sexy, like Aeron chairs and razor scooters. There are plenty of people out there that those kind of hours are ubiquitous for tech startups, like a company can’t succeed on 40-hour weeks. But death marches typically end with, um, death. Those hours can ruin a company and its employees. And more importantly, working long hours isn’t good for software. Software development is hard, and 40 good hours are better than 80 tired hours. I know developers who have burned out, gotten physically sick, and divorced because of this kind of thing. It isn’t healthy, sustainable, or profitable.

Second, Meebo won’t be a success unless it sells for $500 million, according to Business Week, and that just isn’t a good business plan. Paul Graham explains this well:

Venture investors like companies that could go public. That’s where the big returns are. They know the odds of any individual startup going public are small, but they want to invest in those that at least have a chance of going public.

Currently the way VCs seem to operate is to invest in a bunch of companies, most of which fail, and one of which is Google. Those few big wins compensate for losses on their other investments. What this means is that most VCs will only invest in you if you’re a potential Google. They don’t care about companies that are a safe bet to be acquired for $20 million. There needs to be a chance, however small, of the company becoming really big.

In other words, if VCs put $10m into Meebo in exchange for 40% of the company, then they’ve valued the company at $25m ($10m / .4 = $25m). So if they want a 20x return, then Meebo isn’t worth selling for less than $500m ($25m * 20 = $500m). In practice, they might be interested in cashing out at $100m if things look “bad” (for a 4x return), but they certainly wouldn’t want to sell for $20m, since that would actually represent a loss.

Maybe Business Week is exaggerating – I hope they are. I have no inside information on Meebo, and so maybe Business Week (or I) have the details wrong. But really, how many web startups sell for half a billion dollars? Maybe one a year? Off the top of my head, we’ve got MySpace, YouTube, and Skype (if Skype counts) over the last few years. Does Meebo provide anything as wide-reaching or revolutionary as these?

Venture capital may be great for biotech, aerospace, semiconductors, &c. But $10m isn’t needed for most web startups. There is another approach to startups, which understands the inefficiencies of large teams and the value of constraints. Throwing $200,000 at a programming problem often produces better results than throwing $2,000,000 at it. Not always, but often. If you have enough money to bootstrap a small team (3-5 developers) for a year, and if you (ahem) have a revenue model, you’ve got what it takes to build a business. You probably don’t need venture money.

And really, who wants to start a web business that isn’t a success at $30m?

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!