We rebuilt a studio's site in Framer and it took 7 weeks. Here's what we learned

Not a tutorial. A postmortem — the decisions that went well, the one that didn't, and what we'd do differently on the next one.

The project

Noma Studio came to us with a portfolio site that had stopped working. Not technically — it loaded fine, looked acceptable on desktop, had the right pages. But it wasn't generating the right conversations, the mobile experience was painful, and the work presentation was burying the strongest projects under a reverse-chronological dump that favoured recent mediocrity over older excellence.

Seven weeks from kick-off to launch. Framer. Here's what happened.

What worked: designing the CMS before designing the pages

The single best decision we made on this project was spending the entire first week on content strategy and CMS architecture before touching the visual design.

Most web projects do the opposite. Design the pages, then figure out what CMS structure supports them. The problem with that sequence is that you design for the ideal — the perfectly formatted project with the right images at the right ratio with the precise amount of copy — and then fight the CMS every time reality doesn't match the design.

We built the CMS schema first. We defined the fields, the constraints, and the edge cases. We identified that Noma had three distinct project formats — illustration-heavy, identity-focused, and text-with-process — and designed templates that handled all three without the CMS ever collapsing. The visual design followed the logic. It was faster and more robust because of it.

What worked: the mobile-first constraint

Noma's analytics told us that 61% of their traffic was mobile. We designed mobile-first — every layout decision was made at 390px and then expanded outward, rather than the other way around. This is the correct approach for almost any studio or portfolio site in 2025, and it's still not the default.

The discipline it imposes is useful. Decisions that work at 390px work everywhere. Decisions that only work at 1440px are usually decisions that relied on scale rather than clarity, and they tend not to survive contact with a real device in real light with a real thumb navigating them.

What worked: the contact page rewrite

Covered in a separate piece — but briefly: three added lines above the form increased enquiry quality measurably within the first month. Copy is part of web design. This project made that impossible to ignore.

What didn't work: the animation approach

We built the initial version of the project pages with scroll-triggered transitions — content elements revealing as they entered the viewport. It looked good in the Framer preview. It felt slow on the live site, particularly on mobile, where the sequence of reveals competed with the natural reading rhythm of someone scanning work on a phone.

We stripped it back two weeks after launch to a single, fast fade-in on page load. The site felt immediately faster and more confident. The lesson: animation that serves the content earns its place. Animation that demonstrates capability doesn't.

This is not a new insight. We know this. We still made the mistake, probably because the transitions looked genuinely good in preview and the temptation to ship something that looks impressive in a demo is real and persistent. We mention it not because it was catastrophic — it wasn't — but because it's the kind of mistake that's easy to make and easy to correct early if you're honest about whether the animation is there for the visitor or for the portfolio screenshot.

The number that still surprises us

Seven weeks is faster than most studios expect for a full Framer build with CMS. The reason it was possible: content was ready before design began. The single largest variable in any web project timeline is how long it takes the client to produce and approve content. Noma had their project descriptions, their process notes, and their image library organised before we started the visual design.

This never happens by accident. It happens because we build a content requirements document at the architecture stage and give the client a specific list of what we need, in what format, by what date. The schedule isn't set from when we start designing. It's set from when the content is confirmed.

The studios we work with who hit their timelines are the ones who treat content as a deliverable. The ones who miss are the ones who treat it as something to sort out later.