How a developer should review a converted Framer project

Review a converted Framer project the way you'd review any inherited codebase, with one difference: you have the live site to compare against. Start with a clean install and a production build, then check types, read the conversion notices, audit dependencies and third-party scripts, configure and test forms, check the SEO files, and finally compare every route at three widths against the published site. Expect a readable React and TypeScript project, close to the original but not guaranteed to be identical.

This guide assumes the project came from Deframer, which converts a published Framer site to Next.js (the default), TanStack Start, Astro, React Router or Vite. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer. It's meant for sites you own or have permission to convert.

What should you expect to find?

Knowing what's normal makes the review faster. A converted project has:

• One route per URL, with that page's metadata. In Next.js, src/app/**/page.tsx files are short and render a view from src/views.
• React components with CSS modules in src/components, in the designer's folders, with readable variant names.
• Colour styles as CSS variables in src/styles/tokens.ts, text styles as classes, @font-face rules per family.
• CMS collections as a schema and JSON records in src/cms.
• The site's own code components and overrides in src/code, marketplace components as source in src/vendor.
• A small kit in src/lib/deframer that replaces Framer's runtime. There is no Framer runtime in the project.
• A README with every route and a "Where to edit" table.

The folder-by-folder tour is in what you get in a converted Next.js project.

Step 1: Baseline commit, clean install, production build

Commit the download untouched so every later change is a diff. Then:

npm install
npm run build

Use the Node.js version the project needs: 20.9 or later for Next.js 16, 22.18 or later for TanStack Start, Astro and the Vite build, 22.22 or later for React Router 8. A failed build at this point is information, not a verdict; common conversion issues lists the usual causes.

Dependencies are pinned to exact versions in package.json. Keep them pinned for the review so you're testing what was generated, and update later on a branch of its own.

Step 2: Types

Run the type checker directly:

npx tsc --noEmit

If the site has code components written in Framer, next.config.ts keeps typescript: { ignoreBuildErrors: true } with a comment explaining why. Framer's editor never type-checked that code, so errors in src/code and src/vendor are expected. Record the count, then decide whether to fix them before launch or tighten gradually; code components and overrides in Next.js describes both paths. A project without code components builds with the type check on.

Step 3: Read the conversion notices

The result page lists notices: assets that couldn't be downloaded, components that render only in the browser, redirects that weren't carried over. Ask whoever converted the site for them; they belong in the handoff note. Each one points at a file or a URL. Turn each into an issue or an explicit "accepted".

Step 4: Dependencies and vendored code

Read package.json. Expect the framework, react, react-dom, motion and whatever npm packages the site's own code imported. Then:

npm ls --depth=0
npm audit

src/vendor holds code the site loaded from outside the project, copied in so nothing is fetched at runtime. Review it as third-party code: know what each module is, and note its source if it has a license header. Anything your team wouldn't have chosen is a candidate for replacement later, not a blocker now.

Step 5: Third-party scripts and custom code

Framer's site-level Custom Code (head and body) is carried into the root layout, so analytics tags, chat widgets, consent tools and pixels keep running. Find them in src/app/layout.tsx (or the framework's equivalent document) and list each one with its owner. Questions to settle:

• Is each script still wanted?
• Does each have a consent requirement? See cookie consent after leaving Framer.
• Will a Content Security Policy need to allow it? See security headers for a self-hosted Framer site.

The Deframer verification tag is stripped from the project, so you won't find it here.

Step 6: Forms

Every native Framer form becomes an API route (in Next.js, src/app/api/forms/<form>/route.ts) that delegates to src/lib/forms.ts, which applies a rate limit, a honeypot and field checks, then delivers to a webhook. Copy .env.example to .env.local, set FORMS_WEBHOOK_URL or the per-form variable, and send a real submission. Without a webhook, submissions are only logged by the server. A Vite project has no server, so its forms post to the form service in VITE_FORM_ENDPOINT, or to Netlify Forms. Migrating Framer forms covers delivery and spam.

Step 7: URLs, redirects and SEO files

Check how URLs behave before anything else touches routing:

• src/proxy.ts gives each page the URL form the site publishes (with or without a trailing slash) and redirects the other with a 308. Redirects from the published site are in next.config.ts.
• public/robots.txt and public/sitemap.xml are copies of what the site published. They name the current domain.
• The root layout's metadataBase is the published URL. Change it when the domain changes.

Try a handful of URLs with curl -I against the production build: the home page, a CMS detail page, a URL with and without a trailing slash, an old redirected URL and a missing page, which should return 404.

Step 8: Visual comparison

Open every route in the README's routes table at about 1440, 768 and 390 pixels wide, next to the live site. Breakpoints are separate layouts per variant, so a page can be right on desktop and off on phone. If live previews are on, the compare view does this side by side; otherwise run the project locally. For anything you'll maintain, automate it: visual regression tests with Playwright shows how to use the live site as the baseline. Known causes of differences are in fixing layout differences.

Step 9: Performance and accessibility, once

Run a Lighthouse or PageSpeed Insights pass on the production build. Note that next.config.ts sets images: { unoptimized: true }, so images are served as they are; that's a deliberate starting point, and performance tuning covers what to change. Run an automated accessibility check too, using the accessibility audit as a guide. Record the numbers so later changes can be compared.

A review template

Paste this into the review issue and fill it in.

What not to do in the review

• Don't refactor while reviewing. Renaming folders or converting CSS modules to another approach mixes judgement calls with findings. Do it later, on its own branch.
• Don't remove the kit. src/lib/deframer plays animations, variants, breakpoints and routing for the generated code. You can change it, but read what imports it first.
• Don't upgrade everything at once. Update dependencies in a separate pull request, after the baseline works.