Online form for programming contractor's contract?

August 9, 2004 3:06 PM

IndependentContractorFilter: So I've landed a gig doing some contract programming, except we don't actually have a signed contract yet. Before I sink any more time (existing time being this afternoon) into it, and before I deliver anything, I want one, obviously. Does anyone know of any example programming contracts online I can crib from? All the obvious search words are so over-represented on the Web that my Google results are uselessly noisy.
posted by Zed_Lopez to work & money (5 comments total)

Search for "Statement of Work" or SOW. Another document to search on is "Request for Proposals" (RFP) and "Request for Quotation" (RFQ), which is the sort of document you'd expect from the client outlining what they'd expect and how soon they expect it. Your response to the RFQ is a SOW which includes the features you'll deliver, the schedule, and how much money you want for it. Basic Google-fu will turn up lots of examples of these documents. Good luck!
posted by Voivod at 3:59 PM on August 9, 2004

I'm no lawyer, but I do a lot of contract work and have been through this more times than I care to think about.

Your answer depends on who you're working for.

If they're an established company, who hire contractors frequently, then they'll almost certainly have a standard contract (as well as, almost always, a non-disclosure agreement or "NDA") which they'll want you to fill in the blanks and sign. These range from innocuous to completely insane, depending on how bloodthirsty the company's legal department is -- read them carefully, and don't be afraid to ask for changes if you see something that makes you uncomfortable. The really awful ones are just there to make sure you're paying attention, I think.

My practice with smaller organizations who don't already have a process in place, is to forget the legalese and write up a simple description of the work to be performed, and the timeframe, in plain english. Which, if we ended up in court, might not be the best situation... but the amounts involved at that level are usually small enough that it wouldn't be worth going to court over anyway -- and I've found that people tend to be willing to agree to a lot more if it's in english than if it's whereas the party of the first part etc etc.

Some things to watch out for:
* If at all possible, agree on an hourly rate instead of a contracted fixed amount. Things always take longer than you expect, and if the client knows he's paying the same amount no matter how much work you do, then you'll be asked to do a lot more revisions than if you're being paid by the hour. You'll also have to spend a lot more time arguing about what's in scope and what's not.

* If you have to have a fixed-amount contract, be very, very specific about exactly what work will be performed, the number of rounds of changes that will be included, and have an approval schedule at every stage. State loud and clear than any work beyond the scope of what's specifically described will cost extra, that any changes to work previously completed and approved will cost extra, etc. State how much extra it will cost. (and this bit must be an hourly rate.)

You'll still have arguments and feature creep no matter what you do, but the more specific you can be up front, the better for everyone. The ideal case is when you can break the job up into lots of discrete separate jobs: put a price and an approval schedule on each one, and make it clear that once each component is approved, you won't be going back to change it.

* All approvals to be in writing. Can't emphasize this enough. "Yeah, that looks great" over the phone will be forgotten a month later when they want you to turn it upside down and paint it blue.

* Your price should include more than just hours spent coding. Meetings. Phone calls. Testing. Debugging. Tweaking their server to figure out why the thing you wrote that should work fine, doesn't work fine. Documentation. Picking the smart quotes out of the word doc they want pasted into the welcome screen. Whatever. They don't each have to be separate line items in the contract, but all that stuff is work, and you should get paid for it; pad them into the other line items if you need to.

* If there's a strict schedule, and your work depends on them providing you certain content or other code or information, make sure their deadline for providing you that stuff is included in the schedule. You don't want to be on the hook for their slips.

* Will you be responsible for maintenance after whatever you're building is finished? If not, get it in writing, or you'll keep getting calls months after you think you're done. And they'll blame you when the database they forgot to back up crashes next year.

* Who owns the code after it's done? If it's "work for hire", they do, end of story. (And if it's a large company, then it will be work for hire, guaranteed.) And usually that's fine. But if they don't push that angle, consider whether you want to retain the right to resell the code to others, or to prevent them from doing the same. This one can be touchy, and it's usually not worth pushing for -- but in some cases it's worth doing, if only as a negotiating tactic, something you can drop in exchange for something else you really do care about.
posted by ook at 8:14 PM on August 9, 2004

If they resist the idea of a contract you might point out that, as an independent contractor, the copyright in anything you program for them remains with you and in order for the work to be considered a work-for-hire (meaning the copyright is owned by the employer) there must be a written contract and it must be signed before the work in question takes place.

(IANAL and I'm too lazy to Google for the reference or pull my USC 17 off the shelf — there's a good article on Findlaw about this.)
posted by IshmaelGraves at 9:53 PM on August 9, 2004

IANAL, but I am occassionally a programmer. Contracts are just like computer programs, except they both govern and are executed by humans. Write down what you want your contract to specify in a logical manner. Then group relevant sections together so it has simple flow. The idea is to make the contract DEAD EASY for someone not in your industry (ie, a judge and jurry) to understand. Contract negotiation is more tricky than simply writing the contract.

Section 1, overview:
Contract to govern project XXXX, "the project". <Name of Client's company> doing business at <client's address>, "the client," agrees to contract <name of your development company> doing business at <your address> to develop the project.

Section 2, client requirements
The client requires of the developer the following
*<client request 1>
*<client request 2>
*<client request 3>

Section 3, developer requirements
The developer require of the client the following
*<developer request 1>
*<developer request 2>
*<developer request 3>

Section 4, payment
*<payment clause 1>
*<payment clause 2>
*<payment clause 3>

Section 5, governing law
*This contract is governed by the laws of Antarctica, except for the Section 5.(b).3 which specifies contractual obligations regarding tripple-dog-dares and frozen flagpoles.

Section 6, termination
*<termination requirement or consequence 1>
*<termination requirement or consequence 2>
*<termination requirement or consequence 3>

SIGNED BY

THE CLIENT
_________

THE DEVELOPER
__________

DATE
________

WITENESS
________
posted by Kwantsar at 11:22 PM on August 9, 2004

Thanks for your help, everyone.
posted by Zed_Lopez at 9:25 AM on August 10, 2004