It pretty much is that simple. I've had solid success that way multiple times. I once elanced a site that grew to making 5 figures monthly. I know a number of other people who've had even more success than me with it.
The thing is, doing dev in house may have a lot of advantages for many types of startups. But it is entirely possible to come up with a spec, get a mediocre quality (but functional) programming job done to meet it, and then launch it and it takes off. It's even possible to then have your contractors evolve it for you.
I wouldn't say it's optimal by any means, and I much prefer doing stuff in house, at least for what I'm doing these days. The number of startups who succeed by changing courses radically is large, and that's harder to do with the outsourcing model. But that doesn't mean it can't work.
Basically I was providing rake back to poker players. They would sign up at a site through my affiliate link and I would get paid a % of what they paid in rake. I would then pay them most of that back. I would receive amounts every month from the poker sites that a dishonest person with a short time frame would have simply kept and retired on, then pay most of it out.
The business was doing well before I elanced it, but I had hit a point where I could no longer scale without working crazy hours or hiring people. I also wanted my customers to be able to see their stats in real time, etc. So I had a friend (now my cofounder at Blue Frog Gaming) build a cool script to snag the stats from a website and put them in a db. Then I elanced the actual site itself, I think for $500 or so. Some Indian firm banged it out in 2 weeks, I launched it, and was able to grow pretty rapidly.
The point is that the internet isn't like a shopping mall where every business competes with every other for a limited set of eyeballs on the same few things. The salient points of differentiation in many industries have little or nothing to do with quality of code, but they can still make an assload on the web. They just need a website that performs a certain task with reasonable speed and reliability, and if you can define the task, you can get that on elance very cheaply.
You'll never end up with a Flickr, or a YouTube, or a Google that way. But you definitely could end up with a seriously profitable business.
If you are able to spec out how every single screen and interaction works before outsourcing your site then it is that simple. The reason most sites cost hundreds of thousands of dollars and take a year to design is that entrepreneurs don't force themselves to thrash up front.
I would posit that for the vast majority of non-technical would be web entrepreneurs, the one thing that is keeping them from being successful is that they don't do 100% of the design upfront. If you can actually write a completely unambiguous spec and then have the discipline to not change it at all until after the site launches, no magic is required.
You can only write an exhaustive spec if you know what you want - and no startup, and most software projects in general - have no freakin idea what they want 'up front.'
Thats why BDUF failed and hardly anyone uses it anymore. You have to use a prototype to know what you really want and even the prototype changes as you build it. Its an iterative process, and one that requires an intuitive developer as well as customer contact.
And you can't get that using elance. Building good products requires technical intuition that you can't rent.
Exactly. That's why Open Source (Release Early, Release Often) and Agile (iterative) development works so much better. Get the users using the system/site/whatever and build on their feedback.
Spec-and-implement only has two parts, creating a spec and getting the spec implemented. Which part doesn't work?
I'd readily admit that it's not possible to create a web startup based on a single iteration, but I think it can be one box on a much larger PERT chart.
All specs are buggy - they don't spec something out fully, or they spec it and it's wrong when you put it in front of users, or they specify two features that when you try to combine them really don't work well. You can only discover these problems by trying them, because there're basically infinite ways to fail. If you rack your brains trying to think of everything that could possibly go wrong with your spec, you'll inevitably get bitten by something you didn't think of.
So then you start out with a buggy implementation. This could either create vastly more work in the long run, or it could be a huge head start. It all depends on your product, the resources you have available, your sticking points, etc. But there are too many successful examples, like Digg and Squidoo, to completely write off the model entirely.
This is highly dependent on what kind of startup you're doing, as many of the complexities in building a web app are behind the scenes, and therefore can't be captured solely through a requirements spec and perfect mockups of everything.
Agree, but if you're non-technical and you write up a complete spec and have mockups and head to elance, you're likely to be disappointed in the technical execution you end up with.
But if you have a complete spec, then you can take it to a really reputable firm. The way the top web design firms make their money is by charging a relatively low upfront fee (~30k) for a website, but by charging you again every time you change the spec. The reason the firms make money is because 99% of people end up changing the spec, so clients end up spending 150k or so. As long as you never change the spec then you can afford to take it to one of the best design firms in the world, as opposed to hiring some guy off elance.
It takes discipline and a willingness to sit down and have all your fights upfront, but it is possible, and the results make the process well worth it.
The better contractors on elance will guarantee you an hourly rate for changes too. In my limited experience, they seem pretty reasonable about it. It's of course impossible to say whether they're over-billing, but it sure never felt like they were, and the rating system gives them a vested interesting in ensuring that.
That wasn't my experience. Pretty much they'll deliver it, you'll test it to make sure it performs appropriately. There will be some cases where it won't, and they'll fix it.
The only time you'll care about the code quality is when you scale, and if you have that problem you can afford to hire in house.
Right. A thorough functional spec would eliminate the "magic" problem and introduce another concern: management. Having the perfect spec and the right talent guarantees nothing. You must still manage every single step of the dev process. Needless to say, this is non-trivial. OP glossed over this part.
I would go even a step further. I think the "management of talent" concern is so non-trivial that, in many cases, it simply doesn't work. The world has plenty of people with the scars to prove this.
For a tech start-up, I'd put a team of quality hackers on the most critical path. Something the rest of the world conveniently seems to forget.
"Having the perfect spec and the right talent guarantees nothing. You must still manage every single step of the dev process."
You shouldn't have to. Squidoo was completely outsourced. The deal with them was once they handed over the spec the company wasn't allowed to challenge anything. If they had a question about what something meant they were allowed to ask, but that was it. Other than that any communication was forbidden. Because of this the project was done early and under budget. And it seems to have worked; Squidoo is one of the top 300 sites with 91% growth last year.
You're right. You shouldn't have to. But you do. Squidoo is the rare exception. For every Squidoo, there are hundreds of companies whose projects failed miserably because someone dropped the ball somewhere.
The programming is often the easiest part of a big dev effort. People often overlook the specification, design, project management, testing, scaling, security, etc., etc., etc. In the theoretical world (and mainstream media), these things somehow take care of themselves. In the real world, we know better.
+1 for Matt's comment-- for a lot of businesses, the fundamental problem (or at least the first problem that you need to solve) isn't a technical one. Famous example: Digg. Famous example #2: TechCrunch (or any content play, really).
I know of a guy who is minting money doing long-tail adwords for car buying phrases, collecting contact information of the people who click on the ads, and selling that contact info to car dealerships for $20 per. It's not evil-- the pitch is: "enter your contact info any we'll get you three quotes from local dealers".
Bang, no impressive technology required (to prove the initial theory).
I'm using an open-source script and part-time Objective-C developer. But yes, I agree with you in general... to become an AAPL/GOOG/MS requires significantly more emphasis on unique and progressive technology (or to move extremely fast). But to be a profitable web company, it's rather quite easy using secondary development resources. Sugar, Inc relies heavily on Drupal if I'm not mistaken.
"Again, this is a get-rich-slowly scheme: the business generates enough money to house and feed its three founders, who live together in an apartment that doubles as their workplace."
That part is a bit misleading. Airbnb happened to cross over into profitability about the time the article was written, but the graph is quite steep.
I love how articles like this give the general public the perception that software development is akin to getting something heavy off of a tall shelf. Its okay if YOU can't do it, just find someone tall to do it for you, and viola, you'll make a million dollars.
Hi. I am that guy. And we do have some generic offshoots to do other products. But the car thing is our first project, followed by international versions of it. (We're bootstrapping, after all.)
This reminds me of the scene in "Annie Hall" where the guy behind Woody Allen keeps pontifcating about Marshall McLuhan until McLuhan shows up in person to refute him...
MCLUHAN
(To the man in line)
I hear-I heard what you were saying.
You-you know nothing of my work. You
mean my whole fallacy is wrong. How you
ever got to teach a course in anything is
totally amazing.
ALVY
(To the camera)
Boy, if life were only like this!
Hey Alvy, it finally is thanks to hacker news. Another reason why I love it here!
These days you'd do best if your idea either makes people money or saves them money
You might do even better if you save them time, or perhaps fill their time with entertainment, or maybe fill their need for belonging, or self esteem, etc. Money is not everything, perhaps money in fact is nothing.
"When we raised our first Union Square Ventures fund, I told prospective investors to expect 1/3 of our investments to fail. I always like the 1/3 rule, which is that 1/3 of the investments will fail, 1/3 will under-perform expectations, and 1/3 will meet expectations."
"He visited RentACoder.com and Elance.com sites where you can find software developers."
"they quickly enlisted as their partner a former roommate..., who had some technical skills"
If only it were that simple.