7 ms·

How to (Not) Hire Freelancers for Your Startup

27 points by dennybritz 13y ago

danhou 13y ago
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.
- dennybritz 13y ago
  Totally agree, but I thought I wrote that ;) "If you know that you will start from scratch soon you can most likely skip the tests and focus on testing your hypotheses as quickly as possible."
  - danhou 13y ago
    Yeesh, just went back and re-read that. I fail at reading.
- BerislavLopac 13y ago
  Only if you write unnecessary tests: e.g. for CRUD code, or for front-end UI. But when you have complex procedures with clearly defined outcomes, writing tests is never premature.
- hcarvalhoalves 13y ago
  > If you're in the latter camp, writing test code is prematurely optimizing for stability. Not sure test have something to do with stability. Writing test code will help document the code for the next developer who touches the hair ball and will force better definition of requisites in the MVP phase.
- Argorak 13y ago
  The "write tests" part could be rewritten as: don't let the freelancer dictate the rough technical direction. If you want a proper state-of-the-art software project, tests should be included.
- readme 13y ago
  It doesn't need to make sense. Author is obviously a devout monk in the church of TDD. The view is purely religion.
Argorak 13y ago
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.
- dennybritz 13y ago
  I don't disagree with you that "good" freelancers should care, but that doesn't change the fact that (in my experience) most do not. That being said, most of my experiences were with "low price" freelancers, which probably has a high correlation with that fact.
  - Argorak 13y ago
    Sure. If you buy at a low price you show that _you_ don't care.
- StavrosK 13y ago
  I agree, a lot of this sounds like he just found bad freelancers. I have been contacted in multiple occasions by people who wanted to launch their own startup and wanted to hire me to write it, but it was clear that they didn't have all the business details ironed out. I advised them to get feedback first, then try for an MVP based on that feedback, and then come to me for implementation. They were all very happy with this, because it's good advice they hadn't considered, and it's free. Also, working as a freelancer right now (although in a more long-term role), I definitely am concerned about code quality and the thing I'm making working well, because I'm the one who's working on it. Writing unmaintainable code on purpose is not only unethical, but it comes back to bite you in the ass when you have to maintain it. Thankfully, I have no shortage of work at the moment, so it wouldn't be my dream job to have to work on an unmaintainable mess, much less so when I created it. I disagree with the article a lot.
mjolk 13y ago
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?
- StavrosK 13y ago
  "Perhaps I'm a jerk, but I don't feel bad when non-waiters get taken for a ride when hiring waiters for a restaurant." This makes no sense. If you want to open a restaurant, you need to know the restaurant business well, not how to efficiently coordinate table serving.
  - mjolk 13y ago
    If you want to open a restaurant, you sure as hell better know how to screen for qualified waiters/bartenders.
  - pkinsky 13y ago
    Sure, but you'd better be able to tell if the servers you hire are doing a good job. Ditto for cooks, cleaners, dishwashers. You shouldn't need to hire someone to look for flecks of food on your 'clean' dishes.
  - jtbigwoo 13y ago
    Alternatively, if you want to open a restaurant, you shouldn't need to be an expert in plumbing, electrical, framing, HVAC, upholstery, cabinet-making, painting, and floor refinishing just to get the place ready to open.
    - StavrosK 13y ago
      That might be a better analogy, yes.
    - mjolk 13y ago
      Sure, but you hire professionals to perform and inspect this work, and at the end, have a local official verify the work has been done. Your example really stretches the analogy as buying/renting a structure is not at all similar to trying to get a stranger to build a core product that you can't maintain.
