Dear John Smith,
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 coders sabotage themselves by not
using these protections and/or ignoring the site rules and guidelines. They
unnecessarily lose time, money, their good ratings, and sometimes even their
entire account on Rent A Coder.
To prevent this from happening to you, I’ve prepared
this very important email for you. If you value your time, money or account on
Rent A Coder, you need to read and understand 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 buyer.
After the buyer accepts you, 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 buyer.
Some people choose to communicate with the buyer offsite
(by email, IM ,etc.) rather than use this feature. I cannot emphasize enough how
DANGEROUS this practice can be. If the buyer 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 the buyer said you were to perform a certain task for them when
they posted the bid request, but later told you they didn’t want it via an
offsite IM message. The two of you later have a disagreement and they place the
bid request into arbitration. You will lose the arbitration and the project,
because the change to the specification isn’t documented on the site, and you
did not deliver to the specification.
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 (or the buyer insists on it), then there is
another solution. After you complete your offsite conversation, document all the
changes that you’ve both agreed on (which you should be doing anyway). Then post
this to the site and get the buyer 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 lost arbitration or a loss of
time and potential profit.
Minor changes generally don’t involve significant
additional effort from the original requirements. When you and the buyer 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 the buyer asks you for this
sort of change, do NOT feel that you must automatically do it for free. This is
especially important for you to remember if you come from a country/culture
where “workers” are expected to always agree with their “bosses”, even when
their bosses are “wrong”. That is not the way we do things on Rent a Coder.
Remember, you are NEVER forced to do work beyond the original requirements you
bid on!
When a buyer requests a major change, you are fully
within your rights to politely inform them that what they are asking for falls
outside of what you bid on. Explain to them why this is the case and why it will
involve so much extra work. Then attempt to negotiate a higher price and/or extended deadline based on
the extra work.
If you are successful, then simply document it all on
the site (and get them to agree to it). If you've negotiated a higher price,
ask the buyer to contact us to have us escrow the additional funds from them.
If you are not successful, then either the buyer will
decide to drop the change (and things will continue as normal), or they will
decide to pull out of the project. If they decide to pull out of the project,
then this is considered to be a breach of contract by the buyer. If you’ve done
work already, such a breach will result in a partial or full payment to you to
compensate you for the percentage of work done. Additionally, it will NOT
reflect negatively on your rating…although it usually will do so on the buyer’s
rating.
3) DON'T allow lack of buyer response to affect you negatively
Sometimes a buyer doesn't provide you with requirements, clarifications or
answers that you need to continue, or disappears entirely. If they do, those
actions are beyond your control. However your response to those actions is in
your control. Don't make the mistake of ignoring the situation, trying to guess
what they want, or WORSE, doing nothing and hoping it will get better! If you
get into arbitration and you've done any of these things, it will not be deemed
an acceptable excuse for missing the deadline. Instead, follow the following
procedure and then Rent a Coder can fully protect you if the project goes to
arbitration:
a) Communicate onsite to the buyer exactly what you need and why you need it:
ex. "John Smith, I need the answers to those questions I asked you about
yesterday. If I don't have those, I can't build the payment portion of the GUI
which is one of your requirements. Much further delay will affect my ability to
deliver this project on time. Please respond so I can
continue."
b) Hopefully they will respond positively. If they don't, then tell them how
their lack of response has affected the deadline onsite.
ex "John I still haven't heard back from you. I committed to a deadline because
I counted on you responding on a more timely basis. Since that hasn't happened I
must warn you that I will need x more days now to complete this project. If you
don't want to continue, then please let me know and we
can put this into arbitration for a cancellation. Otherwise, please extend the
deadline on the site. Either way I would love to hear back from you. Thanks."
c) If they respond positively, that is great. If they ask for arbitration, you
will receive a partial payment for work completed and not receive a bad rating.
The buyer may receive a poor rating.
d) If they don't respond at all, then put the project into arbitration. We will
protect coders that follow the above procedure, and if the buyer don't respond
to our arbitration request either, the buyer will receive a bad rating and you
will receive a partial (or full) payment for work completed.
4) DON’T mismanage deadlines
Too many times I’ve seen uninformed (and occasionally
lazy) coders mismanage one or more of the 3 bid request deadlines and lose
arbitration unnecessarily. To protect yourself, make sure you do the following 3
things:
a) DO file status reports every Friday.
On projects above $150 you have agreed to file a weekly
status report on Friday. Don’t forget! If you do not do this, not only will your
rating be penalized but if the buyer reports that he does not wish to continue
with you, you will lose the project. Please don’t force us to arbitrate against
you.
b) DO upload the complete deliverables before the
deadline.
This is something else you’ve agreed to that you cannot
forget. You MUST upload 100% of the completed deliverables to the site before
the deadline. If there is a dispute and we need to test your deliverables, this
is what we will test. If you do not do this, and the buyer puts the bid request
into arbitration, you will automatically lose. We cannot accept deliverables
uploaded after the deadline, because that gives an unethical coder additional
time to fix bugs, etc.
If you have problems uploading large files to the site
due to your connection speed or distance from us, email the facilitator your
attachment and they can assist you. But make sure this is handled well in
advance of the deadline, to allow for any time delay, email size limit problems,
etc..
c) DO renegotiate the deadline if you know you can’t
make it.
You should be communicating with the buyer regularly.
However, if you are run into a problem that will force you to miss the deadline,
you need to take extra care to let them know (on-site) exactly what the problem
is. Often you can get them to renegotiate the deadline. If so, then preferably
you should get the buyer to contact us to officially extend the deadline shown
on the site. This will give you the maximum protection.
5) DON’T Use 3rd party code without understanding all
copyright ramifications and explaining it to the buyer on site.
Many coders think they can get a jump start on finishing
a project by using 3rd party code that they don’t own. However, most 3rd party
code (including open source code such as GPL, GNU, etc.) is covered by a license
that places some sort of restriction on the buyer regarding full copyright of
the code. This of course is in violation of the standard request that most
buyers require…100% copyright with no restrictions.
If you are going to include 3rd party code, then you
need to take special precautions. Explain the copyright ramifications to the
buyer and then get their approval (on site). If you don’t understand the
ramifications yourself (or you just want to be safe) then a smart procedure is
to upload the entire license for the buyer to view, and ask them to approve or
disapprove it.
You may come from a country where copyrights are not
strongly enforced and feel the above is not important to you. However, our
company is based in the United States, where violating a copyright can result in
a party being sued, so we take it very seriously. Via many of the international
treaties that the U.S. has with other countries, this can result in you being
sued as well. Regardless…if the buyer reports that you are infringing copyright,
and we confirm it, you will not only lose the project, but can also lose your
account as well. It is in your best interests to take copyrights seriously.
6) DON’T forget to use mediation/arbitration if you need
to.
Some coders are under the false impression that
mediation/arbitration is just for buyers, but that isn’t true.
Mediation/arbitration is designed to protect coders as well. If your buyer is
not responding to your questions on a timely basis, won’t accept your final work
or is getting “out of control”, make sure you contact a Rent a Coder arbitrator.
They are there to help you.
6) DO read and understand your entire contract.
How many times have I heard a coder complaining about a
lost arbitration say “But I didn’t realize I promised to do that! If I had I
never would have done what I did…”, or “Oh, if I had known about that
arbitration rule back then, I would have told you about such and such and that
would have turned the arbitration around…”?
Don’t let this happen to you. It’s crucial that you read
your contract from top to bottom…taking special note of all of the rules of
arbitration. It is located at
