Framer, building sites and the cost of team seats

Framer, building sites and the cost of team seats

Framer is a tool for assembling websites on a canvas, with hosting, a simple content system, and a strong animation set. You design, you publish, and the site runs, with no build step and no deployment.

Before going further, one thing that confuses developers most often. This tool and the animation library that spent years being called Framer Motion, today named Motion, are two different products. The library is a React package you add to your own project. The tool described here is a closed platform where a site lives. Their shared origin means search results mix the two.

What this is good for

Worth naming the right use case, since outside it the tool stops making sense.

A company site, a product site, an event page, or a campaign landing page. The content changes rarely, appearance matters, and the person making changes is often from marketing rather than engineering.

The value lies in the whole chain from idea to published page fitting inside one tool. There is no handoff from design to implementation, no drift between a mockup and the result, no waiting for a deployment. The designer publishes directly.

Beyond that scope the arguments weaken. An application with logins, a dashboard with data, a shop with a thousand products, or anything where logic outweighs appearance requires things this tool does not do, and working around them costs more than building it normally.

Pricing and the line that surprises

There are two paid plans. Basic costs 10 USD a month and Pro costs 30 USD a month, with a free plan on a vendor domain beside them and custom quotes for the largest deployments. The Scale plan was retired in June 2026, so any comparison listing three paid plans is out of date.

The difference between the plans lies less in the size of the limits than in what happens once you pass them. On Basic the limits are fixed; on Pro you buy further batches of pages, entries, and bandwidth at the rates in the table, up to the ceilings written into the plan. Plan prices also rise with the allowance of credits for the AI features, and the pricing page computes those in the browser, so check the rate with the vendor for a larger allowance. The plan price includes 1,000 credits a month on Basic and 3,000 on Pro.

The non obvious line on the bill is people. The workspace owner costs nothing, and so do people who only view and comment, while every additional editor seat is 20 USD a month and a seat limited to the content system is 10 USD a month. Both rates are the same on Basic and on Pro. In June 2026 the full seat price dropped from 40 to 20 dollars, so material predating that quotes double the figures.

The practical effect is that the price shown beside a plan is not the total, yet not everyone on the team raises it either. The designer running the workspace fits inside the plan price, the person checking a page before publication does fine as a viewer and costs nothing, and the person adding entries is 10 dollars. You start paying at the second and further person with full access to the project.

The content limited seat grants access to the content system, localisation, and on page text editing, without the ability to change the design. That is a sensible arrangement on a team where several people add entries while one designs the layout.

One ceiling is easy to forget: on Basic and on Pro at most ten people can hold edit access. A larger team means a custom quote, where the editor count is not capped.

Compute the bill before deciding, since on a team with several people designing, the seat cost can exceed the plan cost, and the comparison against alternatives then comes out entirely differently from comparing plans alone. The figures on the pricing page apply to annual billing, which the vendor bundles with a free domain.

The content system and its limits

The content system lets you define collections, add fields to them, and display entries in a layout designed once. That suffices for a blog, a case study list, a team directory, and similar structures.

The limits surface in three places.

The first is relations between collections. Linking articles to authors and categories works, while a structure with several levels of dependency gets cramped compared with systems built for content, Sanity or Strapi for instance.

The second is scale. A few hundred entries pose no problem; a few thousand start being awkward to manage, and entry limits are part of the plan anyway, so they grow with the bill.

The third is editorial work. Drafts, approval flows, and translations with separate state per language are things editorial teams expect, and here they are simplified.

The practical conclusion: with content as an addition to a site, this suffices. With content as the main product, meaning a site with hundreds of articles and an editorial team, a dedicated content system and a site built on it is right.

Code components, the developer's escape hatch

You can place your own React component on the canvas, and that feature makes this tool interesting to people who write code too.

The component receives properties set in the interface, so a designer can configure it without touching code. That is a sensible route to things the tool does not do out of the box: a calculator, a form with unusual validation, a counter pulling a number from your own interface.

