In the nine years we’ve been doing web design & development at Pelago, we’ve encountered just about every type of client you can imagine. But at the end of each project, it’s always the same story. How do we get paid?
To start with, we’ve divided our contracts into two categories; specified development contracts and maintenance contracts. While the former type of contract is designed for larger custom development projects, the maintenance contracts are ideal for sustaining ongoing development relationships with existing clients.
These web maintenance contracts, based on time and materials, help regulate our cash flow and are often useful to kick start a project with a familiar client. Since so few web projects start out with a clear specification of the work involved, this contract becomes a commitment between us and the client. And since we require that the contract be paid entirely up front, our cash flow is regulated because we are no longer at the mercy of collecting delayed payments on invoices.
This website maintenance contract template has solved two of our largest problems as a web design & development agency. a) Billing and getting paid after the project is completed. and b) Helping clients understand that priority treatment comes at a higher cost.
Additionally, it is important to remind the client that we are simply hired labor. We can build the site, we can maintain it, but the responsibility ultimately belongs to the client. This maintenance contract helps reinforce the notion that when the server goes down or an API module becomes deprecated, it’s their responsibility — both the rewards and risks of running an online web site — and not yours. Of course, you’d be glad to help out, for a fee :)
We’ve spent years perfecting this contract and it’s worked quite well for us. So we want you to have it, for free. Go ahead, download the PDF and use it as a template for your web design & development business. It’s a solid legal contract that you can use as is or change up for your specific needs. Either way, you’re getting a great start on entering your next client project.
And if you happen to already be using Intervals online task management software, you will find that these contracts align nicely with our online project workflow. Here is how we usually handle our web maintenance contracts using Intervals:
- Create a project named the same as the maintenance contract, for example, ACME Maintenance 001.
- Enter the rates and terms into the project profile.
- Set the project to alert you at a certain percentage, so you can give the client enough lead time to renew the contract when it comes close to expiring.
- Use the Invoices tab to issue an official invoice to the client
- When payment is received, add that in the project profile, marking the invoice as paid.
- Work away on the project, using Intervals to track your time and budget along the way.
- Enjoy working with a happier client.
thanks for sharing the document, its worth many more than what it is
hi John,
Thanks for making your contract available, it’s a great resource. It’s always helpful to see how other agencies address the issues we grapple with on a day-to-day basis.
Some quick questions:
1) I noticed you only have one ‘rush’ fee. Did you consider escalating the rush fee by delivery goal (for example, $ for 5 day response, $$ for 3 day response, $$$ for next day response)? If so, I’m curious what led you to implement a single rush fee over a multi-tiered approach.
2) What does ‘rush’ actually mean for Pelago – how soon is a rush issue addressed?
3) How do you handle clients who have ’emergency’ issues they want addressed the same day? Specifically:
– do you charge the standard rush fee for same day requests as normal ‘rush’ work?
– do you provide same-day service for all of your clients, or only those on a maintenance plan?
This is most often an issue for us with clients who ‘break’ something, or run into a previously undiscovered defect that for whatever reason manifests itself as a ‘critical’ issue that needs to be addressed immediately.
Thanks again for posting your maintenance plan info, it’s very useful.
Thanks Brandon. Here are some answers for you:
1) A single rush fee is just easier, and 99% of the time it is being used for a same-day deliverable. The rush fee is a way for us to justify delaying other client work so we can focus on this one client for as long as it takes to get their needs met.
2) Most of the time we address it in the same day. It’s usually stuff like “I sent out brochures in the mail today and I just got the comps back from my designer can we get the web site page from the brochure built by tomorrow?” You know the old saying “a lack of preparation on your part does not constitute an emergency on ours”? Well, this is usually the scenario with the rush fee.
3) It’s always the standard rush fee, regardless of how soon they want it. Our only customers not on a maintenance plan are long term development projects, so the rush fee doesn’t really apply to t hem. So yeah, it is only those on the maint plan.
Yes, we often have times where a client breaks something. A third party SEO company will dive in or someone tries to update some HTML. Or, we overwrite their changes because they didn’t notify us about them. And there have been countless “undiscovered defects” that we’ve encountered, hense the no warranty clause in the contract.
Good luck to you!
Thanks for this contract, it solves a few issues our young web development company has had when there are no good technical specifications at the beginning of a project (hence no ability to accurately bid the project). We’ve been looking for some solid examples for pre-paid support or T&M contracts.
I had a few questions:
1. Do you have an updated version of this contract that you would be willing to post or send?
2. When clients come to you with unclear or no technical specs for a project, do you use this contract to act as a paid consultant and help them develop technical specs, and then bid the project at a flat rate?
3. How do you handle flat-rate contracts? That is, how do they differ from maintenance contracts? Notable differences I would see would be:
– warranty
– payment structure
– time frame
– penalties for client delays
Thanks for the info!
Jesse,
Thanks for commenting on our blog. Here are a few answers for you:
1) This version of the contract is up to date. The only thing that ever changes are the pricing tiers and hourly rates, but that is up to how you want to price your business.
2) Yes, we use this contract for clients with no clear direction or technical specs. We ask them to pay a retainer and give them a general estimate of how long it will take to help them define a technical spec. Once that process is complete they have a clear picture of where they are headed and the option to continue with us if they would like.
3) We don’t do flat-rate contracts. We used to when we were first starting out ten years ago but we kept getting screwed by scope creep, client delays, and other unforeseen circumstances. Our larger contract bids are similar to this contract except they are broken down into how many hours we thing the project will require and into phases of the project. We include a margin of error so the client has a pretty accurate idea of how much the project will cost. If issues such as client delays and scope creep do come up, they are easily addressed by billing more hours for the project. It takes some discipline to manage a larger project being billed out on an hourly rate, but it’s far better than doing flat-rate contracts. That we can say confidently from experience.
Thanks for the sample. I charge flat rate for projects and definitely I feel screwed over because the client then continues to request “industry standard”
The work we do is pretty solid however when it doesn’t work like google or doesn’t have a feature twitter has they turn around to me and expect this as a default because of “industry standards” despite the project budget being about $4000.
It really frustrates me and I end up spending many more hours and working at a rate of about $5 because of ridiculous statements such as ‘industry standard’.
I decided to change my strategy and your contract seems great so far. Thanks you for your generousity.
Thanks for sharing. I’ve got question about “response time”, as it is not very clear to me.
Usually response time is understood as time between submiting the request and the moment someone picks it up and deals with it.
You say: “Response time is defined as Pelago’s attention and resources towards the issue, not
completion of the specific issue.”
How does this compare?
Janusz,
They are one and the same. We define “response time” as the amount of time between when we receive the request and when we start dealing with it.
Hope that helps :)
Great contract, thank you for posting it.
Do you service clients who don’t want to sign a contract?
Simon,
We would not ever, under any circumstances, work with a client without a signed contract.
John, would it be possible to post a Word version of the document?
Nevermind, the document is easily opened/edited with Adobe Acrobat, which can also export the contract nicely.
Wow! Thank you for this really helpful article. Bookmarking this page for sure!