Our approach is to start really small - we only need a small number of hackers and clients to get started. This allows to be in a similar situation as an small agency - we don't need to match the audience of elance/vworker to make it work. The human/case by case approach requires more work for us, for a lower cut than what an agency would take, but with a different goal in mind for scaling.
We could actually have done the first batch by ourselves, with just clients and hackers that we know and are interested. But we thought it would work as a better validation to give a chance to HN readers to join - we're more likely to get a more diverse set of situations this way.
The advantage for those who will be in the first batch is the extra care and attention we'll dedicate on making it work for them. We'll all be learning from the experience - aside from guaranteeing a place on Hacker Trade in the future, it's also a good opportunity to shape what Hacker Trade will be, and ensure that you get what you need from it.
Deliverable-based consultants always have a high hourly rate, because they are rarely fully booked. A freelancer is often 50% or less utilized, especially if they do short engagements. So in reality, they are making ($100k-taxes-insurance-overhead) per year.
The whole point of hiring a consultant is to get someone who knows what he is doing to do specific work and leave. The alternative is paying an employee $40/hr to learn, do work and take care of overhead activities, and keep that employee around for an extended period.
Offshoring has overhead costs too -- depending on what you are doing, the "total cost of ownership" for an offshore developer may or may not justify taking that route.
Oddly, I've had exactly the opposite problem. It's difficult to find contracts in the $100-200 per day range. If I could find consistent, rewarding, challenging work, then I would gladly do it for standard pay. Unfortunately, I spend so much time finding contracts or getting burned by expanding scope or nonpayment, that I have to charge more just to survive.
Freelancing should pay at least the overtime rate of a typical developer. If someone is contemplating freelance work and makes $50,000 per year, than he or she should probably charge at least $37 per hour or else it makes more sense to work out an overtime arrangement with his or her current boss.
When we account for all of the downtime and having to eat so many losses (that are normally handled by an employer), I think that's how so many developers arrive at numbers of $75-125 per hour or more.
We look at past work publicly available - one of the first links we visit is the GitHub profile. We then take into account the demonstrated skills to evaluate the price asked.
Then, when we do the matching with clients, we take the qualification into account - does the project require high skills? What kind of developer does the client seem to be looking for? Would it work?
The key here is to acknowledge the difference between acquired skill, and ability to deliver - it's ok to be learning, as long as you're in habit of delivering.
Indeed. Starting in the beginning is a fine place to start. ;-)
So, 'b' is really small in y = mx + b. Now tell me about 'm'.
In other words, how will you grow?
Traditionally, there have been two types of organizations through which freelancers work when they can't find their own clients: (1) Body shops place "qualified" resources and take a cut of their rate. (2) Higher-end consulting organizations do project management and take on project-level delivery responsibilities.
Body shops tend to be easier to grow and cheaper. Project-managing groups tend to be harder to grow but with better rates.
What are your plans to move Hacker Trade beyond "really small" in this environment?
One of the lessons from our experience with remote freelance work is that it becomes much easier to work when:
1) The people who are working on the project (client and coder) are good and reasonable
2) When work is split up in short tasks/stories, allowing to always work on tasks of which the size can be reasonably estimated
3) The communication is well adapted to the medium, rather than a simple copy of what usually happens in an office
Although it sounds simple, in practice learning this is difficult, on both sides. We can help manually, as we are doing now, to learn ourselves what is the fastest way to get a new working relationship setup, and working.
For scaling, we think that that learning process can be made very efficient, and scale - you could probably describe our long term goal as to end up somewhere between the two models you're describing. Focusing on producing good matches that produces fruitful relationships, but maintaining enough support/advice to maintain a good level of safety.
Our approach is to start really small - we only need a small number of hackers and clients to get started. This allows to be in a similar situation as an small agency - we don't need to match the audience of elance/vworker to make it work. The human/case by case approach requires more work for us, for a lower cut than what an agency would take, but with a different goal in mind for scaling.
We could actually have done the first batch by ourselves, with just clients and hackers that we know and are interested. But we thought it would work as a better validation to give a chance to HN readers to join - we're more likely to get a more diverse set of situations this way.
The advantage for those who will be in the first batch is the extra care and attention we'll dedicate on making it work for them. We'll all be learning from the experience - aside from guaranteeing a place on Hacker Trade in the future, it's also a good opportunity to shape what Hacker Trade will be, and ensure that you get what you need from it.