(and why you need your own contract – especially if you’re a volunteer)
I’m on the other side of a situation that went horribly wrong.
This is not the result I want when I build a site. I like to deliver sites that are properly coded, that look great on different screen sizes, that perform well. So if I work for you, I’ll do any revisions your site requires and check that everything is coded properly, that everything works.
My suggestion to anyone who wants to offer their website design and development help pro bono is don’t do it without a contract. If you volunteer on a skills-sharing platform such as Catchafire, for instance, you’re protected by their contract, and their staff will advocate on your behalf. But if you’re working alone, it’s different. You need your own contract.
Even better, don’t work for free. If you’ve spent years learning skills that people pay good money for, you need to be paid. When you offer your work free of charge without a contract, you’re opening yourself up to problems.
The Whys
You’ll want to know if you are working as an independent contractor or commissioned for work-for-hire.
A contract protects you – and the organisation you’re helping – from any misunderstandings. It protects both parties legally.
A good contract spells out the roles and responsibilities of everyone involved, the scope of work, project deliverables and deadlines, project stages (phases), how many revisions are allowed, who owns the intellectual property for the project’s code, how copyright is transferred when the project is finished, when the project is considered finished and when the handover is complete. It outlines what happens if a situation goes south and you need to part ways.
It names the parties involved in the contract and outlines how you’ll work together. If new parties join a project that’s already under way, the contract spells out what happens, how you’ll define roles, and how you’ll proceed.
With website projects, it’s extremely important for one person to be in charge of changes to the website’s code during design and development. If there’s no version control and no single source of truth, you won’t know who’s making changes and when they’re doing it. You won’t know which version of the site is the approved version. Usually the person who’s building the website handles the changes during a revision period. They ask the client for feedback and changes are made based on that.
Once that period is over and site revisions are approved, then copyright is transferred and the site now belongs to the organisation. But if more than one person is editing the site and changing its look and feel before revisions are complete and there’s no communication, that’s asking for a disaster.
From a security point of view, it’s crucial to know who is working on a website and when. If the site is changed and its code is no longer structured properly, then it has to be fixed. This might mean redoing layouts and pages. This will cause delays.
From now on I’ll use Nathan Ingram’s MonsterContracts for WordPress client work. As he explains it, his contracts are “Battle Tested” and “Attorney Analyzed.” So, exactly what I need.
