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.
No one can, technical or nontechnical. Spec-and-implement doesn't work.
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.
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 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.
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.
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.
Perfect corporate tombstone material.
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.
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.