How We Use Code Components in Framer

How We Use Code Components in Framer

Code components are where Framer stops being "no-code" and becomes a serious front-end platform. They're React components that render on the canvas, in preview and on the published site, with controls that let anyone on the team configure them visually.

They're also easy to overuse. Every code component is a small piece of software your team will own after launch. So we have a simple rule set for when we write one, how we design it, and how we hand it over.

This article explains that approach, with the types of components we build most often. For the technical reference, see Framer's code component docs.

Why code components matter

Out of the box, Framer's visual tools cover a lot: layout, responsive breakpoints, CMS, effects, forms and component variants. Code components add what those can't:

• Highly custom UI not available in the default toolkit, like a configurator or a custom chart.

• Stateful interactions, complex logic and data-driven behavior, such as calculations, multi-step flows or filtered views.

• Reusable building blocks built in React but configured visually, so marketers can use them without touching code.

For B2B tech companies, that matters. The product is often abstract: an API, an AI model, a workflow engine. A well-built interactive component can show how it works in a way a screenshot never will.

Our decision ladder

Before writing code, we go down a short ladder and stop at the first step that solves the problem:

1. Native layers and components. Can it be built with stacks, variants and effects? Most "custom" sections can.

2. CMS. Is it really a content problem, like a filterable list of integrations? A collection and a template usually beat code.

3. Plugins and Fetch. Does the data live somewhere else? Sync it with a plugin or bind it with Fetch.

4. Code override. Is it a small behavior change on an existing layer, like adding UTM parameters to a link?

5. Code component. Only now do we write a component.

This keeps the custom code small. Framer's own docs make a similar point about overrides: built-in features are optimized by default and less likely to break.

Where code components earn their place

When a component makes it past the ladder, it's usually one of these:

• Interactive product tours. A recreated product UI that responds to clicks or steps, showing a workflow without a video.

• Dynamic comparison tables. Plans or competitor comparisons where visitors toggle features, team size or billing period.

• Pricing and ROI calculators. Inputs, a formula and a clear result, with the formula's assumptions visible.

• Custom carousels and storytelling sections. Scroll- or step-driven sequences when native effects can't express the timing.

• API-powered content blocks. Live or semi-live data like system status, model benchmarks or a public metric, fetched and rendered on the page.

• Data visualizations. Charts that need to be accurate, responsive and on-brand at the same time.

How we design a component

The code is rarely the hard part. The hard part is the interface between the code and the people who will use it. Our checklist:

• Design it first, on the canvas. We design every state (empty, loading, error, mobile) before writing code, so the component matches the system.

• Expose the right controls. With property controls, we expose labels, content and options that marketing will change, and hide everything that would break the design.

• Use the site's styles. Colors and fonts come from the project's styles so a brand update flows through.

• Set sensible defaults. Dropped onto a page with no changes, it should look right.

• Make it accessible. Keyboard navigation, focus states, readable contrast and real text instead of text baked into images.

• Keep it light. Avoid heavy libraries for small jobs, and check the effect on page speed.

Example: building a pricing calculator

Here's how that checklist plays out on one of the most common requests we get, an interactive pricing or ROI calculator.

Scope first. We agree on the inputs (for example team size and usage), the formula and the output with your team before any design. If the formula lives in a spreadsheet today, that spreadsheet becomes the spec.

Design every state. Default values, extreme values, invalid input, mobile layout and the call to action under the result.

Decide what's editable. Labels, help text, currency and the call to action become property controls, so marketing can adjust copy and test variations. The formula stays in code, where it can't be broken by accident.

Make the assumptions visible. A short note explaining how the number is calculated builds more trust than a big number with no context.

Test against the source. We check results against the original spreadsheet for a set of inputs before launch, and again whenever pricing changes.

Handover and maintenance

A code component without an owner becomes the part of the site nobody wants to touch. We keep that from happening:

• Document each component. What it does, what each control means, and what not to change.

• Keep the count low. A typical marketing site we build needs a handful of code components, not dozens.

• Plan for change. If a component depends on an external API, decide what visitors see when that API is slow or down.

• Name an owner. Someone on your side, often in engineering, knows the components exist and can review changes.

When not to use a code component

• When the requirement is really a design or content problem.

• When a plugin already does the job well and is maintained.

• When the content needs to be indexed by search engines and could live in the CMS instead.

• When nobody on your team could maintain it after launch.

Our point of view

Code components let us treat Framer sites like real front-end products. We keep most of the system accessible to non-technical teams and spend engineering effort only where it has an outsized effect on UX, credibility and conversion. The best code component is one your marketing team uses every week without knowing, or caring, that it's code.

Allsite builds brands and Framer websites for venture-backed tech companies — designed to perform, and built for the teams that have to run them.