Open source freelance contracts that work for humans

Aug 2018

At the co-op consultancy we use two legal documents for client work: a statement of work that says what we’re going to do, and a contract that covers all the other complications inherent in any business deal.

Here they are:

• Statement of Work
• Contract

First thing to note: if they’re ever used in court, we’ve already failed. Most freelance gigs aren’t worth the cost and time of taking them through an actual breach of contract lawsuit, even in small claims court. Their primary utility is to set expectations so that nobody ever feels like they’ve gotten screwed. Instead, we can have reasonable dialogue about scope and cost during the project.

For the most part, these documents are pretty standard - liability, termination, ownership, confidentiality, and all the good stuff that real lawyers need on a contract so they can sleep at night. There are a few unique features that are a product of the way we structure deals, and if you’re going to use these documents you should be aware of them. They’re both in Section 2 of the contract.

Milestone payments: our clients don’t pay at all until they’ve approved a milestone. Then we issue an invoice, get paid, and deliver the code/assets/whatever that milestone’s artifact is. This works for us because our clients all come through referrals, and we vet them thoroughly enough that we’ve never had an issue. Your mileage may vary - if you’re working with strangers, you may want to add the following to that “Compensation” clause:

Client shall deposit 20% of the full project estimate,
as indicated in SOW, in advance of project start.
This deposit shall be credited on milestone invoices
until depleted.

Then you’re covered for a fifth of the project in advance, and if the client decides not to cough up for a milestone, you haven’t lost out too much.

Capped hourly rate: the actual invoice that’s issued for a completed milestone is a factor of the hourly rates of the members who produced it. We make estimates on the SOW, but they’re just guideposts. However, there needs to be an incentive for us to make good estimates, and it’s reasonable for a client to want protection against cost overruns - so we cap the invoice for any given milestone to within 20% of the milestone estimate. If it starts to go beyond that threshold, then we stop work and have a conversation with the client. This situation is almost always due to a change of scope that the client is fully on board with, but it’s good to have a contractual obligation to stop and say, “OK, but you realize that will cost more, right?”

The SOW is pretty self-explanatory and typically runs about three pages once filled out. The first section outlines the conditions for a successful project in broad strokes, givens and specifications describe actual components in detail, and the deliverables table lays out a milestone schedule and cost estimates. We also include our payment terms on the SOW, since that’s the document the client will actually read.

It’s worked out pretty well for us so far. If you use these documents in a project, let me know! I’d love to hear how they worked for you.