Maintenance retainers for converted Framer sites

A maintenance retainer for a converted Framer site is a monthly agreement to keep the site's code healthy and to make small changes: dependency and security updates, content edits in code, small design changes, form and uptime checks, and a monthly report. It exists because a site moved off Framer no longer updates itself, and most clients who wanted their code still don't want to run it. Price it from the hours the work takes plus a buffer, not from a list price, and write down what's out of scope.

This guide is for agencies and freelancers who have moved, or will move, a client's Framer site to code. It assumes the client owns the site and gave permission for the conversion; the agency workflow covers that part, and selling a migration covers the pitch. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer.

Why do converted sites need a retainer?

On Framer, the platform runs the site. After converting, the client has a standard project, such as a Next.js 16 App Router app or an Astro site in TypeScript, and with it the jobs Framer used to do invisibly:

• Dependencies (Next.js, React, motion and whatever the site's own code uses) get updates, some of them security fixes.
• Content that was edited in Framer's CMS now lives in JSON files in src/cms/, so each change is a commit and a deploy, unless a headless CMS was added.
• Forms post to the project's own API routes and deliver to a webhook set in environment variables. If the receiving service changes, someone updates the variable.
• Hosting has its own dashboard, usage limits and occasional platform changes.

None of this is much work for a developer. It's a lot for a marketing manager who has never opened a terminal. That gap is the retainer.

What goes in the scope?

Write the scope as a list of recurring tasks with a frequency, then a bank of hours for requests. A typical scope:

Out of scope (write it down)

• Major redesigns and new features (quote them as projects).
• Major framework upgrades, such as a new Next.js major version.
• Third-party service costs: hosting, form services, analytics, a headless CMS.
• Content creation (writing, photography) unless you offer it.

Clear exclusions prevent most retainer disputes.

How to price it

Price from hours. Estimate the recurring tasks for a typical month, add the request bank, add a buffer for surprises, and multiply by your rate. Don't copy someone else's number: rates vary by country, seniority and client size, and nothing in this post should be read as a market rate.

A worksheet:

Three ways to structure it:

1. Fixed monthly fee, fixed hours. Unused hours expire or roll over one month. Simple for both sides.
2. Tiered. A basic tier (updates and checks only) and a tier with a request bank. Lets the client choose.
3. Pay-as-you-go with a minimum. A small monthly minimum for updates, requests billed hourly.

Include conversion refreshes if the client keeps designing in Framer

Some clients keep designing in Framer and want the code copy refreshed after a redesign. Each refresh is a new conversion, merged into the repository on a branch. Converting is free; downloading a new project uses 1 credit with site verification, or nothing with the lifetime deal. Pass the credit cost through or include it, and count the merge time; maintaining a converted site with Git explains the merge. For how credits work across many clients, see Deframer pricing explained.

Running the retainer month to month

A routine that keeps it predictable:

1. First week: update dependencies on a branch, run the build and type check, open a preview deployment, check key pages at desktop, tablet and phone widths, merge.
2. During the month: handle requests from the bank. Each change gets a branch and a preview link for the client to approve. See preview deployments.
3. Monthly check: send a test form submission, look at the host's error logs, confirm the sitemap and robots.txt are served.
4. Report: what was updated, what changed, hours used, anything to plan.

Automated visual checks make step 1 safer on sites with many pages; visual regression tests with Playwright shows a setup.

Make the project easy to hand over

A good retainer doesn't hold the client hostage. Keep the repository in the client's own Git organization (or transfer it on request), keep environment variables documented, and keep the project's README current. The converted project starts with a README listing every route and a "Where to edit" table; add a section for the host and environment. Clients renew retainers they could cancel more readily than ones they feel trapped in.

Who should own what?

A sample scope paragraph

Each month we update the site's dependencies (patch and minor versions), check the production build, test the contact form end to end and review error logs. Up to [N] hours of content edits and small design changes are included; requests are made by email and delivered as a preview link for approval before going live. Major version upgrades, new features and redesigns are quoted separately. Hosting, form and analytics services are billed to the client directly. Unused hours roll over for one month. Either side can end the agreement with 30 days' notice, and the repository and all credentials stay with the client.

Adapt the numbers and terms to your own contracts.