One of the questions I get asked most often, from clients, other designers, and agencies I work with, is what the process actually looks like when I build a Webflow site. Not the polished version where everything goes smoothly. The real one.

The honest answer is that every project is a little different. The timeline, the content, the goals, the client's comfort level with tech. All of it shapes how things unfold. But the bones of the process stay mostly the same. Here's how I actually work, from the first conversation to the moment a site goes live.

The First Call

I always start with a conversation, not a quote. Before I know what something will cost or how long it will take, I need to understand what the client is actually trying to accomplish.

That sounds simple, but it matters more than people expect. A business that needs a clean five-page site to establish credibility is a completely different project from a growing brand that needs a CMS-driven site where the team can update content themselves every week. Both projects live in Webflow. Both look like "a website" from the outside. But the thinking behind each one is different.

So in that first call, I'm listening for a few things: what the current site situation is (or if there isn't one yet), who the audience is, what the client wants visitors to do, and whether there are any specific things they've loved or disliked on other sites they've come across. That last one tells me a lot.

I'm also trying to get a sense of how involved the client wants to be. Some people want to hand it off completely and trust the process. Others want to be in the loop at every step. Neither is wrong. I just want to know upfront so I can set expectations that actually hold.

You can book a free discovery call here if you'd like to start that conversation.

Scoping and the Proposal

After the first call, I put together a proposal that outlines what's included, what's not, and how the project is structured. I'm specific here on purpose. Vague scopes lead to misaligned expectations, and misaligned expectations lead to projects that drag out longer than they should.

I note things like how many pages are included, whether CMS setup is part of the build, how many rounds of revisions we have, and what I'll need from the client before I can start. That last part is important. A lot of projects stall at the beginning not because of the build itself, but because content isn't ready.

I offer a few different service packages depending on what a business needs, from the Essentials Launch for businesses that want a professional, customized look without a full custom build, to the Signature Design package for businesses that want something fully bespoke. If you're not sure which direction makes sense, we can talk through it on the discovery call.

Gathering Content and Mapping the Site

Before I open Webflow, I need content. Copy, images, brand assets, fonts, color palette. Ideally all of it. I know that's not always how it goes in practice, but getting as much as possible upfront saves a lot of back-and-forth later.

I also work through the site map at this stage. Which pages exist, how they're connected, what the navigation structure looks like. This is the point where I flag anything that doesn't quite add up, like a page that's missing, a section that's trying to do too many things at once, or a nav structure that might confuse visitors.

If you're working on your copy and not sure where to start, I have a free Website Copy Starter Guide that helps you think through what each section of your site actually needs to say.

If the client is using a tool like Relume to put together a wireframe or rough layout, I can work directly from that. It speeds up the early stages and gives us something concrete to react to before any real building starts.

Building in Webflow

This is where most of the time goes, and honestly, it's the part I enjoy most.

I start with the global elements, the navigation and footer, because those carry through every page. Getting those right early means I'm not untangling things later. If the footer needs to be updated across the whole site, I want that to be a one-time edit in one place, not something I'm chasing across twenty pages.

From there I build out the pages in order of priority. Usually that means the homepage first, since it tends to set the visual direction for everything else, then inner pages. I'm thinking about structure the whole time: how elements are stacked, how the layout shifts across screen sizes, how classes are named so the site stays clean and maintainable. Class naming is one of those things that doesn't matter until it really matters. A messy class structure makes everything harder to update later, for me and for anyone else who might work on the site down the road.

Spacing and alignment get a lot of my attention too. Small things like text not sitting where it should in a card, or spacing that looks fine on desktop but breaks on tablet, can make a site feel unfinished even when the design itself is strong. I catch a lot of those details as I go.

Setting Up the CMS

If the site has dynamic content, like a blog, a portfolio, a team page, or a menu, I set up CMS collections to handle it. This is one of the things I think Webflow does especially well, and it's something I've written about in more depth if you want to dig into why Webflow's approach is different from other platforms.

The goal with CMS setup is always the same: the client should be able to add, edit, and update their own content without touching the design. That sounds obvious, but getting there takes thought. I build the collection fields carefully, label everything clearly, and test what the editor experience actually looks like before handing anything over.

A good example of this in practice is the work I did for Dr. Imamu Tomlinson's podcast site. The whole point was building a CMS structure he could actually grow into without needing a developer every time a new episode went live. That kind of setup is something I think about on every project that has ongoing content.

I'm also deliberate about what clients can and can't control. Webflow's editor gives clients the ability to update content in designated areas, but the design and structure stay protected. That's the right balance for most businesses. They need flexibility without the risk of accidentally breaking something.

Responsive Design and Interactions

Every site I build gets checked and adjusted across breakpoints: desktop, tablet, and mobile. Webflow handles a lot of this well by default, but there's always work to do. Mobile navigation in particular almost always needs attention. What works at full width doesn't automatically translate to a small screen, and a clunky mobile menu is one of the fastest ways to lose a visitor.

I work through each breakpoint methodically. I'm looking at how text reflows, whether images are cropped correctly, whether spacing still makes sense, and whether any interactive elements are easy to tap on a phone. It takes time, but it's not optional. Most website traffic comes from mobile now.

If the project includes interactions, hover states, scroll animations, and entrance effects, I build those in at this stage too. Webflow's interaction system is genuinely powerful, and when it's used well, it's one of the things that makes a Webflow site feel different from one built on a more limited platform. I keep interactions purposeful, though. Animation for its own sake tends to get in the way.

Review and Revisions

Once the build is at a solid stage, I share a staging link with the client for review. I walk them through it, pointing out decisions I made and flagging anything I'd still like their input on.

Revisions are a normal part of the process. I build them into every project. What I ask of clients during this stage is specificity. "The hero section feels off" is hard to act on. "The headline is too large on mobile and the button is too close to the image" gives me something to work with. Most clients get there quickly once they know that's what I need.

Pre-Launch Checks

Before anything goes live, I go through a checklist. Page titles and meta descriptions, basic SEO settings, any scripts or tracking tags that need to be in place, form integrations, broken links, favicon, 404 page. The kind of things that are easy to overlook when you're focused on the build itself.

If you want to see what a thorough homepage review looks like, my Ultimate Homepage Checklist walks through the key elements that make a homepage actually convert. It's free and useful even if you're reviewing your own site.

I also check the project settings one more time, including third-party scripts and custom code in the head or body, to make sure nothing is interfering with the way the site renders. I've debugged enough issues that trace back to a stray character in the project head code to know it's worth a careful look before launch.

Launch and Handoff

Once the client has signed off and the checklist is clear, the site goes live. In Webflow that means publishing, which is clean and straightforward, and then verifying everything looks right on the actual domain.

After launch, I walk the client through the Webflow editor so they know how to make updates. I show them where to go to add a blog post, how to update a team member's bio, how to swap out images. I want them to feel confident, not dependent on me for every small change.

If the client is an agency and I've been working behind the scenes, the handoff works a little differently. But the principle is the same. The work should be solid enough that whoever manages the site going forward isn't left with questions. You can read more about how that kind of arrangement works in my post on white-label web design.

The Bigger Picture

Every project I take on goes through this process in some form. The details shift, the timeline expands or compresses, but the approach stays consistent: understand the goal first, build with intention, test thoroughly, and hand off something that works.

If you want to see the kind of work that comes out the other side of this process, you can browse recent projects here.

And if you're thinking about a new Webflow site or a redesign and want to understand what working together would look like, I'd love to hear about your project.