When do web design contracts do more harm than good?
There’s a general consensus that web design contracts with clients are a good thing.
Unlike many other services, web designers depend on their customers’ input to complete their work.
Traditionally, web designers have submitted a contract along with a proposal of work. It sets out the end deliverable and the responsibilities on either side.
The incentive for web designers is that it can prevent “scope or feature creep” which could leave them out of pocket.
Agile project management challenged this
As the internet emerged developers began to see that setting the scope of projects was often too restrictive.
It led to writing of the Manifesto for Agile Software Development in 2001 which set four values to counter this.
Although it started with software, the agile philosophy has since expanded to the other industries, governments and public organisations to the point where it is now considered the new norm.
It’s estimated that (as of 2021) 86% of software development is being done using agile methodologies and this continues to grow.
The top reasons cited for agile project management is that it can :
- Help manage changing priorities.
- Accelerate software delivery.
- Increase team productivity.
Clearly, plenty of web developers and designers are used to agile working, but I think it fair to say most freelancers implementing solutions like WordPress are not.
“Customer collaboration over contract negotiation”
This is the third of four core agile values. It’s not saying there should be no contracts.
There would be every good reason to formally agree what time and skills are being offered with a Scrum team. Some projects are collaborative to the point where there needs to be some form of profit sharing.
It’s saying only fix in advance what is sensible and collaborate with clients to avoid friction when one side needs to make changes.
In my last video I talked about data-driven design and UX. Although much could be set out as “us and them” tasks, there is a good chance that following the evidence would lead to changes that would be obvious to both parties.
Certainly Agile’s iterative approach makes the most of the internet’s unique ability to give us real time feedback.
But I think the philosophy is far reaching because there is a simple wisdom in the idea of taking baby steps and correcting as you go.
I don’t have a contract
I feel self-conscious saying this because an industry has built up around selling contract solutions to web designers. There are influencers who are quite adamant it is unprofessional not to have one.
What I have instead is some simple terms online that clients have to (tick box) agree to before buying our services.
I cover the two key points of my terms in my initial conversation with clients to make sure we are right for each other:
- Liabilities. I have no control over the website platform I use for clients so I make it clear I am bringing my knowledge and labour to their project. I am not selling a website as an end deliverable.
I’ll do my best to advise on things like accessibility, GDPR and give an expectation over the choice of software, but as much is open to change and opinion I can only attempt to give a balanced summary of my understanding.
- Licensing. We use open source software and royalty free media.
If they want the recommended updates and support on premium software they need to stay on our hosting and care plan or purchase themselves. I give a rough estimate of this.
I cover the pros and cons of WordPress and the sponsor of this blog Beaver Builder.
I explain that we chose Beaver Builder because it was made with agencies in mind. It keeps the client UI simple and stable but developers can extend it with very little risk of things breaking.
The other things in a typical contract I don’t want, because they either limit the scope of a project and will not mitigate personal risks for me.
It doesn’t mean every job I do in the future will not need a contract, but I try to remove as many potential blocks as possible.
If needing a contract I would aim to do it collaboratively as a way of strengthening strategy and working relationships.
I became aware of the concept of web design contracts through two thought leaders with very different ideas.
The first is Andy Clarke and his plain English open source contract called Contract Killer.
Whether this (or for that matter any contract) would stand up legally is probably unknown. Either way, I did not see it communicating what I wanted or representing the priorities of my clients.
The second was Mike Monteiro and his F*ck You, Pay Me talk which was done with his lawyer.
I did not understand it. Long before I knew of agile my instinct was to give estimates and charge upfront where there was risk. I expected client changes and other roadblocks.
Why would I set up a system that risked me not getting paid. Then hire a lawyer to start a relationship assuming no trust and bad faith in order to correct this?
I didn’t have the will or resources to play the “my lawyer is bigger than yours” game. Anecdotally, I’ve heard others say the only clients who refused to sign their web design contracts are lawyers.
I think it’s important to note both of these examples go back to a time before agile was dominant. A time when the web was mostly hand coded brochure sites. In that context, it probably made much more sense to sell the end deliverable.
I’m still not sure why charging upfront for sprints of work is not common. But I can see situations where the commitment of resources is such that to start a project you would need to know it would earn above a certain amount. In some agile contracts if the job is finished before the estimated number of sprints the difference is split.
As Mike Monteiro’s talk focussed on the benefits of having a good lawyer I imagine he would not be a fan of “off the shelf” contracts.
Ready made premium contracts
Let’s imagine we are new to web design.
We have no need for agile project management. We do information or brochure websites. Our clients have no need for marketing strategies. They are leaving it to us to design it. We heard we must have a contract, but the freebies seem too woolly and client’s aren’t paying enough for a lawyer.
We see a post by Joe. He’s raving about how brilliant the new Acme client contract is. He feels more professional and clients have had no issue signing it. Best of all, it got him paid in full when an unreasonable client was refusing and it helped him weed out a problematic client early. Others who bought it recommend it too. It sounds great, but how do we know this isn’t all just confirmation bias?
1. Clients have no issues signing.
Could it be a warning that people are not genuinely committed to the agreement? They met and trusted Joe. He didn’t talk about the contract’s content as this was “off brand” for him. They are busy, but feel (as with most terms) that everyone must sign this and it’s not a problem.
2. The client who refused to pay.
Contracts have a tendency to justify their own existence. Let’s imagine the client does the usual thing of asking for things out of the scope. Joe does not know how to discuss this, but now he can point to the contract. Shocked that Joe has gone all legal on them, the client looks to retaliate similarly. Someone suggested they might be able to get him.
- One of the open source plugins isn’t.
- Another is collecting personal data.
- Some templated elements seem to have retained some rights.
There is probably something, because Joe, like his client, did not get a lawyer in to check the legal situation of his choices . In the end the client decides it is too much work. They write it off rather than have to do the research and go to court.
3. The “red flag” client.
This one reads the contract. It came as a surprise and the tone was not like the affable Joe they had committed to working with. They are disappointed because it took ages to settle on Joe who they thought understood them. What actually worried them was their responsibility to deliver content.
Like many clients they don’t know what was required of them, but not wanting to seem foolish they focus on other things in the hope of removing the need for a contract. Joe, also surprised and defensive, now points out that the contract is for their benefit too. Now feeling patronised the client is out. Joe’s peer group supports him by saying he dodged a bullet.
The Acme contract, like similar products, is for educational purposes only and comes without guarantees. In the right hands and circumstances it could be a very useful cost and time saver. In the wrong hands a potential liability to the business.
Whether you need a contract or not, you’re probably right
All rules are contextual so it’s probably wise to keep asking ourselves whether our contracts or terms are still helping to:
- Produce better work rather than restrict it.
- Improve communication rather than strain relationships.
- Mitigate risks rather than introduce them.
Scope setting contracts are on the decline with the growth of agile projects. Whether that is right for freelancers and small agencies is going to depend on the client and service offered.
Personally, I am moving away from selling websites as a commodity ( I never actually did, but that was the perception) and towards providing a wider service that requires more agility and may even require more contracts.
As always, I would love to hear your thoughts.