Any information contained on this Website is not legal advice and should not be treated as such. You should always contact an attorney for help with your specific legal needs and issues. We may also earn a commission when you click links to our partners and purchase goods or services. For more information, read our Disclaimers Policy.
Managing Webflow client projects well isn’t complicated, but it does require a clear process — one you can repeat without reinventing it for every new client.
This is how I run projects at Matthew John Design: from scoping a new enquiry through to handing over a live site. It’s built around the problems that actually come up — late content, scope creep, clients who want to “just tweak a few things” after launch — and what I’ve found actually prevents them.
Before the project starts: content first, always
The single biggest source of project delays isn’t technical — it’s content. Clients underestimate how much copy, images, testimonials, team bios, and supporting material a website actually needs until they’re staring at a blank brief three weeks into a build.
I don’t open Webflow until I have a complete content brief from the client. This covers every page, every section, every piece of copy and imagery needed before design begins. It sounds strict, but it saves everyone time — a designer building around placeholder content is guessing, and guessing means rework.
The content brief is also where expectations get set. When a client signs off on what goes on each page before the project starts, the “can we add a section about our history?” conversation during QA becomes a change request, not an assumption.
This process is formalised in Doc To Design — a structured handoff system I built to streamline exactly this stage.
Workspace setup and client access
On the Webflow side, I build all client projects as a guest in the client’s own Workspace wherever possible. This means the client owns their site from day one — it lives in their account, on their billing, and they’re not dependent on me to maintain access after the project ends.
The guest role lets me join a client’s Workspace without them needing to share passwords or transfer ownership. I request guest access from my Agency Workspace, they approve it with one click, and I get access to their sites without touching their billing or Workspace settings.
For clients who need to edit content themselves after launch, I set them up with a client seat — Webflow’s access system for giving clients controlled access to their own site. Depending on what they need to do, I assign one of three roles:
- Content editor — can update text and replace images across the site. Best for clients who just need to keep content current.
- Marketer — can create and edit pages using components. Better for clients who need to add landing pages or blog posts regularly.
- Reviewer — view and comment only. Useful for stakeholders who need visibility without edit access.
One thing worth noting: the legacy Webflow Editor (the ?edit interface) is being retired on August 4, 2026. If your clients are currently using that to update content, they’ll need to migrate to client seats before then. Webflow is handling this automatically for existing Editor users, but it’s worth understanding the new system before that deadline. Full details in Webflow’s deprecation FAQ.
During the build: keeping clients informed without constant calls
I use a simple staging-based workflow. The client gets a Webflow staging link from day one and can see the site develop in real time. This removes the “big reveal” moment where a client sees something for the first time after four weeks and wants to change the entire direction.
Check-ins happen at defined milestones — wireframes approved, design approved, content integrated, pre-launch QA — not on an ad hoc basis. Between those milestones, feedback goes into a shared document or comment thread, not WhatsApp or email chains.
Inside Webflow, I keep builds clean: consistent class naming, minimal global styles, components used wherever the same pattern repeats. This isn’t just tidiness — it’s what makes the site maintainable by the client or another developer after handoff. A site where every section has a unique bespoke class is a site that’s impossible to edit without breaking something.
The handoff: what actually needs to be in it
A good Webflow handoff covers three things: how to use the CMS, how content editing works under the new client seat system, and what to do when something looks broken.
I record a short screen walkthrough — usually 10 to 15 minutes — covering the specific CMS collections on their site, how to add and edit items, and what they should not touch in the Designer. The recording format matters: clients watch it when something goes wrong at 9pm on a Thursday, not during a scheduled training call they half-remember.
The handoff document covers:
- Login instructions and how to access their site via client seat
- Which pages are static vs. CMS-driven and how to tell the difference
- How to update common content types (blog posts, team members, services)
- What requires a developer to change vs. what they can do themselves
- DNS, hosting, and domain details — who owns what and where it’s managed
- How to reach me for support and what’s covered under the project vs. what’s a new request
Hosting and billing: who owns what
I have a clear position on this: the client owns their Webflow site plan and pays for it directly. I don’t resell hosting or act as an intermediary on their Webflow billing. This protects the client — if they ever want to work with another developer, they don’t lose access to their own site — and it protects me from being chased for someone else’s payment issues.
What I cover on a retainer basis is ongoing design and development work: changes that require the Designer, CMS structure updates, new pages or sections, and technical troubleshooting. Content updates the client can handle via their client seat are explicitly outside that scope.
This gets written into the project agreement before work starts. “Ongoing support” without a defined scope is where most freelance projects go wrong.
The “one more thing” conversation
Scope creep on Webflow projects usually isn’t malicious — clients genuinely don’t know what’s a small change and what isn’t. “Can you just move that section up?” is sometimes a two-minute job and sometimes an hour of restructuring CMS template logic.
My approach: anything that wasn’t in the original brief gets logged as a change request and quoted separately, with a clear turnaround and cost. I use a simple written format — what the change is, why it falls outside the original scope, and what it costs. Most clients accept this without issue when it’s framed clearly and promptly rather than as a surprise invoice at the end.
The project agreement includes a change request clause from the start, so this isn’t a new conversation — it’s just following the process we agreed on.
Want a Webflow site built with this process baked in?
Matthew John Design runs every project through a structured brief-to-handoff workflow — starting with content, ending with a site your team can actually manage. Get in touch to talk about your project.
If you’re a freelancer or agency looking to formalise your own client content process, Doc To Design is the tool I built to handle exactly that.
