Should we put our pricing on the site?

Almost always yes. Hiding it filters out more people who would have bought than people who would have wasted your time, and it reads as expensive. If the number genuinely depends on seats, volume or scope, publish what it depends on and a range. What loses deals is not a high price, it is not being able to tell whether you are in the right order of magnitude.

Webflow, Framer or custom for a SaaS site?

Framer if the next year is mostly about changing the message quickly. Webflow once there is a growing amount of structured content, because its CMS models relationships properly. Custom once the brief involves accounts, an application layer or content in the tens of thousands. The signal you have outgrown a builder is usually the number of embeds needed to make one feature work.

Can the marketing site live alongside the app?

Yes, and it usually should. The marketing site and the product have different release cadences and different editors, so coupling them means a copy change waits on a deploy. Separate them and share the design tokens so they still look like one company.

You need something that shows the company is alive and thinking, and a changelog often does that better than a blog nobody has time to write. Publish whichever one you will actually keep up. An abandoned blog with three posts from last year is worse than no blog.

SaaS & software4 min de lecture

Websites for SaaS and software companies

A site that explains the product to someone who has never seen it, and keeps up when it changes next month.

Best for early and growth-stage software companies whose positioning is still moving faster than their website.

Software companies tend to build the site they wish they needed rather than the one a stranger needs. The stranger has thirty seconds, no context, and three tabs open on your competitors. Almost everything that works on a SaaS site follows from taking that seriously.

Say what it is before you say why it is good

The most common failure is a headline that describes an outcome without ever naming the category. Someone arriving cold cannot tell whether you are a database, an agency or a browser extension, and they will not read the second section to find out.

Name the category, name who it is for, then earn the rest. Positioning that feels obvious to you is invisible to everyone who has not been in your standups for a year.

Publish pricing, or publish the shape of it

Hiding pricing behind a demo request filters out far more people who would have bought than people who would have wasted your time. If the number genuinely depends on scope, say what it depends on and give a range. Silence reads as expensive, and expensive-and-unclear reads as risky.

Build it so the team can change it

Positioning in an early company moves every quarter, and the site has to move with it. If a copy change needs a developer, it will not happen, and six months later the homepage describes a product that no longer exists.

That means a real CMS behind the pages that change most, components a marketer can rearrange, and a structure that survives a repositioning rather than needing a rebuild for one.

Docs and changelog are part of the marketing site

Evaluators read your documentation before they talk to you, and a changelog that shows steady shipping answers the question nobody asks out loud, which is whether you will still exist next year. Both are usually owned by engineering and styled like an afterthought.

A homepage that names the category in the first line
Pricing, or an honest explanation of what it depends on
A CMS the marketing team can actually publish to
Docs and changelog that look like they belong to the same company
Analytics wired to the events that matter, not just pageviews

Your positioning is obvious to you and invisible to everyone who has not sat in your standups for a year.

What a build here actually includes

Every build is scoped to the practice, but on this kind of site these are the parts that are not optional.

Messaging worked out before design starts, because layout cannot rescue an unclear proposition
A component set a marketer can rearrange without filing a ticket
Pricing presented honestly, whether that is a number or the variables behind one
Docs and changelog brought into the same design system as the marketing pages
Event tracking on the actions that mean something, wired at build rather than bolted on

What we keep seeing go wrong

None of these are hypothetical. They are the things that turn up again and again on sites in this vertical, and most of them are cheap to avoid and expensive to undo.

A headline that describes an outcome and never names the category
Pricing replaced by a demo request, which filters out buyers rather than tyre-kickers
A homepage nobody can edit, describing a product from two quarters ago
Documentation that looks like it belongs to a different company
A product tour above the fold, before anyone knows what the product is

Questions we get asked first

Should we put our pricing on the site?: Almost always yes. Hiding it filters out more people who would have bought than people who would have wasted your time, and it reads as expensive. If the number genuinely depends on seats, volume or scope, publish what it depends on and a range. What loses deals is not a high price, it is not being able to tell whether you are in the right order of magnitude.
Webflow, Framer or custom for a SaaS site?: Framer if the next year is mostly about changing the message quickly. Webflow once there is a growing amount of structured content, because its CMS models relationships properly. Custom once the brief involves accounts, an application layer or content in the tens of thousands. The signal you have outgrown a builder is usually the number of embeds needed to make one feature work.
Can the marketing site live alongside the app?: Yes, and it usually should. The marketing site and the product have different release cadences and different editors, so coupling them means a copy change waits on a deploy. Separate them and share the design tokens so they still look like one company.
Do we need a blog?: You need something that shows the company is alive and thinking, and a changelog often does that better than a blog nobody has time to write. Publish whichever one you will actually keep up. An abandoned blog with three posts from last year is worse than no blog.