What I learned rebuilding a Framer site in code

Visual builders are genuinely good at deciding what a site should look like. They are less good at being the thing you maintain for the next three years.

Rebuilding one in code sounds mechanical. It is mostly judgement.

The question you ask at every difference#

Is this deliberate, or is this what the tool did?

A 3px gap that exists because of how the builder stacks elements is not a design decision and does not need reproducing. A specific rhythm between sections almost certainly is. A font size that is 17px rather than 16 might be either.

Telling them apart requires talking to whoever designed it. That is the step teams skip — they treat the output as the specification, faithfully reproduce every artefact, and end up with code that is as awkward as the thing they replaced.

Pixel-perfect is the wrong target#

If you reproduce builder output exactly, you inherit its structure. Absolute positioning where a flex layout belongs. Fixed heights where content should flow. Breakpoint behaviour generated by rules nobody chose deliberately.

You now have a maintainable-looking codebase with the maintainability problem intact, and you have spent weeks achieving that.

The better target is indistinguishable to the person who approved it, built in a way you would defend in review.

Motion is where it quietly goes wrong#

Layout ports cleanly. You can compare two screenshots and see whether you have it.

Animation does not. Builders make it easy to add transitions everywhere — hovers, entrances, subtle movement on scroll — and none of it shows up in a static comparison. Rebuild without paying attention and the result is technically identical and feels flatter, and nobody can articulate why.

If motion matters in the original, capture it deliberately: what moves, how far, over what duration, with what easing. Otherwise it silently disappears.

Responsive behaviour needs to become intentional#

Builders generate breakpoint behaviour from layout rules. It usually works and almost nobody looking at it could tell you why it works.

Reproducing that output without understanding it just moves the problem into your codebase. The rebuild is the point at which each breakpoint should become a decision — which is more work upfront and the entire reason the exercise is worth doing.

Add everything while you are in there#

The rebuild is the only moment when touching every file is already justified. So that is when the CMS integration, the metadata layer, the structured data and proper asset handling go in.

Doing it later means a second pass through the same files for a fraction of the benefit. The marginal cost during a rebuild is small; the cost afterwards is a project.

Was it worth it#

Yes, but not for the reasons usually given. The performance improvement is real and secondary. The actual value is that the site became something a team can change — content without a developer, new sections without fighting a builder, technical characteristics that are chosen rather than inherited.

That is the thing a visual builder cannot give you, and it is the only good reason to do the work.