Webflow
What you're actually buying when a quote says Webflow
The short answer
Webflow is a visual builder for websites with a content system and hosting included. You design pages by direct manipulation rather than by writing code, and non-technical staff edit and publish afterwards without a developer. It suits marketing sites whose content keeps moving. It stops where a site starts behaving like an application.
Somebody put Webflow in a proposal and moved on, as though you'd already know what that meant. Wanting it explained before you approve a number is fair. Here's what kind of tool it is, what it's good at, and where it runs out.
Go deeper
Count your content against Webflow's CMS limits before you build, not after
Where Webflow's CMS stops: which limits are structural, which move with your plan, and how to count your own content model before you commit.
The two quotes disagree because one of them thinks you're buying pages
One quote says Webflow, one says build it properly. The line that decides it, what a custom build commits you to, and the split nobody quotes.
The WordPress and Webflow quotes on your desk are pricing two different kinds of purchase
Webflow vs WordPress on maintenance, plugins, ownership and where the spend sits. Who each one suits, stated plainly, including when WordPress wins.
A visual builder with a content system underneath
Strip the marketing away and Webflow is two things bolted together. One is a design surface where you build pages by moving them around on screen instead of typing code. The other is a content store that holds the repeating parts of the site.
What you're arranging is real markup and real styles, not a picture that gets converted later. Webflow removes the typing, not the craft, which is why two Webflow sites can be a world apart in quality and still look alike on launch day.
The content half is the part most proposals never explain.
What an editor touches
Most weeks
Words, images and Collection items, in a view where the layout is locked and nothing structural moves by accident.
What a designer builds
Once, at the start
Page layouts, shared styles and components, plus the Collections that hold repeating content. The shape of the site gets set here.
What Webflow generates
On publish
Ordinary HTML, CSS and JavaScript, built ahead of time rather than assembled for each visitor.
What a visitor receives
Every request
A finished page from Webflow's own hosting and content delivery network. No server of yours involved.
Collections, fields and items, in plain language
Webflow calls that store the CMS, which is accurate and unhelpful. Three words do the work. A Collection is a kind of thing the site holds: services, locations, team members, posts. A field is one blank on that thing, like a name, a photo, or a link to another Collection. An item is one filled-in set of blanks.
You design the layout for a Collection once and every item pours into it. Add the fortieth service and it appears on the listing page, in the sitemap and anywhere else that list shows, with nobody building a page for it.
The cost is that the model gets harder to change the longer the site runs. Adding a field is nothing. Finding out that what you modelled as one Collection was always two means rebuilding everything that touched it. Which content types become Collections gets settled in week one, and the rest of the build sits on that answer.
Hosting comes with it, and that cuts both ways
You don't rent a server for a Webflow site. Publishing pushes the pages onto Webflow's own hosting, with the certificate, the content delivery network, form handling and version history included. Nobody on your side patches anything.
For a business with no technical staff that removes a whole category of problem. It also makes the site and the place it lives one supplier, with no separate host to move to if the relationship sours.
Webflow publishes its plan pricing on its own site and changes it, so check there on the day you're deciding. A site with a content store needs a paid plan, and the plan is what the structural limits get measured against.
Who edits the site after launch is the real question
Most platform arguments happen between two people who will never edit the site, which is why they never resolve. The question that decides it is who changes this site after launch, how often, and how comfortable they are with a computer.
If a marketing lead needs to publish a service page on a Tuesday afternoon without booking anyone's time, first-class editing is worth a lot, and that's what Webflow is genuinely good at. Editors work in a locked view where words, images and Collection items change and the layout can't. That constraint is what makes handing the site to a non-technical colleague reasonable rather than reckless.
If the site changes twice a year and everything hard about the project lives elsewhere, that argument is worth almost nothing, and most of the reason to choose Webflow goes with it.
The platform is the second question and this is the first. A proposal that names one before asking who edits the site is telling you what its author is comfortable building. If your shortlist is Webflow or WordPress, the guide on Webflow versus WordPress works through that comparison.
Where it stops, and it isn't the design
People assume the limit is visual. It isn't. Almost any layout you can draw can be built, and a careful Webflow build is indistinguishable from a hand-coded one.
The limit is structural. It shows up first in how your content relates to itself: one post in one category is easy, while an entry pulling in three other kinds of entry meets documented ceilings on how deeply lists can nest. It shows up again in how much the site holds, since Collections and items are capped by plan. Generous for a marketing site, tight for a directory.
Then there's anything that behaves like an application rather than a page: a logged-in person, a record belonging to one customer and not another, a calculation the site runs and keeps. Webflow can gate content, and gating content is not an account model.
Check your busiest page against those ceilings before you commit. The guide on Webflow's CMS limits sets out the figures, and the guide on Webflow versus a custom build covers when writing code is the better answer.
Template product
Cheap and quick, until you need something the theme never anticipated
Webflow
Design freedom and a content model, inside one company's platform
Coded build
No ceiling, and a codebase somebody has to own for as long as it runs
You fill in someone else's layout
You own the software
- You fill in someone else's layout
Template product
Cheap and quick, until you need something the theme never anticipated
Webflow
Design freedom and a content model, inside one company's platform
Coded build
No ceiling, and a codebase somebody has to own for as long as it runs
- You own the software
Worth knowing before you start
Ask whoever is quoting which of your content types will be Collections and which will be plain pages, and get that list in writing. The content model is what you're buying, and it's expensive to change later.
Ask to see one heading style changed in front of you, and watch whether it lands on every page at once. A site built on shared classes does. Forty one-off layouts don't, and both look identical on launch day.
Get the site into a workspace your own company owns, with your billing on it, before the last invoice is settled. An agency-owned workspace is quick to set up and awkward to unwind.
If you're inheriting a Webflow site somebody else built, open the Style panel and count the classes. A few dozen reused everywhere is a system. Several hundred used once each is a set of pictures, and any quote to change it is a guess.
Common questions
No, and that's most of the point of it. Adding a post, changing a headline, swapping a photo or publishing an item in an existing Collection are things a non-technical person does directly. Structure is different: new page types, new fields and layout changes go back to whoever built it.
No. It publishes ordinary HTML, handles meta tags, redirects and sitemaps properly, and loads quickly by default. Sites on it compete on the same terms as anything else. When one isn't ranking, the cause is almost always its content or its structure.
Content moves and the build doesn't. Collection items export cleanly and import almost anywhere. The design and page structure get rebuilt on whatever comes next. That's why the content model deserves more attention while you're choosing than the visual design does.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.