Webflow's visual editor holds up for a brochure site. Here's where it runs out, and why the fix is almost always a developer and a custom code embed.
Key takeaways
- Webflow's visual editor handles hover states and scroll animations well, but not conditional logic tied to real data – that almost always means a custom code embed.
- Custom code embeds are unversioned and invisible to the CMS editor, making them harder to maintain than a normal codebase.
- CMS logic that needs two Collections to reference each other is where Webflow's built-in filtering typically runs out.
"No-code" is the promise on Webflow's homepage, and for a marketing site with a handful of pages it mostly holds. It stops holding the moment the site needs to do something Webflow's visual editor was not built to express – and that moment arrives earlier than most teams expect.
Where the visual editor runs out
Interactions cover hover states, scroll triggers and simple animations well. They do not cover conditional logic – showing a different price to a different visitor segment, gating a section behind a login, or running a calculation across several CMS fields. The moment a client asks for "if this, then that" behaviour tied to real data, the answer is almost always a custom code embed.
Custom code is still code
Webflow lets you drop in raw HTML, CSS and JavaScript per page or site-wide – which is exactly the admission that the visual layer cannot do everything. It works, but it is unversioned, untested, invisible to the CMS editor, and it is the first thing that breaks silently when Webflow ships an unrelated platform update. Someone still has to write and maintain that code; it is just harder to find and harder to review than a normal codebase would be.
What CMS logic actually needs
Reference fields, computed values, content that depends on more than one Collection at once – Webflow's CMS handles simple content well and starts to strain the moment two Collections need to talk to each other in a way the built-in filtering does not cover. That is usually solved with more custom code, or with a workaround content structure that exists only to route around the platform's limits rather than to represent the content naturally.
The developer shows up either way
None of this makes Webflow a bad tool for what it is built for. It does mean that "no-code" quietly becomes "no-code, until it isn't" for any site that grows past a brochure – and at that point, a codebase a developer can actually read and extend is a more honest foundation than an editor with HTML embeds duct-taped in. That is exactly the gap between our Astro + CMS – Basic package and the Collections tier: Basic is for a site that mostly needs the code side; Collections is for one whose CMS logic has already outgrown the visual editor too.
Compare what each package covers, or describe what you're trying to build and we'll tell you whether Webflow can still do it.