Final Outcome Overview

The website of the B2B HealthTech company I work for moved from Wix to Framer seven weeks after the plan was approved, and two and a half weeks after the first page was built. On launch day, all 270 redirects landed on their exact target, and a crawl of 89 pages and 12,842 links found zero broken internal links.

The site launched with 34 page designs behind 89 published URLs, 7 interconnected CMS collections and 24 reusable components. It launched in English and now also runs in German and Spanish.

The bigger outcome was how it got built. I owned the whole technical side, and I designed a shared Claude Code project that let our Designer and a Marketing Product Manager plug in and rebuild pages with me, even though neither of them had worked with git or Claude Code before. The project grew to 779 commits in under three months.

Pain Point to Solve

The old Wix site had become hard to change. A small update could take an entire day, and the editor fought us at every step. Pages loaded slowly, we had no real access to custom code, and new components or animations were basically off the table. The team was frustrated, and the website was holding marketing back instead of supporting it.

Rebuilding the site was never the hard part for me. The problem was time. A migration of this size is a lot of work for one person, I was running other projects in parallel, and the deadline didn't move. I needed more hands, but the people available were a Designer with a finished design system and a colleague who knew the content inside out, not developers.

So the real question became: "how do I let two non-technical colleagues build real pages in a production codebase, at the same time as me, without breaking each other's work or lowering the quality bar?"

My Role

I built and owned every technical part of the migration: the project architecture, the page builds, the full CMS migration, all redirects, every meta title and description, filling in missing content, tracking and consent, QA and the launch itself.

My colleagues plugged into the system I built. They rebuilt pages in Framer, first from the live Wix pages and later from the new Figma designs, while the rules, checks and automation I set up made sure everything they shipped met the same standard as my own work.

How I Set Up the Team

I treated the team setup as part of the build, not as a side task.

• Every laptop, set up from scratch: I wrote a 13-step setup guide for a fresh Mac and went through it with each colleague personally. It covers Homebrew, Node, the GitHub CLI, Claude Code, the Framer agent and the Figma desktop app for the design connection. It ends with a smoke test and a three-check verification inside Claude, plus a troubleshooting table for the eight problems people actually ran into.
• Git that runs itself: hooks pull the latest work when a session starts, then commit and push automatically when it ends. Risky commands like force-push and hard reset are blocked, and secrets can't be committed. Nobody had to learn git to use it safely.
• The Designer's system as the source of truth: I converted our Designer's Figma variables into design tokens and audited how much of the Figma homepage was actually bound to them. That way, pages built in Framer matched the design instead of approximating it.
• One branch per page: each page got the same branch name in git and in Framer. Anyone could pick up a page, build it on their own schedule and publish it without stepping on someone else's work.

Rebuilding the CMS From the Ground Up

I handled the entire CMS migration myself, and I didn't just copy it across. Wix stores rich text in its own JSON format, which Framer can't read, so I built an import pipeline that converts every post to clean HTML and writes it into Framer through its API, including images, links and formatting.

• A new content model: I created Authors and Categories as their own collections, which didn't exist before, and linked every post to them. An author or category page now updates itself when a post is added.
• 7 collections, all connected: Blog Posts, Authors, Categories, Videos, Customer Stories, FAQs and Resources. Each one was rebuilt from what the live pages actually showed, not from the old Wix setup, and every import was checked item by item against the source.
• Built for search: the FAQ collection powers a live search across questions and answers, and generates the structured data search engines read, so it never drifts from what is on the page.
• Cleaned up on the way: I fixed outdated facts in the old content during import and later recategorised the whole blog, so the category pages finally make sense to a reader.

The Rulebook: Everyone Builds Their Own Way, Every Page Comes Out Right

This is the heart of the project. Each of us worked in our own Claude Code session, on our own laptop, on our own schedule. Without shared rules, that's how you end up with three websites stitched together. So I wrote the rules once, in the project itself, and every session loads them automatically before anyone types a word.

