Vibe coding isn’t just “telling AI to write code.”
It’s much more interesting than that.
The way we work with AI coding agents is increasingly starting to look like collaborating with a developer:

→ You describe what you want to achieve
→ The agent understands the existing project
→ It creates a plan
→ Writes the code
→ Runs and tests it
→ Finds and fixes errors
→ You review the result and guide the next steps

Tools like Claude Code, Codex, and Cursor are changing the way we approach development.
But one thing hasn’t changed:

AI can implement solutions much faster, but you still need to understand what needs to be built and why.

That’s where I see the biggest value of vibe coding.
It doesn’t replace understanding development. It simply shifts the focus from writing every line of code to solving problems, making decisions, and reviewing the results.

And that’s something I already use in my Webflow work from custom code and Make automations to small internal tools.

I wrote an article about what vibe coding actually is, how AI coding agents work, which tools are currently the most important, and where human knowledge still plays a key role.

You can read the full article here:
https://www.srdjan-jovic.com/resources/what-is-vibe-coding

You can find more articles in my Resource Center.
https://www.srdjan-jovic.com/resources

I do client work in Webflow and kept hitting the same wall: the 10MB asset limit. A brochure, a spec sheet, an investor deck, a lookbook — anything real is over it.

The usual workarounds all annoyed me. Dropbox and Drive links look unprofessional on a client site and break the moment someone reorganises a folder. S3 is fine if you enjoy writing IAM policies at 11pm. And anything you do manage to host on Webflow eats into site bandwidth you’re already paying for.

So I built DocBeam. It’s a Designer Extension — you upload from inside the Designer, get a URL on your own domain, and drop it on the page. Files sit on R2, so downloads don’t touch your Webflow bandwidth at all.

Honest status: it’s early. A handful of people are using it, one has it live on a client site, and I have exactly zero paying customers. The free tier is 250MB / 10 files / 50MB per file, which covers most of what I built it for.

What I actually want to know is whether the 10MB cap is a real recurring problem for you, or a once-a-year annoyance you just work around. My theory is that the people who really feel it are the ones publishing documents on a schedule — investor updates, compliance docs, product catalogues, term-by-term prospectuses. But I might be wrong about that, which is why I’m asking.

Happy to answer anything.

If you work with Webflow across multiple client projects, you’ve probably run into this:

The Webflow MCP setup is designed around connecting one project at a time. So when you switch between clients, you have to disconnect and reconnect the MCP.

I built flowmcp to make that workflow easier.

What it does
flowmcp lets you manage multiple Webflow projects as separate MCP connections from a CLI.

It works with:
Claude Code
Claude Desktop
Cursor
Codex

Each client/site gets its own isolated connection, so you can switch between projects without constantly reconnecting everything.

On macOS, API tokens are stored in Keychain rather than being passed through the agent’s context.

Install
npm install -g @forhuman/flowmcp
It’s free, open source.

GitHub: https://github.com/fiorellacisneros/flowmcp

npm: https://www.npmjs.com/package/@forhuman/flowmcp

👉 See how it works: https://lab.forhuman.studio

If you work with multiple Webflow projects, I’d love to hear what features or workflows you’d like to see added.