You describe the controls next to the component, and the tool turns them into fields in the panel on the right.

import { addPropertyControls, ControlType } from "framer"

export function Counter(props) {
  return (
    <div>
      <strong>{props.value}</strong> {props.label}
    </div>
  )
}

Counter.defaultProps = { value: 0, label: "users" }

addPropertyControls(Counter, {
  value: { type: ControlType.Number, title: "Value", min: 0 },
  label: { type: ControlType.String, title: "Label" },
})

There are over a dozen control types, covering not only numbers and text but colour, an image with a resolution set, a link, and a dropdown. Reach for the type matching the data rather than dropping a text field everywhere, because that decides whether the designer gets a colour picker or types a hex code from memory.

The limits are clear, though, and worth knowing early. The component runs in the visitor's browser, so anything requiring a secret must go through your server. A service key written into a component is public.

The right arrangement is one where the component knows no key at all and calls only your own address, which adds authentication on its side.

import { useEffect, useState } from "react"

export function OrderCounter() {
  const [count, setCount] = useState<number | null>(null)

  useEffect(() => {
    fetch("https://api.yourcompany.com/public/orders/count")
      .then((r) => r.json())
      .then((d) => setCount(d.count))
      .catch(() => setCount(null))
  }, [])

  return <div>{count === null ? "—" : count}</div>
}

While you are there, handle a failed fetch, because a component rendering nothing on a network error leaves a hole in the layout the visitor can see. A fallback value costs one line and saves the page's appearance in a situation you do not control.

The second limit is maintenance. A code component lives inside the project on that platform rather than in your repository, so it falls out of code review, out of tests, and out of change history. With one simple component that does not hurt; with five it becomes a layer nobody watches.

The third concerns performance. Every component is code shipped to the browser, and a marketing page gets judged partly on load time, so adding them without restraint undermines one of the reasons such a tool gets chosen.

Animations, the reason people choose it

Animations are the differentiator here, and the difference from competitors deserves describing.

Motion is a first class citizen rather than an effect glued onto a finished layout. Transitions between component states, animations tied to scrolling, element entrances as they come into view, and hover reactions all get set in the same place where the layout gets designed.

The practical gain is that a designer reaches a result that in another tool would require handing the task to a developer and several rounds of agreement. A page where something happens in response to scrolling takes an hour rather than two days.

The trap is equally concrete and visible across many sites built with this tool. The ease of adding motion leads to pages where everything slides in, slides out, and reacts, while a visitor waits for elements to settle instead of reading the offer. An animation on the first screen delays the moment content becomes visible, and that is a measurable loss.

A sensible rule reads: keep motion on the first screen minimal or absent, and use it further down to guide the eye rather than to show off. Check the page with the reduced motion setting enabled too, since some visitors have it, and a page designed purely around animation looks incomplete then.

In your own component you can read that setting directly and swap large motion for a plain appearance.

import { motion, useReducedMotion } from "motion/react"

export function Card({ visible, children }) {
  const reduceMotion = useReducedMotion()

  return (
    <motion.div
      animate={{
        opacity: visible ? 1 : 0,
        y: visible || reduceMotion ? 0 : 40,
      }}
    >
      {children}
    </motion.div>
  )
}

Note that with the setting on the element still appears, just without the shift. That is the right resolution: removing the animation entirely can leave a layout where nothing signals a state change, which is not what the setting asks for.

Team work and publishing

A few operational things worth knowing before rolling this out in a company.

Publishing is immediate and on the Basic plan there is no approval stage at all between a change and production. Anybody holding an editor seat changes the live site, which helps with quick fixes and is a risk on a team where somebody experiments. The Pro plan adds a staging environment and branches with their own previews, so only there does publishing become a deliberate step rather than a reflex. If review before release matters to you, that is an argument for the more expensive plan rather than a setting to find.

Change history lets you return to an earlier state, and that safeguard deserves testing before it is needed. Checking how a rollback looks and how many versions back it reaches takes fifteen minutes.