jonathanjaeger 13y ago
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.
Gorbzel 13y ago
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.
- dennybritz 13y ago
  Yeah, these are just my personal experiences, no hard data. I added a little note making that clear.
  - Gorbzel 13y ago
    You did, but you also titled the article "How to...for YOUR startup", implying that somehow these tips are valuable lessons for others, when really any founder taking this advice (without more) is doing him/herself a disservice. An example, lest I just be picking on you. Other commenters have already reasonably tackled many of the other assertions, so let's go with this one: "Developers have gotten really clever about creating fake portfolios" First of all, how do you even know this? Did you work with someone who did this? Have you discussed this w/other entrepreneurs who experienced this? Did you hear a rumor somewhere? No one's demanding hard data, but it's fair to expect you to back up your assertion WITH AT LEAST SOMETHING. Even if you had a personal story, you'd have experience that others could use to detect red flags. Second, what did they do? Get fake apps uploaded to the App Store? Put together screenshots that weren't theirs? What is this super clever scheme that you've discovered? I assume it's not that clever, if it exists at all, but there's no way to tell. Finally, your lack of trust just creates a hostile environment around what might otherwise be some good advice. I'm a freelance dev and I LOVE SAMPLE PROJECT "INTERVIEWS". There's a number of reasons why they are significantly better than just guessing based on a resume and some technical questions (especially w/non-technical startup founders), but I expect to go into first time projects with a sense of optimism and mutual respect, not mindless fear. Your article starts out noting that it's best to find a technical co-founder, and I couldn't agree more. Devs often understand what is going on in the mind of other devs, but also represent the needs of their company, so it's a good balance. Way better than relying on overseas talent using this linkbait as a guide. Ugh.
aculver 13y ago
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.)
7Figures2Commas 13y ago
> 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.
- cpt1138 13y ago
  re: #4 is that kind of distrust warranted? Is it really common that portfolios and reviews are falsified?
- hga 13y ago
  While you make a lot of good points, I'd note that you're more likely to know a good enough, if perhaps not expert-level developer who has some time to do code reviews, than one who has enough time to actually do the work. Or at least I've done this before. With, I'll admit, at least one instance where I raised red flags which were ignored for a long time until I was finally hired to deal with a by then terminal* as it turned out mess. * Before the company could be saved the early '90s recession killed its profitable line of business.
chasing 13y ago
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.
whiddershins 13y ago
>>> 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.
markkanof 13y ago
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.
BigBalli 13y ago
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.
timjahn 13y ago
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 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.

27 points by dennybritz 13y ago

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.

dennybritz 13y ago
Totally agree, but I thought I wrote that ;) "If you know that you will start from scratch soon you can most likely skip the tests and focus on testing your hypotheses as quickly as possible."
- danhou 13y ago
  Yeesh, just went back and re-read that. I fail at reading.
BerislavLopac 13y ago
Only if you write unnecessary tests: e.g. for CRUD code, or for front-end UI. But when you have complex procedures with clearly defined outcomes, writing tests is never premature.
hcarvalhoalves 13y ago
> If you're in the latter camp, writing test code is prematurely optimizing for stability. Not sure test have something to do with stability. Writing test code will help document the code for the next developer who touches the hair ball and will force better definition of requisites in the MVP phase.
Argorak 13y ago
The "write tests" part could be rewritten as: don't let the freelancer dictate the rough technical direction. If you want a proper state-of-the-art software project, tests should be included.
readme 13y ago
It doesn't need to make sense. Author is obviously a devout monk in the church of TDD. The view is purely religion.

Argorak 13y ago

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.

dennybritz 13y ago
I don't disagree with you that "good" freelancers should care, but that doesn't change the fact that (in my experience) most do not. That being said, most of my experiences were with "low price" freelancers, which probably has a high correlation with that fact.
- Argorak 13y ago
  Sure. If you buy at a low price you show that _you_ don't care.
StavrosK 13y ago
I agree, a lot of this sounds like he just found bad freelancers. I have been contacted in multiple occasions by people who wanted to launch their own startup and wanted to hire me to write it, but it was clear that they didn't have all the business details ironed out. I advised them to get feedback first, then try for an MVP based on that feedback, and then come to me for implementation. They were all very happy with this, because it's good advice they hadn't considered, and it's free. Also, working as a freelancer right now (although in a more long-term role), I definitely am concerned about code quality and the thing I'm making working well, because I'm the one who's working on it. Writing unmaintainable code on purpose is not only unethical, but it comes back to bite you in the ass when you have to maintain it. Thankfully, I have no shortage of work at the moment, so it wouldn't be my dream job to have to work on an unmaintainable mess, much less so when I created it. I disagree with the article a lot.

