An agency workflow for converting client Framer sites

Converting a Framer site with Deframer is free; an agency downloads a client's site as code once the client publishes the agency's Deframer verification code on that site. Publishing the code is the client's permission, and because Deframer checks for it before each new project is downloaded, the client can withdraw that permission by removing it. From there the workflow is simple: convert into a private Next.js App Router and TypeScript project, keep one Git repository per client, and hand the code over with a clear checklist. The Studio pack (30 credits for $100) is sized for studios moving several clients' sites.

This post sets out a repeatable process, from the first conversation with the client to the handover.

Permission comes first

Deframer is only for your own site or a site whose owner has given permission. For an agency, permission isn't a checkbox you tick; it's something the client does.

Every Deframer account has one personal verification code, a one-line meta tag:

<meta name="deframer-verification" content="dfv_…">

The same code works for every site you're allowed to convert. When the client's live site serves your code, Deframer treats that as proof that someone who can publish the site has agreed. Three properties make this fit agency work well:

1. Only someone who can publish the site can add it. A tag on the live page shows control of the site, not just a link to it.
2. It's checked before every new download. If the client removes the tag, further projects of their site can't be downloaded. Consent is ongoing, not a one-time click.
3. It never ships in the project. The converter strips the tag from the converted code.

Deframer is an independent tool, not affiliated with Framer, so permission is agreed between you and your client, not through Framer.

What to send the client

Keep the request short and specific. Something like:

We'd like to move your website to a Next.js project we'll maintain for you. To give us permission, please paste the line below into Framer under Site Settings → Custom Code, at the end of the <head> section, then publish the site. You can remove it once we've downloaded the converted project.

Paste your code under that. You can convert the site and review the result before then, for free. When the client confirms they've published, open the project, choose to download it, and click Check again. The download unlocks once the code is found on the live page. The verification guide covers the usual snags: an unpublished change, the wrong domain, or a cached page.

If you already manage the client's Framer project

Agencies often have publish rights on their clients' projects and could add the tag themselves. Technically that works. Ethically, get the client's agreement in writing first, in the contract or by email. The tag proves you can publish the site; your paperwork should prove you're allowed to move it.

Budgeting credits

Deframer is free to convert; you pay per project you download, not per month: the first download of a converted project uses one credit. The packs are:

The details that matter for planning (all on the pricing page):

• Credits never expire, so unused credits carry over to the next client.
• Converting is free, so you can review a client's converted site before spending anything (in the compare view, when a live preview is available), and a conversion that fails costs nothing.
• Reopening and downloading the same project again are free, and so is comparing it when a live preview is available.
• Every conversion is its own project: converting a republished site makes a new project, and downloading that one uses a credit. Converting the same published version with the same options within 30 minutes returns the same project.

A sensible estimate per client is one credit for the download, plus one more if the client keeps editing in Framer and you need a fresh project before launch. Note the download stays available for 7 days after the conversion finishes, so download the zip promptly and commit it.

One repository per client

Treat each client's project as its own codebase. Mixing clients in one repository makes handover and access control harder later.

unzip acme-site.zip
cd acme-site   # the unzipped project folder
git init
git add .
git commit -m "Initial conversion from Deframer"

The project already includes a .gitignore (covering node_modules, .next, .env*.local and build output) and a README.md with how to run it, the folder tree for this site, a "Where to edit" table and a routes table. That README is a useful handover document in its own right.

Keep the first commit as the untouched conversion. Every change after it, from fixing a notice to swapping a webhook, becomes a reviewable diff. Maintaining a converted site with Git describes how to merge a later re-conversion into the same repository.

Per-client settings

• Forms. If the site has forms, .env.example lists FORMS_WEBHOOK_URL and one FORMS_<FORM>_WEBHOOK_URL per form. Point them at the client's own tools (their CRM, Slack, an automation service), not your agency's.
• Domain. The root layout sets metadataBase to the site's published URL. Change it to the client's production domain if it moves, and update the domain inside public/robots.txt and public/sitemap.xml.
• Hosting. The project is standard Next.js, so it deploys wherever Next.js runs. See deploying to Vercel, Netlify, Cloudflare or Fly.io.

Handover checklist

When the site is live, transfer control cleanly:

1. Repository. Transfer it to the client's organization, or give them admin access, as agreed.
2. Hosting account. Ideally the hosting project lives in the client's account, with their payment method.
3. Environment variables. Document every variable you set and where.
4. Domain and DNS. Confirm the client controls the registrar account.
5. The verification tag. Tell the client they can remove your code from Framer's custom code once conversions are done. It's only needed when you download a new project.
6. Ownership. The client's site's converted code belongs to them; Deframer claims no rights in it. Open-source packages stay under their own licenses. Put who owns what in your contract.

The root layout's first line is a comment, // Converted with Deframer · https://deframer.co, and the README links Deframer. Nothing is visible on the site itself.

Ethics and misuse

The verification step exists to keep conversions with the people who control a site. A few rules worth writing into your studio's process:

• Don't convert a site because it's public. Public isn't permission.
• Don't convert a prospect's site to pitch them unless they have published your code.
• If a site was built from a purchased template, check the template's license terms before reusing it elsewhere.

Each conversion is private to the account that ran it, including its download and, when there is one, its live preview. Site owners who believe their site was converted without permission can report misuse (see the terms); misuse leads to the conversion being deleted and the account suspended.