Once a small group of finalists are selected it is time to evaluate each one closely. Since it might be hard to keep them straight, it is a good idea to start a list or spreadsheet so you can make very direct comparisons. Read their proposals carefully to see how well they address the project specifically, how well they explain their experience and skills, and how impressed you are overall with their professionalism. Carefully review the examples of their work provided to you. Do the samples show related app programming skills? Do they have any apps commercially available?
Create columns for each outsource candidate attribute you want to evaluate, like price, schedule, and ratings/feedback. You can also use the spreadsheet to rate each candidate in these and other areas. Consider rating each candidate 1 to 5 in several categories, then averaging the scores to see how each programmer stands. Add any other thoughts about the developer in the Notes column.
On freelance sites, you can also visit the profile pages of prospective developers to see a more complete history. One telling component of the profile page that you will not see on the proposal is the number of jobs awarded but not completed. That could be a sign of a developer who is great at proposals, but lacks the hard skills needed to follow through with projects. Any developer might have a project or two that falls through for some reason, but a trend in this area should be a warning sign. You can also see more extensive feedback comments and a more complete work history on profile pages.
As you evaluate the developers to select one to hire, note any questions you have about them or about the project. Do not hesitate to contact someone that submitted a proposal with follow-up questions, in fact it might be a good idea to come up with a list of question after reviewing all the finalist’s proposals and send them to each programmer to see how well and how quickly they respond. For example, are they willing to use Skype and are they willing to review and demonstrate progress (milestones) a few times during the project? Are they willing to sign a non-disclosure agreement?
Non-disclosure agreements simply state that developers cannot share, sell, or otherwise profit from the proprietary app design or idea. It is a very standard document, and most reputable developers are accustomed to signing them, since it only applies to proprietary information and does not apply in any way to public knowledge or technology. However, theoretically it will prevent an unethical programmer from using your app flowchart to create the app and sell it themselves. Most freelance sites have standard forms like these that are available for you to use. On Elance they can be a bit hard to find, so just start entering “non-disclosure agreement” in the Help search box and it will pop up. Non-disclosure agreement forms are also available at dozens of legal help websites for free or for a small fee.
While this may seem like a lot of work, if you want to take the next step with the app project, you have to select and hire a developer.
If this is a large, complex, expensive development project, the magnitude of importance for this decision is greatly increased. If this is the case, then you might want to consider hiring two or three app programmers that would each develop a small part of the application. Then you can select the developer that does the best work to continue with the project. If you are making a big investment into creating an application, using a small part of your budget to make sure you find the right developer is worth the price.
You can negotiate the proposed price with developers. If things are a little slow or they do not currently have an active project, then most developers would be happy reduce their price a bit to land the job. A developer with plenty of work, on the other hand, has little reason to negotiate. So there aren’t any hard and fast rules. If you have a tight development budget and the programmer you want is little above the budget, then it never hurts to let them know where your limit is and ask if they could do the project at that rate. If you do decide to negotiate with the developer, there are a few unwritten rules to remember.
No one wants to be nickeled and dimed – If it is already a very low cost project then take proposals at face value. For example, it seems really cheap to try to get a provider to reduce the price from $500 to $450. On the other hand, if your budget is $3000 and a qualified provider proposed $3500, it would not be insulting to ask if the provider could meet the $3000 budget. They may at least offer to meet you halfway.
Be Respectful – Don’t try to get a provider to reduce the price by disparaging their work or by harping on how “easy” the project will be to code. You just caused their “bad client” warning lights to flash. Experienced programmers learn to avoid problem clients.
Keep Sob Stories to Yourself – Don’t try to get them to reduce the proposal price with a sad story. Every business has problems. Good developers just want to work on your project for a fair price, they don’t care how cash strapped your start-up is, or that you just lost money on a bad developer, or that your mother is ill. A straightforward reference to the budget limitations is fine, but after that you should keep your problems to yourself.