How to (Not) Hire Freelancers for Your Startup

So... freelancers are vampires.

Just to pick on the most obvious one:

"Freelancers want to make money. They don’t care if your business succeeds or not."

A good freelancer does care. Ignore the other ones. Good freelancers want to be involved in decisions regarding their piece of work. They take interest in what you want to achieve and try to do the best for your project. They pour in an extra hour for a bit of polish that would hurt their pride otherwise.

Freelancing leaves a lot of flexibility and ways to cut deals.

To give you an example: I had multiple prospect clients where I straight-out said "don't build that feature (now) and especially not for my price.". Quite a few ended up not doing (or delaying) the project and were very happy with the decision. All of these turned out to be lucrative events, because those clients pass you on to others with kind words. Find the ones that jump on your idea once you tell it to them and want to work with you. Enthusiasm is (relatively) hard to fake.

Also... I'll never do a fixed price project, unless you agree that: a) it is time-constrained, b) you won't change any of your wishes during the project.

> Hire an expert to regularly review your code. Contrary to what you may think this doesn’t cost much. Any good developer can tell “good” from “obviously bad” code in a matter of minutes. Hire a consultant for one hour and he can tell you exactly what state your code is in.

Generally-speaking, an "expert" is not likely to be interested in periodic code review engagements:

1. Most "consultants" aren't working on an hourly basis, at least one free of reasonable minimums. In other words, good luck finding an expert-level developer eager to take on periodic hour-long "Is this code okay?" projects.

2. A real code review consists of more than just a cursory "this is good code, this is bad code" analysis.

3. A code review doesn't really help a client who doesn't have the ability to rectify issues that are discovered. I can guarantee you that a consultant asked to perform a code review in the scenario described here will nine times out of ten find himself being asked "How do I fix it?" Unless the client is prepared to pay for the skills of a quality developer, getting involved in a "How do I fix it?" discussion is going to be a tar baby for the consultant in question.

4. The author is generally distrustful ("Don’t trust reviews or portfolios", "the motivation of most freelancers directly competes with writing concise code") yet curiously he doesn't consider the possibility that the "expert" you bring on to review your code, if he's looking for development work, has an incentive to raise questions about the quality of the code.

Not all of the advice here is bad, but I think the author generally glosses over the fact that finding good freelance developers and doing so when you have limited technical skills and experience managing the development lifecycle is difficult and may not be a viable approach.

Perhaps I'm a jerk, but I don't feel bad when non-technical people get taken for a ride when hiring people for a tech-startup. I have no business trying to start a hair salon on the cheap, so why should I feel sorry for someone who feels that he can make a go at something that requires highly talented, seasoned workers?

I believe the better solution to most of these problems is to find your freelancer, consultant, etc. through personal channels where their reputation is already established and their past success verified.

For example, you may not have a technical co-founder, but you may have a friend who does, and they're likely to have a friend who is still doing independent consulting. Now, that person may not be available to work with you, but since they're in freelancing circles, they'll likely be able to put you in touch with someone who can, all while knowing that a bit of their own reputation is on the line in the process of recommending someone.

The key here is that you're not finding a stranger online and asking them to establish their credentials. Instead, you have no idea who you'll end up with and the only way you'll find them is if they've got the credentials (and the availability.)

I'm currently working some freelancers on my HypedSound relaunch. The designer and frontend coder both worked on hourly billing but everything was very well-defined. Since the backend is a much more complex scope, it was hard to define hours, and I'm working with a 'variable scope and budget' that we're shooting for. I wasn't ready to commit to hourly billing. Luckily, I have an advisor looking over all the code, which I think is essential as you mentioned. Whether it's a language barrier, technical barrier, or incentive barrier to good communication, you should have someone technical on your side even if they're not doing the coding.

What a terrible article. There are very few actual justifications for the arbitrary claims the guy makes. Even some anecdotes (especially non-personal ones) would be better than this guy's random assertions.

The idea that "goals are not aligned" is very much dependent on the freelancer you hire, and is not a universal truth. The way I approach all my projects is that I (like everyone else) have a limited amount of time left on this earth. I feel a real sense of urgency to make the best use of that time doing meaningful work that I can be proud of.

