Webflow
Who updates the site after launch decides the platform
The short answer
Webflow suits a marketing site whose content changes often and whose editors aren't technical. The ceiling isn't visual, it's structural: how your content relates to itself, per-item logic, and anything that behaves like an application. Decide who maintains the site after launch first. The platform follows from that answer.
You've been handed two quotes and they don't agree on the platform. One says Webflow, one says a custom build, and nothing in either document tells you which one is protecting you rather than protecting itself. The order below is how we'd work through it, and it settles the platform question near the end rather than at the start.
Start with who maintains the site, not with the platform
The platform question feels like the first decision. It's the second. The first is who changes this site after launch, how often, and how technical they are. Answer that honestly and the shortlist mostly writes itself.
If your marketing lead needs to publish a new service page on a Tuesday afternoon without asking anyone, you need a site where editing is a first-class thing rather than a bolt-on. That's the case Webflow is genuinely good at. If the site changes twice a year and everything else in the project is application work, the editing argument disappears and most of the reason to choose it goes with it.
Two of the sites we've published run on Webflow, one for an accounting firm and one for a refrigeration contractor. Almost nothing about those two businesses is alike, which is the point. The industry doesn't decide this. The case the platform fits is a small team with nobody in-house to hand a codebase to, and content that has to keep moving after the build is finished.
Five checks, in the order that saves you money
Run these in order. Each one can end the decision on its own, and they're arranged so the question that's cheapest to answer comes first. Most projects settle at check three, which is why the platform argument sitting in your inbox is usually happening two steps too early.
None of it needs a technical person. It needs somebody who knows how your business actually publishes, and somebody willing to guess honestly at what the site will be holding in two years.
1. Count the editors and the publishing rhythm
Write down how many people will change the site in a year and how often. One person editing a few times a year, and the editing argument for Webflow mostly disappears. Three people publishing weekly, and it's the strongest argument on the table. This is the only check most non-technical buyers can answer from memory, and it decides more than the rest of them combined.
2. Write the content model down before you shortlist anything
List every kind of thing the site will hold, not every page. Services, locations, case studies, team members, posts. Next to each one, write roughly how many you expect to have in two years. Do this on paper before anyone shows you a platform, because a shortlist drawn up first will quietly shape what you think you need.
3. Check the relationships, not just the totals
Now draw lines between those lists. A post belonging to one category is a simple link, and Webflow handles it well. A case study that pulls in three services, two locations and a named person is a multi-reference relationship, and those carry documented limits on how many nested lists a page can hold and how many items each one shows. Count your busiest page against those limits, which are in the next section, before anyone commits.
4. Separate the pages from anything that behaves like an application
Go through the feature list and mark anything that involves a logged-in person, a record belonging to one customer and not another, or a calculation the site has to run and store. Those are product features, not pages. If that column has more than a couple of entries, the comparison you're running is the wrong one, and the platform question can wait until the product question is settled.
5. Count the custom pieces you'd need on day one
Add up every job the platform can't do on its own: a conditional form, a booking tool, a calculator, anything that has to read a value out of another system. Write each one down next to who would fix it when it breaks. That second column is the real output of this check, and if it says the same name five times, you've found a single point of failure rather than a platform decision.
Where the ceiling actually is
People assume the limit is visual. It isn't. You can build almost any layout in Webflow, and a careful build is indistinguishable from a hand-coded one to anyone outside the project.
The limit is structural. It shows up in how your content relates to itself, in per-item logic, and in anything that behaves like an application rather than a page. A blog with categories is fine. A directory where every entry links to three other entry types, filters on six fields and needs a saved view per user is where you start writing around the platform instead of with it.
It's worth knowing where the documented ceiling sits rather than guessing at it. Two of the limits are fixed and don't move with what you pay: a Collection list displays a maximum of 100 items unless you turn on pagination, and a page can hold ten nested Collection lists, each showing up to a hundred nested items per parent item. The plan limits are a separate question. Since the consolidation Webflow announced in May 2026, its Premium site plan holds 40 Collections and 20,000 items per site, though existing sites move onto it at their next renewal or billing change rather than all at once. A site still on a legacy CMS plan is running against 20 Collections and 2,000 items today, so the ceiling you're actually up against may be lower than the published one. Generous for a marketing site, tight for a directory, and that gap is the whole distinction.
When Webflow is the wrong choice
When the thing you're describing is a product rather than a site. Logged-in users, permissions, records that belong to one customer and not another. Webflow can gate content, and gating content is not the same as an account model.
When the site is the smallest part of the project. If the real work is an integration, a data migration or an internal tool, and the marketing pages are the afterthought, choosing a platform for the afterthought quietly sets the shape of everything around it. Settle the hard part first and let the pages follow it.
When you already have engineers who'll own a codebase anyway. The maintenance argument that makes Webflow worth its constraints is gone, and you're paying to give up control you had a use for.
And when nobody at your company is going to touch the site regardless. A site edited twice a year doesn't need an editing platform. It needs to be fast, cheap to host and boring, and there are plainer ways to get that.
What the work looks like
The build is the short part. Structuring takes the time: working out which content types you actually have, what fields each one needs, and which pieces are components that repeat rather than pages that get copied.
Done properly you end up with a style system and a set of reusable components, so a heading change happens once and lands everywhere. Done badly you get forty pages of one-off layouts. Both look identical on launch day. The difference shows up the first time you ask for a change across the whole site.
We handle design and build, hand the workspace over, and sit with whoever will be editing it so they know what they can safely change. That last part gets skipped more often than it should, and it's the part that decides whether the site still looks like itself a year later.
Ask for a short written record at handover too: which pieces are components, which pages are deliberate one-offs, and where any embedded script sits and what it does. Nobody produces that unprompted. It's the difference between a site your next partner can pick up and one they quote to rebuild.
Webflow, a coded build, and a template product
Three options usually reach the table and they fail in different places. A template product is a layout you fill in. Webflow is a visual builder with a content system underneath it. A coded build is software your company owns. Which one wins depends on how the five checks came back, not on which one the person quoting is most comfortable with.
Our recommendation, when the checks land the way they do for most established businesses that need a marketing site: Webflow. Not because it's better in the abstract, but because the thing that kills these projects is a site nobody can change, and Webflow is the only one of the three that fixes that without putting an engineer between your marketing lead and a typo. Move off it when check three or check four comes back loud.
| What decides it | Template product | Webflow | Coded build |
|---|---|---|---|
| Publishing a new page | Only where the layout allows one | Your marketing lead, same afternoon | A developer and a deploy, unless an editing layer was built in |
| Changing one heading style everywhere | Global, but only inside the theme | Once, if it was built on components | Once, in code |
| Relational content | Rarely more than a blog and categories | Good up to a documented limit, then awkward | Whatever you design |
| Logged-in users, per-customer records | No | Content gating, which is not an account model | Yes, and this is the reason to choose it |
| Design freedom | The theme decides | Effectively unlimited | Effectively unlimited |
| Who you need on staff | Nobody technical | Somebody comfortable editing, not a technical person | An engineer, or a standing arrangement with whoever built it |
| Time to a first launch | Days | Weeks, most of it spent on structure | Months, and the range widens with the feature list |
| What you take with you if you leave | Your text | Content exports cleanly, the build gets rebuilt | The whole codebase, if you own the repository |
A platform recommendation is only as good as its reason
Whoever proposes a platform should be able to tell you what breaks if you outgrow it. If the answer is that nothing breaks, they haven't thought about it, because everything has a ceiling and the useful conversation is about where yours sits.
Our own published advice on choosing a partner puts it plainly: teams tend to propose what they're already comfortable with. That isn't automatically wrong, it just isn't evidence. Ask why this platform, for this content, with this team maintaining it. A good answer names your constraints back to you before it names the product.
Worth knowing before you start
Ask whoever's quoting to tell you which of your content types will be Collections and which will be static pages, and get that list in writing before you sign. Structure is the part you're actually buying, and a team that can't answer without going back to look hasn't read your content yet.
Ask whoever's building it to change one heading style in front of you and watch whether it lands on every page at once. That test takes a minute and it tells you more about what you're buying than any mockup will.
Get the site transferred into a workspace your company owns, with your billing on it, before the final invoice is settled. An agency-owned workspace is easy to set up and awkward to unwind.
If you're inheriting a Webflow site somebody else built, ask to see the Style panel and count the classes. A few dozen reused everywhere is a system. Several hundred one-off classes is a set of pictures, and any quote to change it is guesswork until somebody rebuilds the styles underneath.
Put a date in the calendar six months after launch to read the site as a stranger would. Webflow sites rarely decay technically. They decay editorially, and whatever's live in a year is whatever a busy person had time to write.
Work we’ve done
Further reading
Common questions
Your content moves. The build doesn't. CMS entries export cleanly and can be re-imported almost anywhere, but the design and page structure get rebuilt on the new platform. Knowing that up front is why the content model matters more than the visual design when you're choosing.
A template is a good starting point if it already has the structure you want, and a poor one if you plan to reshape it. Reworking someone else's classes usually costs more than starting clean, because you inherit naming decisions you can't see until you try to change something. Use one to move fast on a site that fits its shape, not to save time on a site that doesn't.
No. It renders static HTML, handles meta tags, redirects and sitemaps properly, and loads quickly by default. Sites built on it rank on the same terms as anything else. If a site isn't ranking, the cause is almost always content, structure or intent rather than the platform underneath it.
Simple forms are built in and they're fine. Anything conditional, multi-step, or that has to check something in another system needs an embedded tool or a small piece of custom work. Count those up front. Two or three is normal. A dozen means you're building an application inside a site builder and paying for the privilege twice.
Yes. Before quoting anything we'd read how it was built rather than how it looks, because two Webflow sites that look identical can be an afternoon apart or a rebuild apart on the same change. You'd get that read first, including the case where rebuilding the styles underneath is the cheaper route.
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.