Let’s face it, most programmers, developers, and coders generally hate thinking about the administrative side of our business. Yet, in order to function, we have to do things like accounting, invoicing, and other soul-crushing administration that keeps us away from our (hopefully much more enjoyable) billable time.
All of those items are fairly non-related to development and can be learned or absorbed by Googling best practices. But, I’ve always felt that the contracts we work under are different in that they should be more specialized to reflect the particulars of our environment.
As such, I spent a good deal of time during my start-up years assembling various legal best practices, language snippets, ideas / opinions of my own, and probably way too much extraneous information into a gigantic magnum-opus of a work contract. (Trust me, I scoured all sorts of source material. I even found a typo in YouTube’s terms and conditions that is still there to this day — a fact I somehow find amusing.)
I’ve come to use my contract as not only a binding document between my company and my clients, but also as an educational tool for clients. So, it’s rather lengthy, but also thorough.
Clients — even sophisticated business CEOs— tend not to understand the nuances of the tech landscape in the same way that programmers do. They say things like they want to “own” every line of code on a web site, not even considering what that means (esp. when, for example, you’re using open-source code libraries and CMSs).
Of course, like so many other programmers, I’m not a lawyer. My contract could be complete junk as far as the law is concerned. I mean, I don’t think it is (and thankfully have no record of court cases to test it!). But, it’s at least backed by tons of research, a fair amount of legal wizardry assimilated via the osmosis of actually having worked on contract law publications, harsh yet constructive feedback from clients who are lawyers, and finally best intentions (with which, admittedly, the road to hell is paved).
Get The Document
📁 You can read (and can freely fork, copy, modify, praise, disparage) the exact document I use at this link. 📁 (No ads / popups / annoying weirdness— just the exact text I use on the page where it lives.)
Notes, Qualifiers, and Disclaimers
Again, I’m not a lawyer. So, if you use this, you’re on your own, just as I am. Most importantly, I consider this to be a living document. When I see things that I feel are a good idea or should be incorporated, I do it. If I make material changes, I do like the big players do and alert my “users” (clients) to such changes. If changes are immaterial, I just make them without alerting anyone. Item #8 explains this approach. That said, I believe the following points are especially discussion-worthy.
General Structure. I’ve tried to model this thing according to common structurings of legal contracts. Hopefully, it contains all of the necessary sections or points that contracts need in order to be binding.
Section 1: Term. I thought a lot about this one, as most contract have a term. Programmers like boundaries, but they also like dynamic scenarios. So, what I did was to say that the relationship lasts for one year, and after that any work we do is considered an extension of this. Seems reasonable to me.
Section 2: Duties. This is where the scope and timing lives. It’s where I outline what work will be done, and by when. Then I pop it into this area. For larger projects, this can get lengthy. Or, it can be as short as “Provide ongoing consulting as assigned.” Either way, works well.
Section 3: Fees. This is probably something you’ll want to customize a lot, as it reflects my own processes a good bit w/ respect to web site development in particular. But, give this one a good read, as it incorporates considerable thought and best practices. Nothing lives in this document by default — details like specifying that the amounts are in U.S. dollars are actually purposefully included.
Also, note that I don’t always include all of these items in every contract. (For example, if it’s not a flat-fee job, that part doesn’t show to those clients.) What you’re seeing is a page generated to show all possible provisions. I actually coded up a little system to make this all flexible.
Section 4: NDA. I find it’s a best practice to have an NDA provision. Usually, larger clients come to me with this, as well. But, I’ve long felt that the more open and honest a client is with me, the better the success of the project. This article talks more about my oddball opinions here:
Why I’ve Walked Away from $100,000+ in Web Development Work (So Far)_In the web development world, I get a lot of new entrepreneurs approaching me with “the big idea.” Many of these people…_medium.com
Section 5. Here’s an example of what I refer to as client education. Here, I explain to clients a bit more about what they’re agreeing to via the document, and what’s beyond the scope. However, note that this section is highly customized to my own take on how I care to approach things like IP. As a small player, I don’t care to get into the business of managing rights on untold tens of thousands of lines of code across a few hundred clients. Your take may well diverge majorly from this view.
For example, the item under “Code” Acknowledgements →New Code states that “For any new code developed by Consultant … Consultant hereby grants to Client, and Client hereby accepts, an unlimited, unrestricted, royalty-free, fully paid, worldwide and nonexclusive use (unless such rights are specified otherwise within the scope of work).”
This is a handy way of saying “I can do whatever I want with the code, and so can you.” (I think I snagged that language ages ago from an example I saw on BoingBoing, likely posted by Cory Doctorow.)
Note, though that just because I have access to their code (which I wrote), I am still bound by the NDA, and by normal ethics. So, I can’t go giving away competitive secrets or any proprietary information or processes (not that I would!). But, if I’ve written, say, a method to interact with a database, I can reuse that on other client work — just as I’ve likely employed previously learned tools and practices on the current work.
Programmers build skills over time, and I feel we should be free to reuse those skills, so long as we remain ethical. But, perspectives on this item will vary wildly — ranging from provisions that the client “owns” all of the code to provisions that the consultant does and merely licenses it to the client.
I’m not asserting that my take (“I can do whatever with the code, and so can you”) is best — just that it’s what works best for me.
Sections 6–10. These are all fairly boilerplate / routine items you’ll find in most contracts. I’ve customized them as I felt best reflects my business.
Section 11. I think this is key for a development contract, for a few reasons. First, the legal definition of “as is” offers considerable protection to programmers, most of whom represent small businesses. I tried to think of as many worst-case legal damages scenarios as possible for much of that ALL CAPS portion of this, scrabbled together from many example documents I examined. Oddly, none of those included attorney’s fees in this section, so I added that.
Section 12. Just to show an example of the ongoing development of this, I added “flood” just now, after thinking this through with hurricane Harvey having just occurred.
Section 20. As part of my work on a contract law publication years ago, I recall learning that, in order for a contract to be rock-solid, it really should reflect the thoughts of both parties. Many contracts that do not allow for negotiation are apparently found unenforceable — such as when you sign up for a gym or something and have a take-it-or-leave-it contract (aka “contract of adhesion”) to sign. This section, therefore, is where I put provisions that I agree to from the client. Usually it’s things like noting that we have a prior NDA. Other times the client may want something that runs contrary to some of the “boilerplate” provisions in the document. In this case, I would write up those concessions or changes here.
Printing / Signing
Once I write up the particulars for each client (usually the items in the yellow areas), I assign them an access code. They can then access their customized iteration of the contract by using their code on the page you saw when you grabbed the text. From there, we usually have a few back-and-forth sessions until they’re ready to sign.
I only mention that here because I wanted to remind people that you can indeed tailor CSS for print (here’s an old but relevant resource). So, if you went to print the page I’ve shown, you’ll notice that it prints out very nicely.
Feedback Hugely Appreciated!
I’m always on the lookout for improvement suggestions from any viewpoint — legal, other programmers / developers, or just general business feedback. So if you’ve got an idea for improving this document, please comment. I look forward to the continued evolution of this document.
👽 Jim Dee heads up Array Web Development, LLC in Portland, OR. He’s the editor of “Web Designer | Web Developer” magazine and a contributor to many online publications. You can reach him at: Jim [at] ArrayWebDevelopment.com.