mjolk 13y ago

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?

StavrosK 13y ago
"Perhaps I'm a jerk, but I don't feel bad when non-waiters get taken for a ride when hiring waiters for a restaurant." This makes no sense. If you want to open a restaurant, you need to know the restaurant business well, not how to efficiently coordinate table serving.
- mjolk 13y ago
  If you want to open a restaurant, you sure as hell better know how to screen for qualified waiters/bartenders.
- pkinsky 13y ago
  Sure, but you'd better be able to tell if the servers you hire are doing a good job. Ditto for cooks, cleaners, dishwashers. You shouldn't need to hire someone to look for flecks of food on your 'clean' dishes.
- jtbigwoo 13y ago
  Alternatively, if you want to open a restaurant, you shouldn't need to be an expert in plumbing, electrical, framing, HVAC, upholstery, cabinet-making, painting, and floor refinishing just to get the place ready to open.
  - StavrosK 13y ago
    That might be a better analogy, yes.
  - mjolk 13y ago
    Sure, but you hire professionals to perform and inspect this work, and at the end, have a local official verify the work has been done. Your example really stretches the analogy as buying/renting a structure is not at all similar to trying to get a stranger to build a core product that you can't maintain.

jonathanjaeger 13y ago

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.

Gorbzel 13y ago

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.

dennybritz 13y ago
Yeah, these are just my personal experiences, no hard data. I added a little note making that clear.
- Gorbzel 13y ago
  You did, but you also titled the article "How to...for YOUR startup", implying that somehow these tips are valuable lessons for others, when really any founder taking this advice (without more) is doing him/herself a disservice. An example, lest I just be picking on you. Other commenters have already reasonably tackled many of the other assertions, so let's go with this one: "Developers have gotten really clever about creating fake portfolios" First of all, how do you even know this? Did you work with someone who did this? Have you discussed this w/other entrepreneurs who experienced this? Did you hear a rumor somewhere? No one's demanding hard data, but it's fair to expect you to back up your assertion WITH AT LEAST SOMETHING. Even if you had a personal story, you'd have experience that others could use to detect red flags. Second, what did they do? Get fake apps uploaded to the App Store? Put together screenshots that weren't theirs? What is this super clever scheme that you've discovered? I assume it's not that clever, if it exists at all, but there's no way to tell. Finally, your lack of trust just creates a hostile environment around what might otherwise be some good advice. I'm a freelance dev and I LOVE SAMPLE PROJECT "INTERVIEWS". There's a number of reasons why they are significantly better than just guessing based on a resume and some technical questions (especially w/non-technical startup founders), but I expect to go into first time projects with a sense of optimism and mutual respect, not mindless fear. Your article starts out noting that it's best to find a technical co-founder, and I couldn't agree more. Devs often understand what is going on in the mind of other devs, but also represent the needs of their company, so it's a good balance. Way better than relying on overseas talent using this linkbait as a guide. Ugh.

aculver 13y ago

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.)

7Figures2Commas 13y ago

> 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.

cpt1138 13y ago
re: #4 is that kind of distrust warranted? Is it really common that portfolios and reviews are falsified?
hga 13y ago
While you make a lot of good points, I'd note that you're more likely to know a good enough, if perhaps not expert-level developer who has some time to do code reviews, than one who has enough time to actually do the work. Or at least I've done this before. With, I'll admit, at least one instance where I raised red flags which were ignored for a long time until I was finally hired to deal with a by then terminal* as it turned out mess. * Before the company could be saved the early '90s recession killed its profitable line of business.

chasing 13y ago

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.

whiddershins 13y ago

>>> 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.

markkanof 13y ago

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.

BigBalli 13y ago

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.

timjahn 13y ago

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 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.