In my experience as a freelance developper, I've had some difficulties with clients, whom insist on getting an estimate over flimsy requirements. They then expect me to deal with requirements changes, sometimes late in the project, and stick to that estimate.

Since I've never come up myself with some T.O.S. tailored for this situation, I ended up bound by a contract of a more general nature, which inevitably became unsasatisfactory...

Legal lingo not being my forte, I've been lookin for some publicly released T.O.S. to try to remedy this situation. Ideally these would be from an agile shop, under a licensing scheme allowing derivatives. This would help me lay out the contractual groundwork for a sane customer relationship, especially when dealing with changes.

  • I don't think I quite understand what you're asking. Can you reword/edit your question or add examples to be a bit more clear?
    – Ryan Hayes
    Oct 7, 2010 at 18:07
  • I think he is touching on how to incorporate requirement creep / regular specification changes into contracts for a freelance developer working with clients.
    – Chris
    Oct 7, 2010 at 18:51
  • @Chris: indeed, sorry if my question is poorly worded, I'll try to rewrite it.
    – julien
    Oct 7, 2010 at 19:03

3 Answers 3


Clients wanting you to be agile sounds more like clients that just want to change their mind (which is fine).

It seems like instead of:

  1. Get requirements
  2. Sign the contract with Julien to deliver X for $Y.
  3. Julien delivers X
  4. Julien gets paid Y

They want:

  1. Get very, very vague requirements
  2. Sign the contract with julien to deliver whatever they want (X? Y? X+Y? Z??), which is undetermined, and pay Julien $Y.
  3. Julien works toward ever-changing requirements.
  4. Requirements are never met.
  5. Julien never gets paid because they are never satisfied.

In this case I would simply charge per-hour.

Don't worry about fixed price or an "agile" contract. If you try to re-contract for every change, it will eventually become more pain than it is worth. Your best bet here would be to have a per-hour charge, and have them sign off on timesheets you provide on a per-week or something similar basis. This way both you and they can be as agile as needed while you have a better guarantee of getting paid. Just do great work and any good client will see your value. If not, you're better off just passing on the particular client if you have the opportunity.

For a more Agile approach..

You could, essentially, have a shorter estimate contract per-iteration. Each 2-week (or whatever time) iteration that you plan, have a shorter contract/amendment that outlines the requirements and estimates just for that iteration. Let the client change requirements, but only give them that luxury at the end of each iteration when you do the planning for the next iteration.

  • You pinpointed what's happened a couple of times, except I got paid, by working long hours on those requirements changes. The hourly fee seems indeed logical in these situations, but since the clients insist on getting estimates, I still need some contractual basis to reflect the fact that the estimate will not reflect the actual cost of the project due to flimsy requirements.
    – julien
    Oct 7, 2010 at 19:02
  • 1
    Have you tried giving an estimate of X dollars, plus or minus something like 15%? That way, if the project takes longer, you get paid an additional amount. Oct 7, 2010 at 22:15
  • @Jon That's a good idea.
    – Ryan Hayes
    Oct 8, 2010 at 0:51
  • While this answer is very sound, I'm still hoping for something more akin to legal terms which you could actually base a contract on.
    – julien
    Oct 8, 2010 at 17:08

Agile Team & Fixed Price Contract: http://www.infoq.com/articles/agile-team-fixed-price-contract

Fixed price contracts are evil - this is what can often be heard from agilists. On the other hand those contracts are reality which many agile teams have to face. But what if we try to tame it instead of fighting against it? How can a company execute this kind of contract using agile practices to achieve better results with lower risk? This article will try to answer those questions.


At a previous company that I worked for, we ran into this issue when delivering websites with lots of custom functionality. It sounds to me like you're suffering from client based scope-creep.

To handle this, we started aligning our own personal development benchmark with sample deliverable benchmarks to make sure that the client was satisfied with the way things were progressing. In addition, as Chris mentions in his post, contracts / T.O.S documents were written up and signed in person that explicitly stated what was included with each project and divided up into a per-benchmark basis. Each item was listed out with what it did and did not do, to the best of our abilities without being clairvoyant.

Be upfront about your charges and let them know what an initial estimate would be (which is your responsibility) but also give them the "additional rate", whether you determine it to be hourly or contract additions. When they start scope-creeping you, you can fall back to the initial contract which has that laid out and simply state your new estimate.

To summarize: All functionality described in contract, supply benchmark samples when applicable and get sign-offs on those too, be up front about additional rates for scope creep items.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.