Dear John Smith,
Congratulations on choosing a coder recently on Rent a Coder.
Rent a Coder provides you with a number of unique protections that ensure that
all transactions will be a safe and profitable one for you. However, too many
times I have seen buyers sabotage themselves by not using these protections
and/or ignoring the site rules and guidelines. They unnecessarily lose time and
money when there was absolutely no need to.
To prevent this from happening to you, I’ve prepared this very
important email for you. If you value your time and money, I invite you to read
everything below. Taking a few minutes now to do so may prevent you from
experiencing a very large "headache" later on.
1) DON’T go offsite to communicate with the coder.
After you accept the coder, you are highly recommended to
continue to use the site comment system to communicate with them. When you do,
all communication (including any enhancements, changes, etc) then becomes part
of the "entire bid request"--which is the binding legal agreement between you
and the coder.
Some people prefer to communicate with the coder offsite (by
email, IM ,etc.) rather than use this feature. I cannot emphasize enough how
DANGEROUS this practice can be. If you or the coder puts the bid request into
arbitration, NOTHING that is communicated offsite can be taken into account.
(The reason for this is that logs of all offsite communication can be easily
faked and changed). This can present a serious problem for you. As an example,
let’s pretend that the coder did a great job, except for one thing. They agreed
to do a significant enhancement for you for free (via an offsite IM message)
that they later did not do. If you put the bid request into arbitration, we
cannot take the offsite communication into account in arbitration and force the
coder to do it. You would have to pay them even if though they didn’t do that
enhancement!
To protect yourself, the safest thing to do is to do all your
communication on the site….then you never have to worry about this. However, if
you still prefer another communication channel then there is another solution.
After you complete your offsite conversations with the coder, document all the
changes that you’ve both agreed on. Then post this to the site and get the
coder to post back a response saying that they agree to it. This will fully
protect you in case of a dispute.
2) DON’T mishandle requirements changes.
Very few software projects don’t change somewhat as they are
developed. There are generally two types of changes…minor changes and major
changes. Mishandling either type can result in a loss of time and money.
Minor changes generally don’t involve significant additional
effort from the original requirements. When you and the coder agree to this
sort of change, make sure you document it on the site to avoid later problems
in arbitration as mentioned above under off-site communication.
A major change involves significant
additional effort outside the scope of the original requirements. When you find
you need to do this sort of change, it is not proper (nor allowed) to expect
the coder to do it for free. They bid on your original project, so if that work
expands, then it is only fair to compensate the coder for this.
When you have a major change, we ask that you approach the
coder and find out if they are willing to take on the extra work and if so,
then you can negotiate a mutually agreeable price.
If you are successful in this, then simply document it all on
the site (and get them to agree to it). After that, either you or the coder can
contact us to have us increase the price and escrow the additional funds.
If you are not successful, then you can always get another
coder to bid on the change via a new bid request. Please do realize that you
cannot pull out of the project simply because the original coder refuses
additional work which was not initially agreed to. If you do this, then the bid
request will go into arbitration where the code will be tested and the coder
will be compensated by a partial or full payment from escrow for the percentage
of work already done and completed. Additionally, a bad rating will be placed
on your account. So we ask that you not force us to go through this with you.
3) DON’T mishandle work acceptance.
To protect you, Rent a Coder puts you in full control of when
the coder will be paid. You do this by accepting their work, which release the
funds from escrow to their account. However if you mishandle that control by
not following the site rules, it can result in putting your funds at risk.
Never accept work before you’ve fully tested it and you are
100% satisfied.
Some buyers accept work prematurely, because they don’t feel
like going through the ‘hassle" of testing and/or they feel that they can
‘trust’ the coder. Others do so because a coder pressures them to do so…a
practice which is not allowed, incidentally, because of the propensity for
abuse. Accepting work prematurely is a VERY DANGEROUS practice. If you do this
and you later find out that the coder didn’t give you what was agreed upon,
your money is gone and you will have no recourse! The enormous protections of
escrowing and arbitration are completely nullified by your actions and you’ll
have to hope that the coder (who already has your money) is nice enough to fix
whatever problem you have. So please protect yourself by doing your due
diligence in testing and only accepting work once you are 100% satisfied. If a
coder pressures you, remind them that doing so is against their contract, and
contact us. Taking these precautions will keep your funds safe.
4) DON’T forget to consider milestones.
If you have a project lasting longer than a week (and sometimes
even when the time required is less than a week), you should strongly consider
using a process involving what are called "milestones". Studies have shown that
buyer satisfaction in software projects increases dramatically when you do
this.
It works like this. You split up the project (via onsite
communication) into achievement stages called milestones (or ask the coder to
do so if you are unsure of how to split up the project). As each milestone is
achieved (and you are 100% satisfied with the work at that stage) you then
accept it is complete, giving the coder a partial payment for it. If you are
not, you can either call off the project or you can choose to give the coder
additional time to get it right.
Studies have shown that ‘milestone’ projects have a much higher
success rate than ‘all or nothing projects’. First, the process forces the
coder to show demonstrable progress throughout the project, rather than just at
the end. This generally makes them work harder, and also allows you to make
corrections earlier while there is still time to make them. Second it forces
both parties to communicate more often, resulting in a product that better
reflects your needs and desires, than in one without that communication. And
finally coders get something good out of it too, because they are rewarded as
they go, rather than in one lump payment at the end. This is great for their
motivation, which helps both them and you.
We cannot recommend the software milestone process enough to
all of our buyers. If you choose to do this, remember to completely document
on-site each milestone and what percentage you will release (and have the coder
agree to it).
