Aadhib

Case study · Active

Rebuilding a Framer website without losing the original design

A faithful rebuild is not a pixel copy. Deciding which details are the design and which are artefacts of the tool is the entire job.

Role
Head of Software Development
Published
Reading time
1 min
Next.jsComponent architecture
01

Context

The site existed and looked good. It had been designed in Framer, approved on that basis, and was in use. The problem was not appearance — it was that extending it, connecting it to real content and controlling its technical characteristics all required going back through the builder.

02

Problem

A rebuild has two failure modes and they pull against each other. Reproduce the output too literally and you inherit the builder's structure, which is the thing you were trying to escape. Rebuild too freely and you ship something that is not the design anyone approved.

03

Constraints

01
The design is the acceptance criterion
Stakeholders approved a specific appearance. "Close enough" is a judgement they get to make, not the developer.
02
Maintainability is the reason for the work
If the rebuild is not easier to change than the original, the project achieved nothing.
03
Responsive behaviour has to be intentional
Builders generate breakpoint behaviour automatically. Reproducing that output without understanding it just relocates the problem.
04

Approach

I rebuilt in components, comparing against the original at each breakpoint, and made an explicit decision for every difference: is this the design, or is it an artefact of how the builder happened to render it? While everything was being touched anyway, I took the opportunity to add the CMS integration, metadata and asset handling the original never had.

05

Architecture

Design referenceThe approved Framer output, used as the comparison target.
Component rebuildReusable components with deliberate responsive behaviour.
Content and metadataCMS integration, structured data and asset management added during the rebuild.
06

Solution

A component-based implementation that matches the approved design where it matters, behaves deliberately at each breakpoint, and carries the CMS integration and technical SEO the visual build could not.

The question asked at every difference

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

A 3px gap that appears because of how the builder stacks elements is not a design decision and does not need reproducing. A specific rhythm between sections is. Telling them apart requires talking to whoever designed it, which is the part teams skip and then regret.

07

Lessons

  1. 01Pixel-perfect is the wrong target. Some of what a builder outputs is design and some is incidental; copying both faithfully reproduces the maintenance problem you set out to solve.
  2. 02Motion is where rebuilds quietly lose. Layout ports cleanly and animation does not, and nobody notices until the result feels flatter than the original.
  3. 03Rebuild once, add everything. The rebuild is the only moment when touching every file is already justified.

Stack

What it runs on

Next.jsComponent architecture

The project

01Nexel events platform
BUILD LOGWhat I learned rebuilding a Framer site in code
All case studies