• 17 non-negotiable build standards: responsive at all four breakpoints by default (never a "mobile fix later"), exactly one h1 per page with a correct heading hierarchy, fluid units instead of fixed pixels, every breakpoint checked against the design after every section, one 1260px content column across the whole site, and image budgets (hero under 250 KB, cards under 80 KB) without visible quality loss.
• Decisions Claude makes on its own: if an element repeats across pages, it becomes a component, and every existing copy gets replaced in the same session. If the old site placed the same element four different ways, Claude picks one treatment and applies it everywhere. Nobody has to stop and ask.
• Rules that protect the business: only self-hosted fonts, because one wrong font choice would have sent every visitor's IP address to Google. No links to pages that don't exist yet, and building a page includes wiring up every link that should point to it. Testing only on staging, so test traffic never pollutes the live A/B tests.
• Every lesson becomes a rule: Framer has plenty of silent failures. Whenever one of us hit one, it went into a shared knowledge base of 33 files that every session reads. A mistake found once was never repeated by anyone else.
• Git rules nobody has to remember: pull at the start, commit every change, merge the branch the moment the page is live. All automatic.

The result: a page built by our Designer and a page built by me pass the same checks and look like one system, even though each of us built them separately.

Skills I Built for the Team

Every check we kept repeating became a Claude skill, so quality didn't depend on who was building:

• Page merge check: after a page goes live, it wires up the navigation and footer links, checks meta titles and descriptions against their length limits, runs the link check and merges the branch.
• Link audit: crawls the whole published sitemap for broken internal links, broken CMS bindings, dead buttons, broken anchors and orphan pages.
• Slug rename: renames a page, adds the redirect Framer doesn't create on its own, and rewrites the old URL everywhere it appears.
• Translation drift: shows, per language, where the English changed after it was translated. It runs before every publish.

Protecting SEO, Tracking and Ad Spend

A migration can quietly break things that cost money. Before launch I rebuilt 270 redirects from the old Wix export, checked every Google Ads landing page against them (which caught one live ad pointing at a page that no longer existed), and fixed missing meta data on 10 of 22 static pages.

The most important catch was in tracking. On Wix, the platform's tag manager wrapper set the consent defaults for us. On Framer, those defaults would have been missing, so marketing tags would have fired without consent in GDPR regions. I moved Consent Mode into our consent tool before launch.

After Launch: Blog Publishing Without the Busywork

The project didn't stop at launch. Our content team writes in Notion, and copying every article into Framer by hand, then writing slugs, excerpts and meta data, was exactly the kind of slow manual work the migration was meant to end. So I built a setup where the team publishes blog articles from Notion to Framer without leaving Notion.

• One status change starts it: an author finishes a post in Notion and sets its status to "Ready for Framer". A Notion automation triggers a Claude Code routine that I set up to run in the cloud, so nobody needs a terminal, and nobody's laptop has to be on.
• Claude fills in the boring parts: the routine reads the article and writes whatever is still missing: slug, excerpt, meta title, meta description and alt text for the cover image (it actually looks at the image). Everything is written for our target audience, in the article's own spelling, and it never adds claims or numbers the article doesn't contain.
• Guardrails, not surprises: a title that is too long for the blog card isn't silently rewritten. The routine stops that post and leaves a shorter suggestion as a Notion comment, so the author decides. Character limits are enforced in code, so a field that is too long is rejected, not cut off.
• Drafts, never auto-published: each post lands as a draft on its own Framer branch, and the routine comments the branch link back on the Notion post. If something fails, the post gets a "Push failed" status with the reason. A person always reviews and publishes.

What used to be a manual copy, paste and format job per article is now a single status change in Notion and one review in Framer.

The website kept improving after launch too. The German site is content-complete, the Spanish site is close behind, and our HubSpot forms now load about 1.1 seconds faster on slow mobile connections, with no layout jumping while they load.

What I'm Proud Of

I've built websites for years, and this was the first time the website was the easy part. The highlight for me is what happened to the team. A Designer and a Marketing Product Manager went from never having used git or Claude Code to shipping production pages through Claude Code, and they loved it. It was an incredibly good collaboration, and they still tell me how much easier their work has become.

That was only possible because of the setup underneath: the laptops, the automation, the rules and the skills. It outlived the launch too. The same workspace is still how the site gets updated today, and my colleagues can now focus on what really matters: the creative work.

Tech Stack