The Framer workflow that cut my delivery time in half

Last year I delivered 11 client projects. This year, through May, I have already delivered 9. Same quality bar. Same scope of work. Roughly half the time per project.

The difference is not that I am working faster in the caffeinated, eyes-on-fire sense. I am working with less friction. Framer is most of the reason why, but Framer alone is not the answer. The workflow around it is.

Here is exactly what changed.

The brief is now a Framer file

I used to take a brief, build a Figma file, present the Figma file, get feedback, update the Figma file, present again, then rebuild in Framer. Two tools, two rounds of presentation, two sets of feedback cycles on essentially the same work.

Now the brief lives in a Notion doc that I own and the first thing the client sees is a live Framer prototype. Not a mockup. Not a screenshot. A URL they can open on their phone, resize, click through.

This matters because clients give different feedback on something they can interact with versus something they are looking at. Static mockups invite pixel-level feedback. Live prototypes invite narrative feedback. "This page feels too long" is more useful than "can you move this button 8 pixels to the left." I want the narrative feedback first because it shapes the structure, and structure is expensive to change late.

I built a personal component library and I protect it obsessively

Every project I finish, I extract the components worth keeping and add them to a private Framer library. Navigation patterns, card systems, form layouts, CMS-connected components, animation presets. Things I have already solved once and do not need to solve again.

The library is now at around 140 components. For a new project, I estimate I build roughly 30 to 40 percent of it from existing components, adapted. The other 60 to 70 percent is net new work. A year ago that ratio was closer to 10 and 90.

The discipline here is not building the library. It is maintaining it. Every few weeks I go through and deprecate things that have been superseded, document the ones that need explanation, and make sure naming conventions are consistent. An undocumented library is a library you stop using because you cannot find anything in it.

The content phase happens before the design phase

This used to be reversed. I would design beautiful empty containers and then wait for the client to fill them with content that did not fit, forcing layout revisions that ate into delivery time and created tension that did not need to exist.

Now I run a one-hour content session before touching Framer. We go through every page, every section, and I ask: what is the actual sentence that goes here? What is the real headline? What photo exists for this block?

Clients often do not have all of this ready, and that is useful information to have on day three rather than day twenty-three. I can either help them produce it, adjust the scope accordingly, or set expectations about the timeline. Any of those outcomes is better than discovering a content gap when the site is 80 percent built.

I use CMS for almost everything now

Early in my Framer practice I would hardcode content unless a client specifically asked for CMS. The reasoning was that CMS adds setup time and complexity. This was wrong in almost every case.

CMS-connected content is faster to build than it looks once you have the workflow dialed in, and it makes the handoff dramatically cleaner. Clients can update their own content without touching the design. Support requests drop. The relationship after delivery is less maintenance-heavy, which frees me up for the next project instead of fielding "can you change this text" emails six months later.

The exception is genuinely static content that will never change, legal pages, specific landing pages with locked copy. Everything else gets CMS by default now.

Client communication runs on a fixed rhythm

I used to respond to client messages as they came in. This sounds responsive and it is, but it also means your attention is constantly fragmentable by whoever decides to send a message. A client who sends five messages throughout the day gets five context switches from you. That is expensive.

Now every active project has two touchpoints per week: a written update I send on Monday mornings covering what was completed the previous week and what is planned for the current one, and a 30-minute video call on Thursday for anything that needs discussion. Outside of those, I am responsive to urgent blockers but I do not treat every message as urgent.

Clients adapt to this faster than I expected. Most prefer it. They know exactly when they will hear from me and what to expect. The Monday update means they are never in the dark. The Thursday call means nothing sits unresolved for more than a few days.

The side effect is that I have uninterrupted building time between those touchpoints. That uninterrupted time is where the quality lives.

The handoff is a product, not an afterthought

I used to hand off projects with a brief Loom walkthrough and a "let me know if you have questions." Questions always came, often complicated ones, often weeks later when I had moved on to other work.

Now the handoff is a structured Notion document: a recorded walkthrough of the CMS, a component guide covering every editable element and what it does, a style guide with the exact fonts, colors, and spacing tokens used, and a troubleshooting section covering the five things that most commonly break when clients edit their own sites.

This takes an extra three to four hours at the end of a project. It saves double that in post-delivery support and creates a paper trail that protects both sides if questions arise later.

The honest version of this

None of this is about being clever. It is about taking the friction seriously. Every hour I spent waiting on feedback, rebuilding layouts because content did not fit, answering questions that a better handoff would have prevented, every one of those was an hour I was not building something.

The workflow I have now is not final. I find something to improve every few months. But the principle behind it has not changed since I first articulated it to myself: a faster project is not one where you rush. It is one where you remove the things that slow you down without adding value.

Most of them, it turns out, were removable.