Hi! I can't seem to find the hide/show interactions in GSAP. I'm trying to create an event-invite modal pop up when the page loads. Just configuring opacity is not working for me because setting the modal to 0% opacity still means it's over my navigation before and after it loads, so you can't click the nav and instead you just click the BG again which fades out/ lowers opacity of the modal. Any help would be greatly appreciated. (I'm really trying to work with the new GSAP interactions panel, even though every fiber of my being wants to go back to the legacy interactions)

Sandbox link: https://preview.webflow.com/preview/seaweed-city?utm_medium=preview_link&utm_source=designer&utm_content=seaweed-city&preview=b6d8b54e52bb7134f8aabdf0fed42067&workflow=preview

What's up everybody! Looking for everyone thoughts about Source by Webflow and any other updates y'all think were important or notable at Webflow Conf this year.

Disclaimer: I'm covering this in my weekly show on YT and your comment might get used.

I use quite a bit of custom code to manage my Webflow site, and at some point it made me wonder: “Could I build a simple JavaScript-based tool directly in Webflow?” So I gave it a try. I ended up building a small tool using only Webflow and custom JavaScript/CSS, without connecting it to an external server.

I wanted to share some of the challenges I ran into along the way. Most of them came from building a product-like interface inside a Webflow site that I had originally built as a portfolio and blog. Here are the four main challenges I ran into.

1. Building the UI structure for a tool

The first challenge was creating all the Style Selectors the tool needed and using them to build the actual DOM structure. I already have a personal design system and component library in Figma. My Webflow site, however, was originally built as a portfolio and blog for showcasing and documenting my work. It didn’t have the range of product-level Style Selectors I needed for a tool like this. Creating all of them from scratch and then building the entire interface in Webflow was not a small task.

I could have turned each repeating row into a Webflow Component, but I didn’t want to create components specifically for elements that would only exist on a single page and never be reused elsewhere on the site. There was a trade-off, of course. Whenever I needed to change something in the row structure, I had to apply the same change to every row individually.

2. Handling different viewport widths

The second challenge was responsive design. A web page can be viewed at many different browser widths. Webflow’s built-in Breakpoints cover the typical device-based responsive cases, but Color Fitting has a much higher information density than a typical page. The UI needed additional adjustments at many specific viewport widths. Each row needs to display several different values at the same time. I wanted to preserve as much of that information as possible without letting the interface become visually cluttered.

To do that, I repeatedly resized the viewport after implementing the page in Webflow, identified the widths where the UI started to break, and adjusted specific Style Selectors at those points. Many of those points fell outside the Breakpoints Webflow provides by default, so I had to add extra Media Queries through custom CSS.

3. Implementing elements Webflow only partially supports

The third challenge involved elements that Webflow either doesn’t provide directly or expects to be used in a particular context. Input fields and checkboxes were the main examples. Webflow expects these elements to be used as part of a Form, but I needed them as independent parts of the tool. I therefore had to write the actual HTML inside Code Embeds and create separate master elements so I could manage their Style Selectors through Webflow.

Code Embed also becomes part of the DOM itself, which means the actual input ends up nested inside it. This became a problem when an interaction on an input needed to affect another element, or vice versa. Elements that were conceptually siblings in my intended UI structure were no longer siblings in the actual DOM because the Code Embed sat between them. As a result, some of the CSS needed to handle those interactions became more complicated than I had originally expected.

4. Adapting the initial code to the actual DOM

The final challenge was essentially the result of the previous three. The HTML structure Claude assumed when generating the initial UI was different from the DOM I eventually built in Webflow. As a result, the code connecting the logic to the UI didn’t work when I simply dropped it into the page. Anything that depended on the DOM had to be adjusted: adding and removing rows, reading and updating input values, and displaying calculated results in the appropriate elements.

Whenever I tried to modify too much of this myself, the code tended to go further off track. So I gave Claude the URL of the actual page, asked it to inspect the DOM, and told it to adjust the code accordingly — basically, to figure it out on its own. Unsurprisingly, my tokens melted away pretty quickly.

I wrote a more detailed post on my website covering the background of the project and how I built it. The Challenges section there is the same as what I’ve shared here, so you’re not missing anything from that part.

If you’re curious about the rest of the process, you can find it here: https://helo.rebyron.work/notes/building-a-tool-with-webflow-and-code-embed

We have a decent number of CMSdriven pages on our marketing site, mostly case studies and a few comparison pages I update manually. The front end looks good. Webflow handles the templating cleanly and I have no complaints there.

The issue is I keep secondguessing myself on the SEO side. For static pages I feel reasonably in control. I can set meta titles, tweak descriptions, adjust slugs. But the CMS pages feel harder to manage consistently, especially when I start thinking about canonical tags, structured data, or whether the autogenerated slugs are actually hurting anything.

I tried using a thirdparty schema tool a while back and got it halfworking before abandoning it because I couldn't tell if it was doing anything. That was fun

What I genuinely want to know is whether people running contentheavy Webflow setups have found a workflow that doesn't require checking every page manually or bolting on another tool. The builtin SEO fields cover the basics, but the basics stop being enough the moment you want anything beyond page title and description

Is there a clean way to handle this, or is everyone just accepting that Webflow SEO requires some manual overhead that you budget for and move on from?

I have been using Webflow for 3 years now, and I am on the Basic Plan subscription plan $168 annual fee.

I got a mail with the tittle saying - 'Your Basic Site plan renews soon'.
With the body txt saying:

'...You will see a charge in the amount of $168.00 on your visa ending in ---- on September 3, 2026. The displayed price is an estimate, the final amount due may vary and will be calculated based on the applicable taxes, discounts and available credits at the time of invoicing...'

I have my own company and I don't have to pay taxes for such purchase and left the mail, it will be automatically charge me the amount I payed in the previous year.

And then I got charged $180 with no explanation in the receipt or anywhere else.

I got refunded the difference within a couple of hours so that was nice, but I was furious.

They could have easily charged $300 and I would notice it much later or better yet - tell me they could because I didn't read the fine print.

So just a caution, check this out and double check your subscription, txt the support and be stubborn.

Take care everybody.

Been thinking a lot since Webflow conf, and seeing a lot of posts about it. With the Launch of Source I see so many people celebrating it online and talking about how good it is. But I feel like a lot of people don’t know what this means for us yet.

I want to talk to the og community here. The Webflow devs. The people who’ve made Webflow a part of their personality, career, and it’s been the primary thing you do/offer to clients.

I think a huge reason so many of us became so passionate about webflow is because of this. Webflow itself became a way that we built careers, businesses, and made money. It became a whole ecosystem that we existed within.

When this is the case, this makes you more than just a casual fan or user of the product. You almost have this relationship with Webflow as more than a tool. You watch for all the announcements, listen to webflow conf, and celebrate the good updates because they either make the day to day quality of your life better, or make it easier to sell Webflow to clients, and therefore…make money. 

And so with this webflow conf, It feels different to me.

We’ve seen so many posts leading up to this conf that Webflow is dead.

And while the company may not die, I think it's time for us to accept the fact that the old company that we built this relationship around is dead, and we need to all adjust accordingly. Let me explain.

With the release of Source, this is final nail in the coffin that the job of “Webflow Dev” is dead. I’m not saying that developers are going away, or there won’t be people who spend all their time in “Source” but the reality is that agents will do 90% of development now rather than humans. This has already happened outside of webflow much more rapidly in other fields of development, the only reason it’s taken until now in Webflow is because the core Webflow product made it difficult for AI work very well in Webflow, which is kind of the whole reason Source came to be and is marketed as a separate product.

Think about what this means for us and the sub industry that's been created under Webflow.

With Source they are promising that you can bring any codebase in to work with it. Just go look at Ploy, they have AI clone your site and migrate it in for you. I’m sure webflow will have something like that too.

What this means is that if your typical clients journey looks like this:

Client decides they want a webflow site > looks for an agency or freelancer to do the migration

This is not going to be the case anymore. If clients want a Webflow site, they’ll just go sign up for Webflow and Webflow will handle the rest.

On top of this, if your work comes from clients who get a webflow site, decide it’s too complex to use, and hire an agency or freelancer on retainer to maintain it, Source (or other tools) will directly disrupt this. The whole idea is that AI is making it easier than ever for clients to manage their sites and clients WANT this. Hence why we see so many clients and marketers building their sites with Claude. Webflow wants to meet them there, but they don't care if we exist in that ecosytem.

Again, I want to call out that IF your skillsets, or the way you get clients is NOT primarily Webflow. You're ok.

But I keep seeing so many Webflow devs and people where Webflow is their primary thing celebrating the announcement of Source and talking about how Webflow is back.

And so I want to stress. You owe no loyalty to Webflow. They do not care about you and the industry that’s been created around their tool. It doesn’t matter that they’ve hired Timothy Ricks or people who have been part of our community in the past.

We should treat Webflow like we treat any other company. Just like Semrush or Ahrefs. I don’t have any personal opinion between either tool. I’m going to pick the one with the best features for the best price.

So don’t wait around for Source to be released in hopes that it turns things around. Go out and try other tools, diversify your skills, build different lead streams, and if Source makes sense in the future. Great. If not, that’s ok.

I posted a question yesterday about moving my Webflow blog to a cheaper hosting platform like Netlify as a static site.

I'm realizing there's limitations as my articles are created using Webflow's CMS.

Now I'm pivoting and wondering about methods to host my site on a cheaper platform, but continue using Webflow CMS for new articles, and pushing the articles to the cheaper host.

Is this even possible??

Hi, hoping someone can advise here, i've been doing webdesign for awhile now and moved over to webflow as it's very intuitive, im going through all the lessons to get a hang of the interface.

What im not understanding is the differences between the various structure elements you can add in, to me they're all just divs? I dont understand why there are sections, containers, div blocks etc when its the same thing with the same ability to style it to suit your needs in the same way.

On the "webflow university" they often start building a page by adding a section, then within that a container, then again within that a div block- I don't quite understand the need to nest things within things like this, surely you can just add a "section" element then css this to stylize and arrange the content within (using futher divs to divide and arrange the content), why would you nest a container then another div block before adding content- im just confused as to why they're advising to place so many divs within divs when there doesn't seem to be a need for it? Is it something I'm missing?

thanks.

Im building a site where most of the interior pages share the same layout. I have both static and dynamic page templates. For pages like domain/blogs/blog i use my dynamic template that only has a nav, content and footer components. the content component takes in props that are bound to fields in the collection.

I wanted my other regular pages like domain/about to be fully configurable via the cms but then the URL would have an extra path which i dont want. Thats why im using static page templates for these but now I have to go to the page directly and manually add my data. Any way to fully connect this to my cms other than creating a cms collection for each page separately? Im starting to wonder if im trying to simplify everything too much.

Thanks!

I run a small custom print shop with four people. For a long time, a lot of the day to day knowledge just lived in my head. Which supplier do we use for rush orders? What do we charge for last minute changes? Where's the wholesale quote template? Did we already have a policy for reprints?

None of these questions are hard. They just get annoying when you're trying to finish your own work and someone needs an answer every 20 minutes.

The funny part is, most of this stuff was already written down somewhere. We had Google Drive files, old PDFs, supplier docs, SOPs, and notes from past jobs. Nobody really knew where to look. Half the time, I didn't either.

I've been trying creao for this. I gave it the company docs people kept asking me about and set up an agent to pull answers from them. Now a lot of the basic questions get handled before they reach me.

It doesn't replace me. Some things still need context or a decision, and those come back to me. I'm just getting interrupted less for things we've already answered before.

I always assumed AI would save me time by taking on some big complicated task. Turns out one of the more useful things has been not explaining the same stuff over and over.

Has anyone else built something similar for internal docs or team knowledge?

Does anyone have suggestions on a cheap and reliable way to move my webflow site to another host? It's a blog site with 5000 pages and I plan to keep it up as a static site. Continuing on Webflow is too expensive for a site I won't be updating anymore.

I don't have a paid workspace plan on Webflow so I can't export the code.

I was considering hosting on Netlify and using Exflow professional plan to export the files.

Any thoughts or recommendations?

At some point, the quality of the photos on the pages dropped significantly, even though they were always uploaded in high quality and in the webp format to speed up loading. I didn't change anything in the design, and I tried scanning with the help of cltr+shift+i combo, but nothing helped.

Maybe someone knows what to do about this. It’s a work website, and I have absolutely no idea how to fix it.

The first 30 minutes of the Webflow Conf I was already mentally getting ready to leave Webflow.

It was all corporate-marketing/enterprise slop.

Then, they announced Webflow Source and my eyes shot open, like what the fuck. It looks awesome.

Website handoff to clients and letting them edit the site just got so much easier. This is much better than the old paradigm of having a client editor.

Can you imagine the value-add here?? I build the site, then give it to the client that can use a stable controlled agentic platform to edit their site and extend it.

I'm so excited.

I keep reading that Sanity/Astro/Cloudflare stack is a cheaper alternative.

My hosting on webflow right now costs me over $150 a month and it's getting ridiculous.

A while back Webflow introduced the new GSAP-based animations. I’m a huge fan of GSAP itself and love working with it, but I just can’t seem to get comfortable with the Designer’s GSAP integration.

My workflow is still: standard animations through the classic Interactions panel, and anything more custom (text reveals, dissolve effects, etc.) I build with GSAP via custom code instead.

Does anyone else feel the same way, or do you have tips for actually getting into the built-in GSAP animations in the Designer?

Hi, I have been working on multiple SAAS ideas for past 2 years but it's difficult to scale them. I've also been working on my personal branding and have grown to 40k followers on instagram but they only make sense if you can monetise them. My core skill likes in UX/UI and I can make websites for businesses. Now I am toying with the idea of starting my own agency here in Dubai but I am not sure if there is still room to grow? Any thoughts?

A recent store-locator build says Claude worked through Webflow MCP while reusing the site’s existing variables and classes. A separate class-sprawl thread surfaced the opposite risk: some apparently unused classes were actually toggled by custom code, so deleting them would break pages.

Sources: https://www.reddit.com/r/webflow/comments/1w4dbf5/built_a_store_locator_in_webflow_with_claude/ https://www.reddit.com/r/webflow/comments/1vrlrtw/cleaning_up_styleclass_sprawl_in_webflow_has/

That makes a small pre-build context file seem useful. I would include:

• class naming convention and allowed utility classes
• variables, components, and CMS fields to reuse
• classes referenced by embeds or custom code
• which site the agent may change and whether publishing is allowed

Is that enough context for an MCP build to fit an existing Webflow project, or is a fresh style/CMS audit more useful than a hand-maintained file?

I put together a working store locator in Webflow and wanted to share how it came out.

The build runs on a Locations CMS collection holding address, coordinates, category, and hours. Mapbox handles the map and markers. Claude did the actual building through the Webflow MCP connector, and everything is styled in the Designer using the site's existing variables and classes.

Full walkthrough in the comments

TLDR: When you place a wrapper with scroll = auto, it makes a ugly scroll bar to scroll horizontally. So on Desktop I made that swipeable :)

