Retainer invoice template: six lines for legacy sites

The invoice as the smallest readable contract

A small studio we know in Utrecht spent four years sending two-page service agreements to legacy retainer clients. Three pages of preamble, two pages of clauses, a signature block nobody opened after month two. Then they stopped. The thing the client actually read every month, sometimes twice, was the invoice. So they put the contract on the invoice.

Six lines. Retainer fee, included hours, scope, exclusions, standard rate, after-hours rate. PDF, one page, the bottom half is the breakdown of what was billed. The top half is, in effect, the standing terms reprinted every cycle.

This is a perspective post about why that works on a legacy site retainer specifically, and the exact shape of the six lines after two years of iteration.

Why a legacy retainer needs its own template

A retainer on a brand-new build is easy to scope. The codebase is in your head. You know what a minor change costs in time. A retainer on a 2014 WordPress site with eleven inactive plugins, a child theme that overrides functions.php in three places, and a custom post type registered in a must-use plugin nobody documented is not easy to scope.

The honest answer for most legacy retainers is: I will keep this site running and respond when things break, within a defined response window, for a fixed monthly amount. Things that aren't keeping the site running are not in that amount.

The trouble is, that sentence has at least four undefined terms. Running can mean uptime, or it can mean the contact form actually delivers. Respond can mean an email back in two hours, or a fix in two hours. Things that aren't keeping the site running is where the entire dispute lives.

The six-line retainer invoice is the contractual version of that sentence, with the terms defined.

The six lines, line by line

These are the literal labels in the studio's current template:

RETAINER       €X / month, prepaid
INCLUDED       Up to N hours of intervention per calendar month
SCOPE          Keep [domain] resolving, deliverable, patched
EXCLUDED       New features, redesigns, migrations, plugin licensing
STANDARD RATE  €Y / hour, Mon–Fri 09:00–18:00 CET, 30-min minimum
AFTER-HOURS    €Z / hour, all other times, 60-min minimum

RETAINER is the only line that is a number times months. Prepaid matters. A retainer billed in arrears is just a service contract with a slow paydown. Prepaid sets the working relationship: you have been paid to be available, so you are.

INCLUDED is the line that earns the retainer fee. Two hours per month is honest for most legacy WordPress sites that aren't under active attack. Four hours is generous. The number isn't how much work the site needs (impossible to predict), it is how much work you are prepaid for before overage kicks in.

SCOPE is three verbs. Resolving means DNS and the certificate are valid. Deliverable means canonical pages return 200 and forms hit an inbox. Patched means core, parent theme, and active plugins are within one minor version of current, or pinned for a documented reason. Three verbs is enough; more invite arguments about implied verbs.

STANDARD RATE defines time-of-day for billing, not just price. The window matters more than people expect. Mon–Fri 09:00–18:00 CET is unambiguous. Business hours is not.

AFTER-HOURS is the rate for everything outside that window, including bank holidays. The 60-minute minimum is deliberate.

The EXCLUDED line is the contract

The hardest line to write is EXCLUDED, because every exclusion is a small future argument condensed into a word. The studio's current list is: new features, redesigns, migrations, plugin licensing.

New features means anything the site didn't do before. A new contact form field is a new feature. So is a new shortcode, a new page template, a new shipping zone, a new ACF block. Bug-fixing an existing feature is not.

Redesigns covers any change driven by aesthetics rather than function. The client moved a button: in scope (it broke). The client wants the button green: out of scope.

Migrations is the one that surprises people. Moving from PHP 7.4 to 8.2 on the existing host is in scope (it's patching). The PHP supported-versions table makes the patching cadence non-negotiable. Moving the site to a different host, stack, CMS, or domain is a migration and is excluded.

Plugin licensing means: if a paid plugin's license expires, the client renews it. The retainer covers configuring and maintaining the plugin, not paying the vendor. This one prevents a specific recurring conversation.

Pricing the after-hours rate

The standard answer is 1.5x or 2x your day rate. The studio's actual rate, after two years of data, is 2.2x for the first hour and 1.6x for each subsequent hour. The 60-minute minimum applies to the first hour.

The reasoning is structural. The cost of an after-hours call isn't the hour you spend on it. It's the context switch from whatever you were doing (sleep, dinner, a film) and the recovery cost after. A flat 1.5x undercharges for the switch and overcharges for sustained work. A graduated rate prices the friction more honestly.

Two practical effects of this rate. The client thinks twice before sending a 22:00 message that could wait until morning. Not because they are being charged punitively, but because the invoice arrives a week later with a €280 line item and a 90-minute breakdown, and the next request comes during business hours. And the developer answers when the message is urgent, because the rate makes the response worth it. A retainer where the client feels guilty calling at 23:00 isn't a working retainer.

If you want a reference point on what justifies the after-hours rate, the OWASP Top 10 is the shortlist most studios use. If the inbound names one of those categories (we got a phishing email pretending to be us, the login page is throwing weird errors, I see a JS file we didn't deploy), it is an after-hours call.

Two years of running this template

The studio reports three things after running this template for two years across roughly forty retainer clients.

Disputes dropped to near zero, because every dispute now resolves by re-reading the invoice. The client and the developer are looking at the same six lines.

The overage line items got smaller. When the retainer fee, included hours, and overage rate are all printed on the same page, clients self-regulate. They batch requests. They send Wednesday instead of Friday afternoon. They ask is this in scope before sending, not after.

The EXCLUDED line grew by exactly one term per year. Year one added plugin licensing. Year two added third-party API quota overages. Both came from specific arguments. This is the right pace; an EXCLUDED line that grows faster than that is a sign the SCOPE line is wrong.

When we built Pier for editing legacy sites by chat, the part we underestimated most was the audit trail: every change lands in version history with who did it, when, and against which file. That pairs naturally with a six-line invoice, because the is-this-billable question gets answered from timestamps instead of memory.

The smallest thing to do today: open your current retainer template, count the lines, and check whether EXCLUDED is a list of categories or a vague out-of-scope work billed separately. If it is the second, the next dispute is already in your inbox.