

Ask HN: Corp-to-Corp Contract Gotchas  - big_data

For the experienced contractors out there who do corp-to-corp deals, either directly with clients or through recruiters, what are some of the contract gotchas that a newbie could avoid?<p>From your experience are there terms you should always ask for? What terms have you accepted and later wished you hadn't? Which ones do you always reject?<p>Thanks in advance for helping me out!
======
kls
I always try to stay time and materials as opposed to fixed bid. If I do fixed
bid and detailed documentation does not exist (AKA I have to document it). I
always have an out clause that a. I get paid time and material for the
documentation work and b. I retain the option of voiding the contract once
documentation is complete and I have a more accurate picture. This way I can
give them the price they are looking for but yet not commit to a situation
that I am going to eat a bunch of free work to pull the project out, you also
have to be very diligent about scope creep with a fixed price contract.

Until you are comfortable,you should stick to time and materials over fixed
bid, they latter can really bite you in the ass if you are not careful. You
should always look at fixed bid like the client saying:

"I want you to build this software that is going to provide me with unlimited
upside profit, but I want to limit you upside profit for building it, but want
you to take all the risk of failure."

You should price a fixed bid accordingly, as you should be compensated for the
client shifting the risk onto you. A lot of new (to freelancing) developers
will basically take their hourly rate, estimate what it will take to build the
project, add some buffer and that is the price they charge. This is a very bad
way of arriving at the price, as it does not take into account the types of
risk involved.

For example things like dependency on client personnel, gaps in schedule and
deadline have to be factored in. Just doubling you rate or worse yet just
charging you rate + buffer without doing proper risk analysis can put you in a
really tight spot.

Start small with fixed bids and work you way up; build a repeatable process
that scales and produces accurate estimate results. Track your (detailed)
estimates and actual times and hone the process until you can get fairly
accurate results. Estimates will never be a precision instrument, but you can
generally get them close enough that you don't get you ass in a sling.

~~~
big_data
Thanks!

This deal would be priced at an hourly rate, and the work driven by the
combination of their internal departmental and project managers. From the
looks of it, they'll create all the requirements and I will code. The gig's
duration is expected to last only to the end of December.

My big concern is any language in the contract that would allow them access to
my other work. I am working on some side projects as well that uses common
technology but is not in the same domain. How have you handled this before?

~~~
kls
BSD license you code. Put a BSD header in all files in the common library. So
long as the license precedes the date of the contract it cannot be argues that
this code is their property as it existed before the contract and is already
bound by the terms of a license that supersedes the contract.

Remember that BSD gives them rights to do as they please with that code
though, they can distribute it sell it, etc. But it is a good license for this
type of work, as they have no real (in business terms) restrictions.

You cannot however add to this library of code while on their engagement
unless expressly permitted by the contract. It is a good idea to lay out what
is in that library in the contract and the kind of items that can be added to
the library while on engagement (e.g just bug fixes or generic routines).

~~~
big_data
This is a great idea, thank you!

------
SHOwnsYou
Don't ever EVER accept a contract for a set monthly amount when the employer
"swears they will only have you working half time"

You will regret it every time.

~~~
big_data
Thanks, I will keep this one in mind.

