4 ms·
I had a former life as a web contractor, and almost half of the projects I did were from individual or small groups of founders. They were usually non-technica
by wolfrom 16y ago
I had a former life as a web contractor, and almost half of the projects I did were from individual or small groups of founders. They were usually non-technical or had no knowledge of the web technologies they required. Even though we were able to create some really strong initial products, the businesses themselves never took off.
I think this was often because as a contractor, I finished version 1.0, and then I went off on the next project. I was available for small fixes and enhancements, but I didn't feel it was my job or my specialty to help them iterate or pivot. Without a technical person fully invested in their work, there was no real evolution to their products or their business.
Eventually I came to the point where I no longer took those kinds of contracts, because I either didn't believe in the model, or else I felt that it would only be worthwhile to contribute as a partner as opposed to a worker for hire.
So I think that technical founders are necessary, whether that involves bringing on someone with the knowledge, or having one or more non-technical founders learn enough to become a technical founder.
- dasil003 16y agoI've been in that position too and came to similar conclusions, but there is a huge middle ground between contractors and cofounders: employees.
- wolfrom 16y agoThis may be a debate for another day, but I haven't noticed a big difference in involvement/investment from employees over contractors.
- dasil003 16y agoReally? In my current position I have hired 8 contractors over the last 3 years, and 5 employees. Initially we tried to always hire the best developers we could get, who tended to be contractors. Several of these guys were actual core members on major projects like Rails and Prototype. The work they did was amazing, but we could never get a long term commitment and thus they never came to really understand the codebase, and it was impossible to get emergency bug fixes from them in a timely manner. Of the 8, we still use 1 because he is able to respond quickly, and because the scope of what we use him for is relatively small and well-defined. Of the 5 fulltimers we've hired, only one didn't work out. The others are not quite as good as some of the big names, but definitely above average and able to add real value not just to the pieces of the code they work on, but the overall technical and product strategy.