Beware Of The Lying Liars!
We love what we do, but we hate, and steer away from, the corrupt practices in our industry designed to hoodwink you, the custom programming consumer. Here we lay it out for you so you don’t fall prey to the unscrupulous individuals and companies who use these dirty tactics.
The Low-ball trick
Low-balling is so prevalent on freelancer recruiting sites, it’s pushed many honorable programmers out of those systems, as they can’t compete or become disgusted with a platform that is so corruptible. Low-balling consists in offering to do a project at a ridiculously low price which nobody in their right mind could deliver on. The strategy is solely to win the job, and then invariably ask for more money along the way, or you can forget about seeing the job completed. In the end, the project, if completed, is likely poorly done and winds-up costing a lot more than if you had chosen another developer. Unfortunately, many succumb to this scheme at least once and not surprisingly, they will be angry and their next developer will bear the brunt of that anger.
The “it has to be redone” trick
If you have an orphaned app, say because your developers are no longer involved, chances are very high that your new developers will say it’s a disaster and that it has to be redone from zero. It’s a good bet they didn’t even look at the source code and you could show them source from professional well established programs (without telling them what it is) and they would say the same thing. What gives? Programmers generally don’t like to modify others’ code and will do anything to avoid it. Many don’t have the skills to decipher code, even if it’s well annotated. The other motivation is that there’s much more money to make creating an application from scratch. That said, sometimes the code is so bad, tossing it is indeed the best solution, but make sure that’s true before accepting this verdict.
The “It’s almost done” trick
If programmers are infamous for something, it’s procrastination. When your developer says something is almost done, it’s a pretty good bet it isn’t, and actually could be far from done. The tactic is to keep you at bay, buying more time, and next time you ask, they could use the “unexpected complications” trick which is outlined next. Many developers take on more work than they can possibly handle, and they’ll often spend most of their time on the project that pays them the most or that they enjoy most, or that which they’re at higher risk of losing the client. If you hear several “it’s almost done” on a project, you may have to ask for hard proof.
The “unexpected complications” trick
This is another common tactic designed to buy time or generate additional charges, or both. While it could be true, the real question is if it’s because the developer lacks the skills, or did not plan well? Ask for more detail on the alleged problem. If the answer sounds dodgy, it probably is. Most programmers can find solutions to problems right on the web, just by googling the issue, so unless it’s a monster of a problem, this shouldn’t even be a topic of conversation! Our advice here is that if you trust your developer, don’t argue the point, but if it’s somebody you don’t know well, don’t be afraid to ask pointed questions.
The “Research” charge trick
This is an all too common charge that appears on your developer’s bill, particularly from freelancers, and it’s one you should question, especially if it’s substantial. Is this custom project actually something so innovative that the coder has to figure out how to make it happen? If so, research can be legitimate billable work. However, if it’s actually the programmer learning on the job, the question is “hey, shouldn’t you know this stuff already?”. It’s presumed that whom you hire should have the necessary skills and you shouldn’t have to pay them “to go to school”, unless you like them so much you’re happy to do that! Our advice is to agree in advance to research and set a cap on the time. Incidentally, research is often just an euphemism for “Googling”!!
The Old “steal your deposit” trick
This one has been around forever and unfortunately still happens to this day, particularly where offshore freelancers are involved. While it’s completely normal for you to pay an advance to the developer before the project begins, there are those whose game consists in getting this money and never producing a line of code in return. Tell tale signs that this is going to happen is when the project start date keeps being moved forward, or you’re being told work is underway but have yet to see the results in a demo. Getting your money back can be problematic if the developer is in a country where there’s no protection for foreign businesses. The best strategy here is to do your homework well before hiring, or to use a reputable 3rd party service that holds your deposit in escrow until the project is completed.