Preview for people outside the project happens through a link, so showing a draft to a client requires no publishing. That is the equivalent of a deployment preview, familiar to teams working from a repository.

A custom domain attaches through a record change and the certificate configures itself. Remember, though, that redirects from old addresses when moving an existing site have to be entered by hand, and skipping them means losing search positions built over years.

The last item is role division. One person designing and several adding content through cheaper seats is an arrangement that works. Several people designing the same page in parallel leads to conflicts the tool does not resolve as well as a version control system.

Framer against the alternatives

The first row wins on time rather than capability. A site that in the second option takes two weeks with a designer and a developer takes three days here with one person. For a company site that difference is real and measurable.

The second wins when the site is meant to grow. The code stays with you, content lives in a system built for content, and performance and optimisation sit under your control rather than a vendor's.

The thing to weigh before deciding is the exit. A site built here does not export as a project to develop elsewhere. Changing tools means rebuilding the site, so a three year choice deserves making deliberately rather than because the first version came together quickly.

Performance and search visibility

Two things technical people ask about, and both have concrete answers.

Pages are rendered statically and served from a content delivery network, so the foundation is sound. Titles, descriptions, friendly addresses, a sitemap, and structured data are available in the interface and require no working around the tool.

The risk sits elsewhere: in what you add. A page with five typefaces, a video background, scroll animations, and three code components loads slowly regardless of how good the infrastructure is. The tool makes adding effects easy, so crossing the line past which load quality metrics start hurting is easy too.

The practical advice is simple: measure the finished page with a performance tool before considering it done. The largest gains usually come from cutting typeface count, replacing a video background with an image, and dropping animations on the first screen.

The measurement runs from the command line, with no account to create anywhere, and takes a minute.

npx lighthouse https://yoursite.com \
  --only-categories=performance,seo \
  --preset=desktop \
  --output=html --output-path=./report.html

Run it twice: once in the desktop variant and once without that switch, meaning under phone emulation, because results can differ by tens of points. A page with a video background and three typefaces scores decently on a fast connection and terribly on a phone, and it is that second figure that matches how most visitors will see the site.

Common mistakes

The first is confusing this tool with the animation library of similar ancestry. They are two different products and one's documentation does not concern the other.

The second is computing the cost from the plan price alone. Editor seats are a separate line and with a small team exceed the plan.

The third is choosing this tool for a site with hundreds of articles. The content system is simplified here, and with content as the main product it starts constraining within months.

The fourth is keeping service keys in code components. The code runs in the visitor's browser, so everything in it is public.

The fifth is adding effects without measuring. Animations and video backgrounds spoil load time faster than the impression while viewing suggests.

The sixth is not checking the exit path. A site does not export as a project to develop further, so changing tools means rebuilding.

FAQ

Is Framer the same as Framer Motion?

No. The React animation library formerly called Framer Motion is today named Motion and is a package you add to your own project. The tool described here is a closed platform where a site is built and lives. Their shared origin makes search results mix them.

What does it really cost?

The site plan is one line: 10 USD a month on Basic, 30 USD on Pro. People are the second: the workspace owner and view only users cost nothing, every additional editor seat is 20 USD a month, and a content limited seat is 10 USD. The full seat rate came down from 40 dollars in June 2026, so older material quotes double.

Can I add my own code?

Yes, through React components placed on the canvas, with properties configured in the interface. The code runs in the visitor's browser, so keep secrets out of it and route operations requiring a key through your own server.

Will the site rank well in search?

The foundation is sound, since pages are static and served from a content delivery network, and settings for titles, descriptions, and structured data are available in the interface. The risk is what you add: many typefaces, video backgrounds, and animations spoil load time.

When should I pick something else?

When content is the product rather than an addition, when you need logic beyond an informational site, or when you want the code to stay with you. In those cases Next.js with a separate content system gives control this tool does not.

Documentation sits on the product site, and plan terms in the pricing.