Picture the lazy version of a retainer. A developer writes it on one line in an email: “Ten hours a month, same rate, invoiced on the first.” The client says yes within the hour, and everyone feels very professional for roughly three weeks. Then a request lands on day 29 that is really a small project, the client asks what happens to unused hours, and someone wonders whether “ten hours” includes the time spent reading emails.<\/p>\n
None of that was in the one-liner. That’s the job a retainer agreement does, and a one-liner doesn’t do it. Below is the template I’d use today for a web developer retainer, the reasoning behind each clause, and the places where I think most templates online quietly fail the developer.<\/p>\n
I’m not a lawyer, and this isn’t legal advice. Treat the wording as a starting point and get a local professional to read it before you attach your name to it, especially if your client is in another country.<\/p>\n
A retainer can sell three different things, and the agreement should say which one you mean.<\/p>\n
The first is a bank of hours. The client gets a fixed number of hours each month at an agreed rate. This is the easiest to explain and the easiest to argue about, because every hour becomes a unit someone can question.<\/p>\n
The second is availability. The client pays for the right to reach you within a stated response time, whether or not they use it. This is closer to an insurance premium, and it suits maintenance work for a site that mostly runs by itself.<\/p>\n
The third is a defined outcome: for instance, “keep the site patched, backed up and monitored, and fix anything that breaks within one business day”. You’re selling the result and you absorb the variance in hours.<\/p>\n
I lean toward the third for small sites and the first for active product work. The mistake is mixing them without saying so. If the agreement promises a one-day response time and also caps you at ten hours, you’ve written a contract that you’ll break in the first busy month, and the client has no idea.<\/p>\n
If you haven’t already talked through scope with the client, do that before you send anything. My list of discovery call questions<\/a> is what I’d run through first, because half of these clauses get easier to write once you know what the site actually does.<\/p>\n Here is the skeleton. Short on purpose.<\/p>\n Most of that is boilerplate. A few clauses carry all the weight, and those are the ones I’d spend an evening on.<\/p>\n Clause 4 is where the money argument happens. If hours expire, the client feels cheated in quiet months and the developer feels fine. If hours roll over without limit, you can end up owing someone 60 hours at the worst possible moment. I’d pick expiry as the default, and offer a single month of rollover if the client pushes. Whatever you choose, write it down. An unstated rollover rule means the client will assume the generous version.<\/p>\n Clause 5 is the one the day-29 request breaks. Define “small change” with a number, not an adjective. Something like “any single request that I estimate at more than three hours is a project and gets its own quote”. Then the client doesn’t have to argue with your opinion of what “small” means. They can argue with an estimate, which is a much more productive fight.<\/p>\n Approval in writing matters because it protects both sides. An email reply is fine. A verbal “yeah go ahead” on a call is how a retainer becomes unpaid project work.<\/p>\n Month to month with notice is boring and it’s the right answer for most small clients. Long fixed terms scare people off, and a client who can’t leave tends to become a client who resents you. A 30-day notice period gives you time to hand over credentials and documentation, and it gives them time to find someone else without a gap in coverage.<\/p>\n A retainer that depends on you remembering to send an invoice on the first of the month will fail in the month you’re busiest, which is also the month the client most needs the cash flow to be dull and predictable.<\/p>\n If your clients can pay by card, a recurring subscription takes the chasing out of it. Stripe documents the model in its subscriptions overview<\/a>: you create a price, attach the customer, and the billing happens on a schedule without you. For clients who need a proper invoice with a PO number or bank transfer details, Stripe Invoicing<\/a> can generate and send those on a schedule too. Neither is the only option, and I don’t have a stake in the choice. The point is to remove yourself from the loop.<\/p>\n Two things I’d add. First, send the hours report with the invoice, even when the client never asks for it. A short list of what you did builds trust faster than any promise about quality. Second, decide in advance what happens when a payment fails. A sensible default is a reminder at day 7, a pause on non-emergency work at day 14, and a conversation by phone before anything harsher. Write that sequence into clause 2 or a short schedule so it isn’t a personal decision at the worst moment.<\/p>\n Free retainer templates tend to share the same weaknesses.<\/p>\n Many are written for consultants or agencies and talk about “deliverables” and “milestones” in a way that doesn’t fit ongoing maintenance. A retainer is a service relationship, not a project with an end date.<\/p>\n Many bury the response time or skip it. Clients buy retainers because they want to know that someone will pick up the phone. If the agreement doesn’t say how fast, the client will fill in “immediately” in their head.<\/p>\n And some give the developer almost no protection on scope. A line like “ongoing website support” is an invitation. Schedule A should list what is included in plain words, such as plugin and framework updates, uptime monitoring, nightly backups with a monthly restore test, and small content or layout edits. It should also list what is excluded: new features, redesigns, third-party integrations, and anything caused by changes someone else made to the server.<\/p>\n The Freelancers Union<\/a> publishes free resources on contracts and getting paid, and it’s worth a read if you’re newer to this. If you want my view on the broader contract, I wrote up six questions I ask before I sign<\/a>, and most of them apply here too.<\/p>\n Open the last retainer proposal you sent, or the email where you described one, and check it against the skeleton above. Find the three clauses it’s missing. For most people that’s unused hours, the definition of extra work, and the notice period.<\/p>\n Then write Schedule A as two short lists, included and excluded, and send the updated version to your next client before they ask. If you already have clients on a retainer with no written agreement, send them the new one with a short note and offer to talk it through. Nobody has ever been upset to be asked what happens to the unused hours before the answer matters.<\/p>\nThe clauses that matter<\/h2>\n
RETAINER AGREEMENT\n\n1. Services. The Developer will provide the services listed in Schedule A\n (maintenance, updates, monitoring, and small changes) for the Client's\n website at [domain].\n\n2. Monthly fee. The Client will pay [amount] per month, invoiced on the\n [first] of each month, payable within [14] days.\n\n3. Included time. The fee covers up to [N] hours per month. Time is tracked\n in 15-minute increments and reported monthly.\n\n4. Unused time. Unused hours [expire at month end \/ roll over for one month].\n\n5. Extra work. Work beyond Schedule A or beyond [N] hours is quoted\n separately and does not start until the Client approves the quote in writing.\n\n6. Response times. The Developer will acknowledge requests within [1]\n business day. Emergency means the site is down or taking payments\n incorrectly; those requests are handled first.\n\n7. Term and ending. This agreement runs month to month. Either party can end\n it with [30] days written notice.\n\n8. Ownership. The Client owns the work product once the month's invoice is paid.\n The Developer keeps rights to general tools and code not specific to the Client.\n\n9. Liability. The Developer's liability is limited to the fees paid in the\n preceding [3] months.\n<\/code><\/pre>\nUnused hours<\/h3>\n
What counts as extra<\/h3>\n
Ending it<\/h3>\n
Billing it so it actually gets paid<\/h2>\n
Where templates online get it wrong<\/h2>\n
What I’d do this week<\/h2>\n