The handoff was always a fiction
The traditional workflow describes design and engineering as sequential: draw the page, then build it. In practice they were never cleanly sequential — developers made decisions designers assumed they owned, and the gap between the mockup and the shipped page was where those decisions quietly accumulated. Webflow and Framer are, among other things, arguments that the gap should not exist.
Webflow launched in 2013 and has spent the intervening years building a visual interface that writes genuine HTML and CSS, not an approximation of it. Its output is standards-compliant markup that a developer can inspect, export, or extend. The canvas is not a picture of a webpage; it is a webpage, with a real box model underneath it and real cascade determining what wins. Container queries, flexbox, grid — the engine has added each as browsers shipped support. The tradeoff Webflow makes is that the interface has to teach you the actual concepts, which is why its learning curve is longer than it looks from the marketing.
Framer arrived on the scene as a prototyping tool and pivoted, decisively, toward publishing. The current product takes React components as its building blocks, meaning the output is closer to an application than a document. Framer's motion library — developed separately, with the same Framer brand — has become a first-choice dependency for teams animating inside React regardless of whether they use the publishing platform at all. The two products share a name and a heritage but are distinct things, and conflating them misses what each one actually does.
What emitting the site costs
Neither tool is free at production scale. As of early 2025 on their published pricing pages, Webflow's site plans begin around ten dollars a month and rise steeply once you need CMS content beyond the free tier limits or more than a staging domain; Framer's paid plans start at a similar floor with comparable CMS constraints. The more instructive cost is the one that does not appear on the pricing page.
The two products share a name and a heritage but are distinct things, and conflating them misses what each one actually does.
When the design file is the build, the design file accumulates the same technical debt a codebase does. A Webflow project with two years of client revisions behind it can reach a state of cascading override that any senior CSS author would recognise as a mess — inherited styles corrected by utility classes, corrected by inline overrides, corrected by !important. The visual surface looks fine. The underlying structure does not. CSS specificity does not become forgiving because the person writing the rules used a point-and-click interface to write them.
The same pressure bears on Framer, differently. Because its components are React, a Framer site has a JavaScript bundle behind it, and JavaScript bundles have weight. A page that would be a fast static document in plain HTML becomes a hydrated React tree. Whether that tradeoff is right depends entirely on what the page needs to do; for a marketing site with enough interactive surfaces to justify it, fine. For a five-page portfolio, it is overhead that a simpler tool would not introduce.
These are real costs. They are also exactly the costs you incur with a separate design tool and a separate engineering step — miscommunication, refactoring, debt — just distributed differently. Stripe's marketing pages, which have been admired for their typographic precision for years, are maintained by a team with no handoff problem because design and engineering are genuinely the same people working in the same repo. Most teams are not that. For most teams, the question is which gap they prefer: the gap between the mockup and the build, or the gap between what the visual tool can express and what the finished product actually needs.
Webflow and Framer's answer is that the second gap is narrowing faster than anyone predicted.