Why we rebuilt norml.studio on Next.js and Sanity
By Max Tymoshyn4 min read
I was trying to change the header on norml.studio, and I was pissed off.
Claude was already part of our client work. On a WordPress site, a change could start as a prompt, continue as a code edit, and end with a review.
Our own website was still in Webflow. The same header change meant opening the visual editor, dragging things around, and fighting with pixels.
I wanted the same prompt-first workflow for the site we owned. That frustration started the migration.
Our own website had fallen behind the workflow
On client WordPress projects, Claude could read the theme files, CSS, and templates. A header change could happen in the real files rather than in a tutorial or a list of instructions.
With our Webflow setup, I couldn’t find a connection that gave Claude the same access to norml.studio. Claude could help with copy or code, but the live site still had to be changed through the visual editor.
Webflow had done its original job. It gave the site a good visual starting point and kept it running for a long time. The mismatch came later: the website no longer fit the way our team was building and maintaining client sites.
The site moved in one evening
Webflow’s code export includes HTML, CSS, JavaScript, and assets. Those files became the working material for the rebuild.
The old design already contained the choices worth keeping: type, spacing, images, motion, and page layouts. Claude could read those files, see how the styles worked together, and help move the site into Next.js without starting from a blank design.
By the end of that evening, norml.studio was running as custom code. Roughly one more evening connected the rest of the setup: GitHub for the code, Vercel for publishing, and Sanity for content.
The timing matters. The first evening got the site out of Webflow. The second turned the rebuild into the system we still use.
Webflow’s CMS data isn’t included in a code export, so the content needed a new home. Sanity became that content store, separate from the page code.
Each tool now has one clear job
The code lives in GitHub, Vercel publishes it, and Next.js renders the pages. Sanity stores the copy and images.
Claude is the working interface across this setup.
Sanity is a headless CMS, which means the content can live separately from the code that displays it. I almost never open Sanity Studio now. It does its job quietly in the background.
A header change no longer begins inside a visual editor. Claude can inspect the existing files, make the edit, and show the result for review. New pages and blocks follow the same path.
This makes the workflow easier to understand as well. Each tool has a narrow role, and Claude can work across them without turning every small request into a manual layout task.
The code gives Claude the site’s visual language
The useful part isn’t code generation by itself. The site’s real HTML, CSS, and components give Claude a clear reference for how norml.studio should look.
Fonts, spacing, buttons, page sections, and mobile styles already exist in the code. When Claude adds a page or block, it can reuse those choices instead of inventing a new design system for every request.
That makes new work faster, but it doesn’t remove review. AI can still make a bad design choice or break a layout. The improvement is that review starts with a real change on the site, not with every element being moved by hand.
The same workflow works for content
Our content managers can use the Claude subscriptions they already have to work on the site. They can add a case study, update copy, or publish work to Unpublished through the same setup.
Claude reads the existing structure and handles the code or content change. Sanity keeps the content stored. The content manager reviews what changed and publishes it.
That means routine publishing doesn’t depend on one person knowing every Sanity screen or moving every part of a layout. Larger structural changes still get a closer review, but normal content work can move through the same prompt-led process.
Why Webflow stopped fitting
Webflow wasn’t broken. It had stopped matching the way we worked.
Client sites had already shown what an AI-assisted website change could feel like. Keeping norml.studio in a visual editor meant using a slower process on the website we controlled most directly.
Now a header change starts with a prompt. The same setup can support a new page, a new block, a case study, or a content update and keep the site’s existing style in view.
That is why we rebuilt norml.studio on Next.js and Sanity. I wanted our own website to be as easy to change with AI as the client websites that had already changed how we worked.
