Why we left Framer | Babou Blog

If you're shipping a software product in 2026 and your product can't be driven by an agent, you're cooked.

Not every workflow has to move to agents. Anything a single human can hold in their head will stay where it is. The workflows leaving drag-and-drop interfaces are the operational ones, where a team grinds through repetitive composition work for hours a day. Drag and drop isn't broken, but it can no longer compete with what a team and an agent can do together.

Every minute a founder spends nudging boxes in a canvas is a minute not shipping the demo video. Every hour a designer spends rebuilding the same component in a visual editor is an hour off the next campaign. That tradeoff used to be fine when the alternative was "ask an engineer." The alternative now is "ask Claude," and Claude is 10x smarter than most of us, 100x faster than all of us, and can work on 10+ different asks at once.

The rest of this post is about how we learned this the expensive way.

The Framer experiment

We picked Framer for the Babou marketing site for the reasons everyone picks Framer: visual canvas for the design half, code components for the engineering half. My brother Matt and his team is the design half, and the bet was that Framer's friendly interface would keep him in the driver's seat while I assembled everything around him.

The first feature we tried to build was the navbar, which isn't exotic: two dropdowns split by audience, Features for technical buyers, Creative for marketers, each with labeled items, descriptions, icons, and hover states. In a Next.js codebase this is a couple hundred lines of component code. In Framer it became four approaches and a closed door.

The simple navbar we were trying to build.<br>Approach zero: drag and drop it myself

I'm no deep-Framer expert, but how hard can a drag and drop web builder be? I've been using them since Dreamweaver.

I started where you'd expect. Drop in a rectangle. Round the corners. Drop in some text for the brand. Drop in a few text links. Drag, click, nudge. Logo on the left, items on the right, the orange CTA at the end.

Ten minutes in, with no agent in the loop, I'd already burned what's probably the equivalent of three hours of agent time.

And the easy part was the part I'd just finished. The mobile breakpoint, the dropdown panels, the hover states on every item, the contextual inspector that opens every time you click something, the variant swapping between them. Doing all of that by hand the way a designer would was going to take days. Time for some agents!

Approach one: import an off-the-shelf nav

Drag and drop was out, so I'd cheat the design problem by starting from someone else's work. The Framer marketplace has several reasonable nav components, so we picked one, dropped it into the project, and pointed Claude Code at it. The plan was to bash on it through the Framer MCP until the labels, icons, and links matched what we wanted.

One of the off-the-shelf Framer marketplace nav components we tried to bend into ours.<br>Claude couldn't change the labels, because linked component instances in Framer don't expose their internals through the API. getChildren() on a linked instance returns an empty array, you can only set the controls the component author exposed, and neither the labels nor the icons were exposed as controls. The only escape hatches were "detach the instance," which severs the link to the source and leaves you with a static frame, or "open the Framer UI and edit by hand," which defeats the whole reason we were trying to drive Framer programmatically.

Approach two: build it from scratch through the MCP

If the marketplace component was closed, fine, we'd build our own. Claude burned about three hours on this through the Framer MCP.

The output was a slow accumulation of opaque hashed identifiers. Every node Claude created came back with a string like Hb53M8VtK or Ay5dA8cmr, and the only way to do anything later was to maintain a hand-curated map of which hash meant which thing. About two hours in I opened the file Claude was keeping.

const nodeMapping = {<br>featuresChevron: 'Hb53M8VtK',<br>creativeDropdownOld: 'yXhk293an',<br>navItemLabel: 'Ay5dA8cmr',<br>iconColorProp: 'UO5clYVeQ',<br>// ... and so on<br>};<br>This is what programming a UI through the Framer API actually looks like. No naming layer, just hashed strings everywhere, mapped by hand to whatever you happen to remember about the layout.

The component's hover state, which was the whole point of having a dropdown, couldn't be set through the API at all. Framer interactions, the things that fire on hover or click and modify sibling state, are an editor-only feature. There is no programmatic way to wire "when I hover the nav item, show the dropdown." You open the Framer UI, click the element, and set the interaction in the inspector.

By hour three I'd had enough:

Nick → Claude Code<br>p]:m-0">I have no frickin idea where you are. I have no frickin idea what your plan...