8 ms·
Ask HN: Could you share your general purpose development contracts?
I'm a freelance web developer and I'm planning on putting together a general purpose web development contract for future projects. I was hoping to get a feeling of what I should be covering in the contract. I'd love to make a easy to read, non-legalese contract that covers the basics (payment, ownership, expectations, work hours etc.) which would give a client an introduction to my terms and be tweaked on a per-project basis.
I understand that I/WANAL & YMMV etc. but it would be nice to see what people are using themselves.
- jMyles 12y agoThese days, I usually have a recorded sit-down (in person or over the phone) and discuss very specific details with the client and inform them that this recorded conversation will be the basis for the beginning of an agreement. We then share the recordings with them, along with a written summary of the agreement. Fortunately we've never had to go to court, but I'm told by my lawyers that this will hold up just fine. It also seems to breed a more organic agreement than a sterile, boilerplate contract.
- joe9 12y agoThat's very interesting. Are your clients typically open to this, or do you run into any resistance?
- jMyles 12y agoI haven't yet, but some clients come to me with a contract in hand instead of doing a recording - I surmise these are the ones that are likely to object and I don't usually even ask. Typically, I'll still sign their boilerplate, but I ask that things like NDA, work-for-hire, and non-compete are either eliminated or toned down such as to still clearly permit unmitigated action in the open source space. The last time I did a "recorded contract" was over a year ago, which makes me now feel sheepish about saying "these days." :-) I don't think it will be the last though, and I do highly recommend it.
- raverbashing 12y agoYes, this sounds like a good idea Someone might have an objection to a boilerplate contract and this is always too much of a coming/going between lawyers of both parts. With a personal discussion you can get whatever interests each part and get to an agreement faster.
- alphydan 12y agoHave you tried Docracy? There are a few good examples at: https://www.docracy.com/application/dochome https://www.docracy.com/application/dochome
- rabino 12y agoThis one is really cool http://tri.be/update-the-shane-peter-inc-contract/ http://tri.be/update-the-shane-peter-inc-contract/
- mangoman 12y agoYou should try Shake! http://www.shakelaw.com/legal-info/freelancehire-agreements/ http://www.shakelaw.com/legal-info/freelancehire-agreements/
- jeremymcanally 12y agoThese served me well when I owned a consultancy: http://msabundle.com http://msabundle.com
- joelhooks 12y agoI've also used these quite a bit. They are sufficient for about 50% of clients. The other want to use their boilerplate.
- dkadams 12y agoI use a modified version of Ross Kimbarovsky's Contract from: http://www.crowdspring.com/contracts-for-software-and-website-developers/ http://www.crowdspring.com/contracts-for-software-and-websit... Caveat: I've only used it with one client, with whom I have a prior working relationship.
- deleted 12y ago[deleted]
- brudgers 12y ago[IANAL] I come from a field, AEC, which in the US uses a lot of standard contracts. The AIA contracts, though not the only option, are very common and have been developed over the course of 100 years. The architecture series start with B. These are, in my opinion, a good model for a software consulting project because: + Neither party really knows the full scope of the work when the contract is let. As my mentor Ronn Ginn told me, two people sit down and sign onto something about which neither has much of a clue. This of course emphasizes that an agreement is really a matter of trust not which court to go to. + Client objectives change during the process. The contract reflects it. + Intellectual property rights are clear. The architect retains the copyright. The client is granted license to use it for the purpose of the project. The license is predicated on payment. + Terminating the contract for convenience is a distinct possibility. The contract acknowledges that. + One person is the technical expert. The other party hires them for their judgement. The contract acknowledges that. + Both parties are likely to contract with others during the course of the project [architect with consultants, owner with builders]. The contract acknowledges that and one of the reasons for using standard contracts is because they all fit together. But that's too much to hope for here. The idea of acknowledging the possibility of other contracts and taking them into account is what matters. The short form agreement, AIA B105 currently, B155 previously, is a good place to start. Both use simple plain language and cover most projects. Having written a lot of proposals and contracts over the years, I've learned that selecting clients matters more than what's in the contract. Red flags really are red flags. Good luck.
- Radim 12y agoI don't know what these acronyms mean, but I'd hate NOT being assigned full intellectual property rights, as a client hiring a freelancer. Is that really common in your field? What's your field's price tag between doing full IP assignment vs. a license-only?
- k__ 12y agoIf you create basic CRUD apps it is probably not so common. But for anything more advanced it would be wise to have the option of using the software in other projects to save time and money.
- reboog711 12y agoThe ones I use are on the sidebar of my blog; which I posted in conjunction with an article I wrote ( Deconstructing the Consulting Contract ) for a print publication called Fusion Authority Quarterly Update (FAQU): http://www.jeffryhouser.com/download.cfm/dir/software/file/contracts%2Ezip http://www.jeffryhouser.com/download.cfm/dir/software/file/c... . I do not know if the article is still available anywhere; it is from 2005. [Maybe I should update said documents; but primarily very little has changed] Bigger clients will have their own contracts [and sometimes very little negotiation room]. I've drive some clients crazy w/ negotiations and about what rights I refuse to sign away. Update: Here is the original article I wrote http://www.jeffryhouser.com/enclosures/DeconstructingConsultingContract.pdf http://www.jeffryhouser.com/enclosures/DeconstructingConsult... [I guess it was 2007; not 2005]
- DennisP 12y agoWhat rights do they ask for that you refuse to give away?
- reboog711 12y agoSome of it is covered in the article; for example I once had a prospect want me to sign a web dev firm want a non-complete which said I wouldn't work in any industry they work in. I believe every client I've had before / after would classify. I'm not going to sign away my right to take on clients. I've seen IP ownership clauses that say the client owns everything I create, whether or not it was done for them. These clauses are written in such a way that the client could claim ownership of work I did for other clients, my blog posts, podcasts, books I've written, and even things that have nothing to do with tech, such as songs I've written and/or recorded. I try to make such IP transfer clauses as specific to the work I do for the client as possible.
- IgorPartola 12y agoHere's what I used last time: https://gist.github.com/malarkey/4031110 https://gist.github.com/malarkey/4031110 I like the plain language of it. For me, contracts are a necessity. The way I see it is that people who want to not pay, won't pay. You'd need an army of lawyers to craft a bulletproof general purpose contract. Instead, I go by a mutual understanding sealed by a simple contract. From what I understand, the best tool/weapon you have is a clause that says that copyright assignment from you to them happens upon receipt of full payment. That way you hold their work until you get paid. YMMV and IANAL.
- benjymau5 12y agoI also use Killer Contract, slightly tweaked of course. It's simple, understandable and gives me some leverage when clients don't pay, which happens a lot more often that i would like.
- johnorourke 12y agoI work on small projects (from $5k to $50k) and have no formal contracts. My thinking is that: - the client can afford more expensive lawyers than I can, so regardless of the truth they would be able to wipe me out - if the client has to read the detail of the contract, it's probably too late to save the relationship anyway - maintaining the relationship is everything, being honest and open and striving to maintain a service that is genuinely useful to the client, even if you're not always perfect. I do have a contract with one client but any questions about it have been about the 'spirit' of it, not the detail. Pricing is everything: if you're too cheap, you'll struggle to deliver and will not meet expectations. Too much, and you'll lose out to your competitors.
- dripton 12y agoThat's an interesting angle that I hadn't heard before. I'd still rather have a contract, just to avoid confusion about the terms of the deal.
- ziles88 12y agoGood intentions, terrible advice, sorry. Contracts are not just for 'the courts'. It is a standard business practice of having some clear terms for the both parties. Not only that, but any company who could sue and, 'wipe you out' already has their own contracts and NDAs, you not showing up with one just looks unprofessional. It should be also used as a place to outline your workflow and what the client should expect from you. Clients love this, trust me. To tell new developers that, 'go ahead and put 5K-50K of your earnings on good faith' is just a dangerous thing to say.
- sethrin 12y agoThis is a good idea right up until something goes wrong. The client decides not to pay you -- what do you do? The client asks for revision after revision on a flat-rate job. The client refuses to buy stock photos, or refuses to provide some essential software component. The client insists, years later, that because they changed their requirements, something you did is now a bug, and they insist you fix it for free. You write software library X for a client and then the client sues you for using it in a different project. The client asks for a change verbally, later denies making this request, and insists that you reverse it (for free). I could go on but the point is that there really are some things that aren't covered by a handshake agreement that you really should have nailed down, because you have very limited recourse otherwise. This should include the work to be performed, payment schedule and penalties for late payments (which are generally covered by usury laws, the workaround is often to offer a discount for early payment), what copyrights are transferred and when, responsibilities for providing assets, acceptance criteria, liability for defects, severability, and controlling law. Non exclusive list written from memory, IANALATINLA. Relationships may be important, but that does not mean automatically getting screwed if the client decides to. A well-written contract protects both parties. We need contracts because this isn't a perfect world, things go wrong all the time, and it's very easy to burn relationships unless you both agree about what to do when things go wrong, before the lawyers start getting involved. And again, if it does get to the point where the legal letters start flying, without a contract you are going to be severely limited in terms of recourse. Another way to look at it is that without a contract, you are both taking on risk; the risk of not being paid is probably the biggest factor. If you can avoid a $5k to $50k risk by spending a few hundred dollars, why wouldn't you? If you need more than my words to convince you, I suggest either reading clientsfromhell.net, or watching "Fuck you, pay me." http://vimeo.com/22053820 http://vimeo.com/22053820
- lakesta 12y ago[IANAL] Been using this one for a few years, wrote it with some mates, never had any issues. Attached some design images as well as the text. http://teamgoblin.com/contract.html http://teamgoblin.com/contract.html
- dbeardsl 12y agoMyself and a number of others have used this generic development and design contract: https://github.com/danielbeardsley/service_contracts https://github.com/danielbeardsley/service_contracts I negotiate the terms, make local commits, and include the commit hash on the print-out.
- nickbauman 12y agoWhenever possible, I try to strike Agile Contracts where the client is given control ONE of three levers: The Scope lever (how much will be done). The Time lever (how much time will be spent). The Money lever (how much will the client spend). If you try to give your client more than one of these levers, you're fooling yourselves, because it isn't really possible. Some aspect of the project will suffer in a way that violates the basis of a good business relationship and / or a good outcome. More information on Agile Contracts: http://www.agilecontracts.org/ http://www.agilecontracts.org/
- deleted 12y ago[deleted]
- cweagans 12y agohttps://github.com/cweagans/Contract https://github.com/cweagans/Contract Fork and modify. I accept PRs too ;)