Positioning lags the roadmap
The product moved into a new segment and the homepage still explains the old one. Sales know the new story; the site has never been told it.
Webflow for SaaS companies
A SaaS marketing site that keeps up with the product
SaaS websites fail operationally before they fail visually. A launch is announced, a use-case page is needed by Thursday, and the person who can build it is in a sprint until next month. Most of what I do here is removing that dependency.
- Marketing autonomy
- Use-case pages
- Qualified demos
What usually goes wrong
The site describes a product that shipped two years ago.
These show up in almost every SaaS site I am asked to look at, and none of them are design problems.
Marketing cannot publish
Every new page is a developer ticket. Campaigns get planned around what the site can already do, which is the wrong way round.
Two audiences, one page
The buyer and the user need different things, and the homepage tries to satisfy both by saying less to each.
Demo requests that go nowhere
The form asks for a call before the visitor knows whether the product fits. The rate looks fine and the pipeline does not.
What I build
A content model shaped like your marketing calendar.
The test of a SaaS site is not the homepage. It is whether the twentieth use-case page can be published by someone who does not write code.
Use cases, integrations, resources
The content that repeats and grows becomes a collection with fields named after meaning, so templates can use it and a redesign later does not mean re-entering everything.
Sections marketing can assemble
An approved set of blocks with properties, so campaign pages get built from a system rather than improvised, and no two landing pages drift apart.
More than one way in
A demo for the ready, documentation and pricing for the evaluating, and a use case for the ones who do not yet know the product solves their problem.
Honest limits
Where Webflow stops being the right answer.
Marketing site, not product
Webflow is for the marketing site. Your app, your billing logic and anything behind a login belong in your product stack. Collection item limits also matter if you publish heavily, and that is worth checking against your plan before the model is fixed rather than after.
Frequently asked questions
Questions connected to this decision.
Can our marketing team really publish without a developer?
For the content types we model together, yes. That is the point of the build. A genuinely new layout still needs someone like me, and the line between the two is agreed in writing.
Can Webflow handle our resource centre?
Usually yes. The thing to check first is volume against your plan limits, because splitting collections later is much more work than choosing correctly now.
Should pricing plans live in the CMS?
Only if the team needs to edit them repeatedly and can manage the relationships. Billing logic stays in the product.
Can you work with our in-house designer?
Yes. Some clients bring finished Figma files, some bring a brand and no site. Both work.
Will a redesign lose our search traffic?
Not if URLs, content and redirects are planned as part of the project. That planning is included, not an extra.
Sources and basis
What supports this page.
Platform capabilities and migration controls reference current documentation rather than claims. No performance or conversion outcome is promised, because none can be promised honestly in advance.
- Manage CMS Collections
Webflow University · Verified 2026-07-19
Reference for collections, fields, references and item limits, which govern what a content model can and cannot do.
- Build with components
Webflow University · Verified 2026-07-19
Current documentation for components and properties, which is what makes a build maintainable rather than a set of copied sections.
- How to move a site with URL changes
Google Search Central · Verified 2026-07-19
Official guidance on URL mapping, redirects and monitoring when a site moves.
Related decisions
