Framer to code: when a Framer site needs to grow up

Framer is the fastest way we know for a designer to ship a polished site. That's also why teams outgrow it. The site starts as a launch page, then gets a blog, case studies, docs, three languages, and a pricing page that should read from the billing system.

Where Framer gets tight

• Plans cap pages, CMS items, and locales, so growth turns into upgrades and add-ons
• The CMS suits simple collections, but deep relations and reusable blocks are harder to model
• There's no supported code export, so hosting and performance stay on Framer
• Product features like auth or live data end up as embeds

What moves easily

More than you'd think. Framer code components and overrides are React, so they usually port into a Next.js codebase with small changes. The design is already in components and variants, which map well to a component library.

What needs care

Animation is the part teams worry about most. We rebuild effects with CSS and Motion, the open-source library that grew out of Framer Motion. Most scroll and hover effects carry over closely. A few complex sequences need a rethink, and we'd rather flag those in the assessment than in review.

CMS content needs an export and a new content model. Framer collections are usually simple, so this is a chance to add the structure you were missing, like authors, categories, and SEO fields on every entry.

Designers keep their tool

Moving the live site to code doesn't mean your designer stops using Framer. It's still a great place to explore and prototype. The difference is that new sections get built as components that editors can reuse, so marketing doesn't need the designer for every new page.

Next.js or Astro?

If the site leans on React components and motion, Next.js keeps everything in one model. If it's mostly content, Astro with a few React islands works well too. See Astro vs Next.js for a marketing site.