Further more, out of experience, especially for bigger projects, taking in freelancers is a very bad idea :
- You lose the knowledge about the project :
- in case of evolution you need to find the same freelancer hoping he/she will be able and have the time to do the job
Only if the hiring party is being cheap and/or is relying on "wishful thinking" documentation (what if one of your in-house devs with a lot of knowledge gets hit by a bus?). A well-run project will have documentation requirements that the freelancer has to implement.
- If there's a problem,
- your own developpers will be pulling out their hair because it's not compliant to their way of working (or worse unreadable spaghetti code)
Why would you pay a freelancer to develop code that isn't compliant to in-house standards?
- no garantees, you've already validated and payed the freelancer, yer on yer own.
need to go on?
And again - why would you hire a freelancer under a contract with no warranty if you feel that is important to your business (because you don't trust your initial validation and acceptance)?
I actually work as a software contractor. My contracts have all kinds of stipulations for the situations mentioned - including an arbitrage and jurisdiction clause. Having a good contract is great for both sides. Don't skimp on it. Clients can be a little intimidated at first (it's not a short document even in draft form) but when they read it they realise that everything that's in there is in there for a reason, and it's really not just to cover my own arse.