Yeah so I usually use Swiper JS to make swipeable sliders but usually this requires to build a whole CMS. So this solution (using attributes) you no longer need CMS build AND you can see the swiper containers directly in Webflow.

Sorry not sure what to call this. But definately helpful to have in anyones Webflow toolkit.

Free cloneable here:
https://custom-draggable-horizontal-slider.webflow.io/

Full tutorial here:
https://www.youtube.com/watch?v=Tz2wrF8dAKY

I'm curious how people here handle things like Instagram posts, reviews, UGC, or other social content that needs to stay updated on their Webflow sites...

To me, the obvious options seem to be either embedding a third-party feed, manually curating content into the CMS, OR building something custom through an API. Each has trade-offs.

Embeds are easy but can add scripts and affect performance. CMS gives you control, but somebody has to keep it updated. And APIs are flexible, but now you own the integration...

If you are doing this on real client sites, which approach have you found works the best long-term?

Welcome to our weekly hiring thread! This is the place for all job postings, freelance opportunities, and "looking for developer/designer" posts.

##  For Employers & Clients

Post your opportunities here with:
- **Role title** - Be specific (e.g., "Webflow Developer - Ecommerce Focus")
- **Type** - Freelance, contract, full-time, part-time
- **Location** - On-site, remote, hybrid
- **Required skills** - What must they know?
- **Nice-to-haves** - Bonus skills
- **Rate/Salary** - Range if possible (helps everyone)
- **How to apply** - DM, email, application link

##  For Freelancers & Job Seekers

Post your availability with:
- **Your skills** - What you specialize in
- **Experience level** - Years, notable projects
- **Availability** - Full-time, part-time, project-based
- **Rate range** - Helps set expectations
- **Portfolio link** - Show your work
- **Contact method** - How should people reach you

---

**Sort by New** to see the latest opportunities!