Ask HN: Corp-to-Corp Contract Gotchas
2 comments
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.
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.
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?
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?
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).
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).
This is a great idea, thank you!
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?
Thanks in advance for helping me out!