I've had a couple of experiences where a startup hired contractors initially and then brought in staff as things ramped up. Though the contractors are indeed often great developers, they rarely have an insight into the business because they are not involved in the industry and since they will be on to the next gig after yours, they don't have any real need to become an expert. For that reason and also because contractors are writing to fulfill contractual obligations - they tend to write exactly to spec, which can sometimes produce an application that isn't very good. Because actual programers assigned to our project would revolve in and out it led to inconsistency and jumbles of technologies that causes major headaches for the next phases of development. There tends to be a feeling among the staff developers that the contractors don't care anything about maintainability because they never have to deal with that aspect. They are long gone to the next gig and it's not their problem so they just want to get things working as quickly as possible.

Building a startup is a time when you are finding your way and you really need people who are interested in the details of your industry. People who will look at a spec and notice things missing, or improvement to be made.

I do think that hiring contract programmers can be good and I do so myself. But I limit their involvement to smaller sub-projects that can be written to spec and easily plugged into our app. I've done that with visual components, things that require specialized knowledge of an open source framework or really complex math algorithms, etc. It has worked very well in those cases.