billable.devWebsite Maintenance Retainers: Pricing and Invoicing
By Mark Fulton · 2026-09-04 · 12 min read
Price a website maintenance retainer from your own numbers, not from somebody else's pricing page. List the tasks you will actually perform every month, estimate the hours each one takes when nothing goes wrong, multiply the total by your hourly rate, then round up. Do that three times, at three levels of coverage, and you have three tiers. Write down what the plan does not cover in the same breath, because an undefined maintenance plan turns into unpaid development work within about two months. Then invoice the plan on the same date every month, in advance, with one line item naming the tier and the period, and a separate line for anything that fell outside it.
Published price bands for maintenance plans are everywhere, and they are close to useless for a solo developer trying to set a price. They are averages of businesses with different cost structures, different stacks and different definitions of the word maintenance. Some of those plans are a cron job and an automated report. Some are a named engineer answering the phone. Copying a number off a page like that tells you nothing about whether the work is profitable for you, at your rate, with your clients.
The way out is to build the price up from the work, then sanity check it against the market rather than the other way around.
What belongs in a maintenance package?
Split the candidate tasks into two piles: work that happens whether or not the client asks, and work the client requests. Only the first pile is genuinely maintenance. The second is a service pool you are attaching to it, and it needs a ceiling.
The recurring pile, for a typical business site:
- Dependency and platform updates. The mechanical work, plus the part that actually takes the time, which is checking that nothing broke afterwards.
- Backup verification. Not "backups are enabled". Restoring one backup somewhere and confirming the site comes up. A backup nobody has restored is a hypothesis.
- Uptime and error monitoring. Reviewing what the monitor caught, not just having a monitor.
- A written status note. Short, monthly, in the client's inbox. This is the item that makes the invoice feel earned in a month where nothing broke.
How heavy the update work is depends entirely on the stack, and it is worth being honest with yourself about the real cadence before you price it. On WordPress, minor and security releases have applied automatically in the background since version 3.7, with major feature releases still requiring a click, so your recurring time goes into verifying rather than applying. A Node application is a different shape of commitment: the Node.js release schedule puts a major version in Current status for six months, and an LTS line typically guarantees critical bug fixes for a total of thirty months, with production applications expected to stay on Active LTS or Maintenance LTS. That is a predictable major upgrade landing inside any multi-year retainer, and it should be priced in rather than discovered.
This is also the honest argument for the plan existing at all. CISA's guidance on patches and software updates frames prompt patching as basic security hygiene rather than an optional extra. A client who declines maintenance is not saving money, they are choosing to run unpatched software until something forces the issue, usually at a worse moment and a higher price.
The requested pile is where scope goes to die: content changes, small design tweaks, "can you just add a field to the form". Include a fixed pool of hours for it, name the number, and be specific that unused hours do not roll over. That clause is what stops a client banking six months of unused time and then presenting you with a thirty hour invoice in March.
How do you price three tiers from your hourly rate?
Build a table. Tasks down the side, tiers across the top, hours in the cells. Total the hours, multiply by your rate, round up.
Below is a worked example. The hours and the rate in this table are illustrative inputs I picked to show the method. They are not market data and they are not a recommendation. The $95 rate is the placeholder Billable ships with, and the hour estimates are deliberately conservative, which is the point: they are what these tasks take in a month when nothing goes wrong.
| Task | Essential | Standard | Priority |
|---|---|---|---|
| Dependency and platform updates, applied and smoke tested | 1.0 | 1.25 | 1.5 |
| Backup verified by restoring one to staging | 0.25 | 0.25 | 0.5 |
| Uptime and error log review | 0.25 | 0.5 | 0.5 |
| Written monthly status note | 0.25 | 0.25 | 0.25 |
| Pool for small fixes and content changes | 1.5 | 2.0 | |
| Performance and Core Web Vitals check | 0.5 | 0.5 | |
| Staging environment kept in sync with production | 0.5 | ||
| Major version upgrade work, spread across the year | 1.0 | ||
| Thirty minute monthly call | 0.5 | ||
| Hours per month | 1.75 | 4.25 | 7.25 |
| At $95 per hour | $166.25 | $403.75 | $688.75 |
| Rounded package price | $175 | $400 | $700 |
Now the version you fill in. Copy this, put your own tasks in the left column and your own rate in the multiplier row.
| Task | Tier 1 hours | Tier 2 hours | Tier 3 hours |
|---|---|---|---|
| Hours per month | |||
| At $______ per hour | |||
| Rounded package price |
Four things about how that math behaves.
Round up, never down. The computed figure assumes a clean month. Some months are not clean, and the retainer price is fixed while your effort is not. Rounding $403.75 down to $400 rather than up to $425 is a decision to absorb variance yourself. That is fine at the low tier and expensive at the high one.
The gaps between tiers should be obvious. In the example, the jump from Essential to Standard is not a slightly bigger number, it is the arrival of a fix pool and a performance check. If a client cannot tell you in one sentence what the next tier buys, the tiers are decoration and everyone will pick the cheapest.
Spread the lumpy work. A major framework upgrade is not a monthly task, but it is a real cost inside a twelve month plan. Estimating it annually and dividing by twelve keeps the price steady and keeps you from resenting the month it lands.
The bottom tier is allowed to be small. A genuinely thin plan at a genuinely low price is a fine product, as long as its boundaries are explicit. It is also the easiest thing to sell to a client who has never bought maintenance before, and the natural on ramp to the tier above. If you have not settled your underlying number yet, how to set your freelance developer hourly rate is the input this whole table depends on.
What stays explicitly out of plan?
Write the exclusions into the agreement with the same care as the inclusions. A maintenance plan without a written boundary quietly becomes a subscription to your availability, priced as if it were a patching service.
The exclusions that matter most:
- New features and new pages. Anything that adds capability rather than preserving it. This is the big one and it needs to be named directly, because "small" is a word clients and developers define very differently.
- Redesigns and rebrands. Visual overhauls are projects with their own scope, not tweaks.
- Third party service migrations. Moving hosts, swapping payment processors, changing email providers. Each one is a project.
- Work caused by someone else's changes. If a client's marketing agency installs a plugin that breaks checkout, fixing it is billable. Say so before it happens, not after.
- Emergency response outside stated hours, unless the tier explicitly includes it and the price reflects being on call.
- Content writing, SEO campaigns and paid media. Adjacent services that get assumed into maintenance if you leave them unmentioned.
The practical mechanism is a change order: when a request falls outside the plan, you send a short written estimate and the client approves it before work starts. That single habit is what keeps the retainer profitable, and handling scope creep with change orders covers the wording. Nothing here is tax or legal advice, so have a lawyer look at the agreement itself if the contract value justifies it.
How do you invoice maintenance each month?
Invoice in advance, on the same date every cycle, with the period named in the line item.
The shape that causes the fewest questions:
| # | Description | Qty | Rate | Amount |
|---|---|---|---|---|
| 1 | Website maintenance, Standard plan, October 2026 | 1 | $400.00 | $400.00 |
| 2 | Approved change order CO-014, contact form integration, September 2026 | 2.5 | $125.00 | $312.50 |
Line one never moves. That is the entire value of the arrangement to both sides: the client gets a predictable cost, you get predictable revenue, and neither of you renegotiates it every thirty days. Line two is the out of plan work, on its own line, labelled with its own period and its change order reference so the client can match it to the approval they already gave.
A few mechanics that prevent the common problems:
- Keep the invoice numbers sequential. Recurring invoices for the same amount look like duplicate submissions to automated payables systems, and a clean sequence resolves that flag in seconds. The invoice numbering system for freelancers post covers a scheme that survives a few years of monthly billing.
- Use short terms on the retainer line. There is no delivery to verify on advance billing, so due on receipt or Net 7 is defensible. Longer terms, late fees and deposits are covered in getting paid on time.
- Do not itemise the routine work every month. The tier name is the line item. Itemising invites the client to price each task individually, which is the argument you set up a retainer to avoid.
- Put the proof in the status note, not the invoice. The monthly note is where you say what was updated and what was caught. Keep the two documents separate.
You can build this invoice now in the free invoice generator and save it. Saving and duplicating are free, and the whole thing runs in your browser with no account. If you want next month's copy to arrive with its issue and due dates already advanced and a fresh number assigned, that is Billable Pro, at $4 a month billed $24 every six months, or $79 once. The broader mechanics of billing a retainer, including block of hours versus access models and how to show drawdown, are in how to invoice retainer clients, and there is a ready made retainer invoice template if you want a starting point rather than a blank form.
How do you move a project client onto maintenance?
Sell it before the project ends, not after. Once the build is delivered and the final invoice is paid, the client's mental budget for that site closes, and reopening it in February is a cold sale. Two weeks before handover, while they are still actively thinking about the site, it is an obvious continuation.
What actually works:
Put the plan in the original proposal. One paragraph, priced, as the phase after launch. The client has then agreed to the shape of it before there is any pressure attached.
Make the first month concrete. During the handover call, walk them through what will happen in month one specifically: these dependencies are already behind, this backup has never been restored, this error appears in the log eleven times a day. A named list of real findings sells better than a description of a service.
Show the work in month one. This is where the status note earns its place. If your commits are the record of what happened, your git log is already the report, and turning your git log into an invoice shows how to get the month's commits into a document without retyping them. Even on a plan that does not itemise, having that list ready for the one client who asks is worth the two minutes it takes.
Default to the middle tier. Present three, recommend one, and make the recommendation specific to their site. A client asked to choose from three options with no guidance picks the cheapest one and then asks it to behave like the most expensive one.
Frequently asked questions
Monthly or annual billing for maintenance?
Monthly is the easier sell and the safer default, because the commitment is small and the client can leave. Annual billing is better for your cash flow and your planning, and it is reasonable to offer a discount for it, commonly the equivalent of one month free on a twelve month prepay. The risk with annual is that you have collected for work you have not done yet, so be clear in the agreement about what happens if either side cancels partway through. If you are new to the client, run monthly for the first six months and offer the annual option at renewal, once you both know what the site actually costs to look after.
What response time should I promise?
Promise something you can hit on your worst week, not your average one. For a solo developer, next business day acknowledgement on the lower tiers and same business day on the top tier is honest and achievable. Separate acknowledgement from resolution explicitly: you are committing to reply within a window, not to fix an arbitrary problem within it. If a client needs a genuine resolution guarantee covering nights and weekends, that is a different product with a different price, and it is worth saying plainly that it is available rather than quietly failing to deliver it.
How do I bill work beyond the plan?
Estimate it in writing, get approval, then put it on the next monthly invoice as a separate line with its own reference. Do not absorb it silently, because absorbed work teaches the client the boundary is soft, and it will be tested again. Do not stop work and open a negotiation mid task either. Set an overage rate in the agreement, ideally your standard hourly rate rather than a discount, since out of plan work is the unpredictable kind. For anything above a few hours, a short change order beats an hourly overage line, because it gives the client a fixed number to approve.
When should I raise maintenance prices?
On a fixed annual review date, written into the agreement from the start, with at least thirty days notice. Having the date in the contract removes the awkwardness entirely, because the increase becomes a scheduled event rather than a request. Raise on the anniversary even when the relationship is comfortable, especially then, because the plans that go five years without an increase are the ones you eventually resent. If the site has grown since you priced it, more pages, more integrations, more traffic, rebuild the tier table with current hours rather than applying a flat percentage. The hours changed, so the price should follow the hours.