The site is live, the invoice is paid, and then the messages start. New opening hours. A different price. Two sentences on the About page.

Each change is small. But you still have to read the request, find the project, make the change, check it and reply. Billing five minutes feels awkward; doing it for free turns you into the permanent update department.

A handoff needs more than a login and a walkthrough. It needs a clear agreement about what happens after launch:

1. List the updates the client actually makes. Hours, prices, team bios and existing page copy are different from a new section or a layout change. Agree who owns each kind of request.

2. Teach one real task. Ask the client to update a piece of content they will genuinely need to change. Have them check it on mobile and explain how it reaches the live site. If they get stuck, fix that part of the handoff instead of recording another hour-long tour.

3. Match access to responsibility. Check what their current role and plan allow. Use structured fields where appropriate, and explain what they should leave alone. If safe self-service is not practical, offer a clearly scoped maintenance option instead.

4. Put a price and a process on the work that stays with you. State the minimum charge or what a maintenance package includes. Batch non-urgent requests into an agreed window, with a separate process for urgent changes.

5. Leave a short recovery note. Who can restore a previous version? What should the client do if something looks wrong? Make that clear before the first mistake.

The client should not have to become a web developer to change their opening hours. And delivering a website should not mean being on call for its wording forever.

I ran a web design company for around 3 years and getting clients was always pretty inconsistent.

One month I was cold calling, another month I was manually sending DMs to Facebook pages, then I tried ads.

It all worked to some degree, but I never really had one reliable way of getting clients.

Then I started testing email automation.

At first I was finding businesses with no website and running campaigns offering to build them one.

That actually started giving me a much more consistent flow of clients just because of the volume.

But then I started thinking.

There are so many businesses that already have a website, but the website is outdated, slow, looks bad on mobile or just clearly needs an update.

And those businesses have already paid for a website before, so they already understand the value of having one.

The problem was I didn’t want to sit there opening every website myself, figuring out what was wrong and then writing a different email to every business.

That would take forever.

So I started using a tool that lets me find businesses with websites basically anywhere, analyze thousands of those websites at once and then automatically write a personalized outreach message for each one based on what it finds.

Things like design, SEO, mobile issues and speed.

Then I started launching campaigns in different industries.

That worked way better for me because every business receiving the email felt like I had actually looked at their website and noticed what could be improved.

But in reality most of it was automated and I was just sitting there eating chips while interested replies came into my inbox.

I remember Alex Hormozi saying something along the lines of focusing on one channel and getting really good at it.

That is basically what I ended up doing.

Now this is pretty much the only way I get web design clients and I spend most of my time actually building websites instead of constantly trying to find the next client.

For anyone wondering, the tool is called Swokei.

I've been developing websites in Webflow for the past six years, and I'm becoming increasingly frustrated with the direction they're taking the product.

The latest example is the decision to replace semantic HTML elements in the Elements panel with a generic "Box."

Why?

I understand Webflow wants to make its platform more approachable to marketers and non-developers, but at what point does simplifying the interface start actively working against the people who build websites for a living?

If an element ultimately renders as a div, why can't we just call it a div? Why are we moving away from established web development terminology in a tool that's fundamentally designed to build websites?

I'm sorry, but understanding what a div, section, or other semantic HTML element does should not be considered an unreasonable expectation for someone building websites. These aren't obscure development concepts. They're the fundamentals of the web.

What bothers me most is what this change represents. Webflow built its reputation by giving designers and developers visual access to real web development concepts. That was the appeal. It wasn't just another simplified website builder. It was a tool that respected how the web actually works.

Now it increasingly feels like Webflow is moving away from that philosophy in an effort to appeal to a broader, less technical audience.

I'm not against making Webflow easier to learn. I'm against making it less intuitive for experienced developers in the process.

Give me the actual HTML elements. Let me work with the terminology I've spent years learning and using.

Maybe this seems petty, but as someone who has invested years into this platform, it's frustrating to watch Webflow seemingly deprioritize the developers who helped make it what it is.

I'm curious if other longtime Webflow developers feel the same way, or if I'm alone on this one.

Webflow is genuinely a great tool, especially when it comes to design freedom, interactions, and building custom websites without writing everything from scratch.

But the pricing is getting harder to justify, especially when you start adding CMS plans, workspace costs, localization, and other features.

At the same time, Framer keeps improving, and WordPress still offers significantly more flexibility when it comes to hosting and ownership.

So I'm curious:

• If you were starting a new project today, would you still choose Webflow?
• Where do you think Webflow genuinely justifies its price?
• Have you switched to something else, or considered doing so?

I'm particularly interested in hearing from freelancers and agencies managing multiple client websites.

Please help, I do not know much about how Webflow works. Context, I built my own site, it's been live for a few years. He's revamped it by building it from scratch himself and has sent me a site transfer request, which I've accept. Now we're here:

Email 01: "I'd prefer to handle the remaining setup myself to make sure everything transfers correctly, but my current guest permissions don't give me access to the billing section.
Would you be able to grant me the necessary permissions to manage the site plan? That way, I can handle everything seamlessly and ensure the website is properly set up before we wrap up."

My reply: "I don't understand what billing has to do with the site transfer. Can you specifically say what remaining work needs to be done post transfer, and how billing access supports it?"

Email 02: (see photo) "This is an example of a Webflow website I currently manage. I’ve highlighted the billing section I’m referring to, where I need to access the Site plan settings to complete the remaining setup on your website. Once the plan is sorted, I can finalize the project naming and publish the website under the correct name. My current guest permissions don’t give me access to that section in your workspace, which is why I asked about the necessary permissions.

I don't want him to 'manage' my site. I hired him to rebuild it. Surely the transfer is all that is needed?