The idea of just churning on a project to make a few extra dollars really makes me feel a little bit sick. The opportunity cost of that time is just too great. I would much rather take the most efficient route possible to build what my client wants and then be able to start on the next project. Hopefully the client is pleased with my work and that next project might even come from them.

It sounds like the OP was burned at least once by a freelancer in the past. We come across folks like this every so often at matchist (http://matchist.com).

The biggest problem we often see (and I've seen in my previous experience as a freelance developer) is a lack of trust between the two parties. The client doesn't trust the developer to do their job and/or the developer doesn't trust the client to do their job.

The OP has some good ideas about how to establish trust between the two parties (communicating regularly and effectively, but most of his ideas appear to stem from the fact that he simply doesn't trust freelancers from the get go.

>>> Hire an expert to regularly review your code. Contrary to what you may think this doesn’t cost much. A good developer can tell “good” from “obviously bad” code in a matter of minutes. Hire a consultant for one hour and he can tell you exactly what state your code is in. >>>

Where? How? I've tried. Even if for my own code I would love it. Any credible recommendations and I would do it.

Everything made sense to me except for the part about writing tests.

If you're confident you're product will have a long lifespan then tests make perfect sense. But from what I've seen most MVP's are experiments that may or may not stand up to real users.

If you're in the latter camp, writing test code is prematurely optimizing for stability.

That is precisely why I usually recommend avoiding websites like oDesk, elance, freelancer etc. You need to have experience and knowledge in order to weaeve-out the bad candidates... but odds are, it's due to your non-experience that you're looking on these websites.

I've been a freelancer for the better part of 17 years. A few quick reactions:

1. (Code reviews.) This seems really rare, in my experience, and there are a few problems with it. For one, the code reviewer might not be better than the original developer. And they may not know the constraints and development process of the project. Secondly, the one time someone wrote up a major code review for a project I had recently finished, I felt they were nit-picking and falling into the trap of "well, that's not how I would've done it" mostly just so they could land a job fixing the alleged problems.

Even if you're non-technical, I might suggest asking the developer to show you how they've organized the code. Just because you're curious how it works. I really enjoy teaching people about code, and it can be fun when non-technical people get a glimmer of understanding. And I think you can tell a lot about how clearly someone thinks simply by how clearly they can explain what they're doing.

2. (Sample projects.) Sorry, I don't do these. Look at my portfolio, resume, and go use some stuff I've built. If you think I'm lying to you about my involvement in those, then we have a bigger problem on our hands. If you need to, ask me for the contact info of someone I've previously worked with and talk to them about me.

3. (Goals not being aligned.) No two people ever have perfectly-aligned goals -- there's no need to get weird about it. Part of hiring someone is assessing whether you can trust them to do what they're expected to do. You'll get better at this with age. And hiring developers you can meet and talk to face-to-face is probably important. I am a professional and I am invested in the success of my clients. Because I'm a human being with a soul. And because it makes me look better if I can say "I built this app and then the company went on to wild success!"

4. (Tests.) It's all about budget and timeline. And project complexity.

5. (Communication.) Yes, good communication is key.

6. (Hourly vs. fixed-price.) My clients mostly want fixed-price contracts, which is fine. But I don't think it's because they don't trust me -- it's because it's easier to predict budgets that way. If trust is really such an issue that you need to worry about whether a developer is wasting time and you're thinking about hiring someone to audit(!) their timesheet, you have a bigger problem on your hands. So much in life requires trusting people and you need to either find people you can consistently rely on or come up with some ways of judging the trustworthiness of someone that doesn't involve micromanaging them. As for not getting screwed on fixed-price contracts: Trust also comes into play. But so does a well thought-out contract that spells out exactly what's expected from everyone and when. A contract doesn't replace trust. But it does make sure that everyone's on board with all of the nitty-gritty details and it lets everyone know what happens if something goes wrong. Think of it as a design document for your working relationship.

Anyway -- I'm glad people are thinking about these issues, but my general sense, here, is that Danny Britz is fairly new to this and has been hiring people off of relatively impersonal cattle-call sites like Elance. Which is fine. But I think that once you establish a rapport with some developers and get more experience working with them you'll find that you don't have to be quite as fearful that they're going to screw you.