The Perfect Web Design Contract

Recently I left the “day job” and am now pursuing other projects including my new role at 88mph.

I have worked for myself before and have the majority of the necessary things in place like accountants, bank accounts, invoicing and time tracking apps. The one thing I need to revisit is a standard contract of work relating to web design and/or development. My previous one is sadly lacking and out of date.

I have a good idea about the types of things I need to include such as paying a deposit, costs, agreed delivery dates, final payment terms, what happens if the scope of the work changes, bug fixing, browser support, on-going support and hours of service.

I also want the document to be easy to read and no more than a couple of pages, any longer and I always feel clients get put off. I would love to learn what you think makes the “perfect web design and development contract”.

If you are willing to share your own, minus any obvious specifics I would love to hear from you. You can always e-mail me them to or just leave your your pearls of wisdom in the comments. Thanks.


Hi Keir.

You should check out Andy Clarke’s “Contract Killer”:

Hey Tom – Great shout. I remember this from a while ago now that you mention it. Thanks for reminding me.

I’ve got the stuff you’ve covered above, but I’ve also got:
– rough explanation of what the project entails
– what happens if they use Typekit excessively (in case I’m hosting their fonts off my account.)
– explaining copyright and how if they provide me with content, it must be something they’ve ensured they’re allowed to use
– a part saying I will likely use the work in my portfolio, blog etc.

and, of course, the very important line “I am sure you understand how important it is as a one-girl band that you pay the invoices that I send you promptly. If you don’t pay I can’t eat!”

Hey Laura, Firstly I love the last one. I am sure that applies to the majority of us.

Great other points too. Hadn’t considered the hosted fonts one but it’s certainly one to put in.

The portfolio issue is something we have talked about a lot. It’s often hard to put “development” work in your portfolio as it is often with an agency who are outsourcing. Often they will ask for you to explicitly not include screen grabs or logos as they argue it is misleading to say those “brands” are your clients. It’s a tricky one sadly. More often than not a developers portfolio is pretty baron!


You make a great point about developer portfolios. Often we’re one step away from the actual client, but on the other hand often you’re working on something that looks so terrible it would dog a portfolio; despite the fact that the design is irrelevant, humans are visual beings and judgements will be made.

As a developer, I think portfolios just don’t make sense… the best you can do is put interesting code out into the ether, so make sure you have the right to use & publish code that you write in your client work.

Hey Kelvin, Thanks for the comment.

You too raise a really interesting point, that of how can a developer (either freelancers or small agencies) really show they know what they are talking about. Releasing code is a great way to do this for sure. I think it was Joe Stump who said something along the lines of “when hiring a new developer I look them up on GitHub to see what they have released, if there’s nothing there they won’t even get an interview”.

One we often discuss is back to basics blogging. Talking about the technology you use, the good, the bad, the ugly, how you are solving problems, ways of working etc. The hope being that new clients will read your posts and appreciate your expertise. Perhaps speaking at conferences and training would also lend gravitas. Interesting problem!