Published
9 MIN READ
SaaS website: how to structure your product website
A SaaS website is not a landing page. It's a set of pages that has to sell, explain and support the product at the same time: home, features, pricing, case studies, documentation and changelog. A landing page handles a campaign. The product website handles the entire buying cycle.
That distinction barely shows up in Portuguese. Search for the topic and you get landing page templates or content on how to build the software, which are two different things from this one. This article covers the third: the page structure a product sold by subscription needs, and what changes in each page as the product matures.
What is a SaaS website and why isn't it a landing page?
A landing page exists for a single decision, almost always coming from a paid campaign. It has one argument, one proof and one button. It works very well for what it was made for and fails when someone shows up with a different question.
A SaaS website receives audiences at different stages in the same week. Someone who has never heard of the product, someone comparing three options, someone who is already a customer looking for documentation and someone from procurement trying to understand the billing model. A single page can't hold those four conversations. Whoever tries to solve everything in one landing page ends up with copy that doesn't work for any of the four.
If the product doesn't exist yet or hasn't sold, the conversation is different and a single page is still the right answer. Check what to put on the website before there's a product before investing in a full structure.
The pages every SaaS website needs
The list below is not a ceiling but a minimum. Each row answers a question someone is going to ask, and the page exists so the answer doesn't depend on a meeting.
Page | Question it answers | When it comes in |
|---|---|---|
Home | What problem this solves, and for whom | from day one |
Features | How the product solves it, in practice | when there's more than one use case |
Pricing | How much it costs and what limits each plan | as soon as there's a defined plan |
Case studies or customers | Did it work for someone like me | with the first customer who authorizes it |
Documentation | How do I use it without talking to anyone | when the product requires setup |
Changelog | Is this still being maintained | when releases are frequent |
Blog | Do you know the subject | when there's someone to write |
The last two rows are what most separate a SaaS website from an ordinary corporate website. Documentation and changelog are living content, published every week, and that's what sets the technical requirements of the project.
How should you structure the pricing page?
With the price visible, whenever there is one. Hiding the price behind a form only works when the ticket is high and the sale is truly consultative. In every other case, the visitor reads the absence as too expensive or disorganized, and leaves to compare with whoever publishes it.
The structure that works has four parts: plans side by side with what limits each one, the billing unit stated without ambiguity, what happens when you go over the limit, and a block of frequently asked questions addressing the real commercial objections. The most common question on a pricing page isn't how much it costs. It's what happens if I grow.
How the product itself is built changes what fits on that page. On that, it helps to understand the product behind the pricing page, because a plan limit is an architecture decision before it's a marketing decision.
Trial, demo or form: what should you ask the visitor for?
It depends on the ticket and how much the product explains itself. A simple, cheap product calls for an immediate trial. An expensive, configurable product calls for a conversation. The common mistake is copying the model of a company with a completely different ticket from yours.
There's public data that helps decide. According to ChartMogul's conversion report with ProductLed, from January 2026, which analyzed 200 B2B products, the median free-to-paid conversion was 8%. The more interesting cut is another one: trials that require a credit card convert at around 30%, more than five times the result of those that don't.
That doesn't mean asking for a card is always better. It means asking for a card filters, and filtering early is usually worth more than signup volume. Deciding which ask to put on the page is the same discussion as deciding what the visitor's next step is, applied to a subscription product.
Whatever the ask, the product needs to be shown working before it. A short video of the real interface convinces more than any description, and it's worth recording the product demo with marketing-piece quality instead of improvising a screenshot.
Docs, changelog and blog: what the CMS has to handle
This is the technical requirement that defines the project. Documentation grows nonstop, the changelog is published with every release and the blog piles up. Before long, an active SaaS website has more content-generated pages than hand-designed pages.
In practice that means choosing a platform that can handle real content collections and letting the team publish without depending on a developer. Framer's official pricing page, checked in September 2026, gives the yardstick for this kind of requirement: the mid-tier plan covers 10 collections and 2,500 items, with extra capacity sold separately up to 40,000 items.
Two points are usually left out of the budget. The first is who writes: documentation without an owner ages fast and becomes a liability. The second is the platform that gives you a CMS for docs and changelog without turning into an engineering project. And there's the recurring cost of whoever updates the changelog and docs every week, which rarely comes up before the website exists.
Product website and app: where does one end and the other begin?
It ends at login. Everything that exists before you sign in is website: public, indexable, made to convince. Everything after is product: private, functional, made to be used. Mixing the two is the source of half the SaaS website problems that reach us.
When the boundary gets blurry, familiar symptoms show up: marketing pages inside the app, sensitive data on a public page, or a website only the engineering team can change, which stalls marketing. Defining the boundary early avoids expensive rework later, and the full discussion is in the boundary between the website and the system.
Common mistakes on a SaaS website
The five below show up often in the products that reach us, and they all share the same root: treating the website as a launch piece and not as part of the operation. Fixing it later costs more than structuring it right from the start.
Describing features instead of outcomes. The feature list doesn't say what changes in the buyer's life. A feature is a means; the outcome is what you sell.
Hiding the price for no reason. It only makes sense in a high-ticket consultative sale. Everywhere else, it drives away people who were ready to buy.
Documentation as an attachment. Treated as a leftover of the project, it ages and becomes the main reason for support tickets.
An abandoned changelog. A changelog that hasn't moved in eight months communicates exactly the opposite of what it exists to communicate.
A website only the developer can edit. If publishing a piece of copy requires opening an engineering ticket, the content simply stops.
How much a SaaS website costs and what changes by stage
A product website with a full structure falls in the range of US$ 2,000 to US$ 8,000, and what moves the price within it is the number of pages with their own layout, who writes the copy and how much of the motion is custom-made. A product with a logged-in area and integrations is a different calculation, in the range of US$ 4,000 to US$ 20,000.
The most economical path is to build in layers, following the product's maturity. Home and pricing first, features when there's more than one use case, documentation when setup requires it, changelog when release frequency justifies it. The full yardstick by project type is in the budget for a website with many pages and integrations.
Frequently asked questions
Should I show the price on my SaaS website?
Yes, whenever there's a defined plan. Hiding the price is only justified in a consultative sale with a high ticket and variable scope. In other cases, the visitor reads the absence as a high price or a lack of clarity and goes to compare with whoever publishes it.
What's the difference between a landing page and a SaaS website?
A landing page serves a single decision, almost always coming from a paid campaign. The product website serves audiences at different stages at the same time, from the curious visitor to the customer looking for documentation. One doesn't replace the other, and many companies keep both.
Do I need a blog on the product website?
Only if there's someone to write consistently. A stalled blog signals abandonment and works against you. If the choice is between an irregular blog and well-maintained documentation, the documentation delivers more, because it serves customers and also attracts searches from people looking for a solution.
Should the SaaS website be on the same domain as the app?
Usually yes, with the product on a subdomain or on a path after login. Separate domains fragment search authority and confuse existing customers. What matters is a clear boundary: public before login, private after.
How long does it take to build a SaaS website?
4 to 6 weeks for the initial structure with home, features and pricing. Documentation and changelog usually come in a second phase, because they depend on content the product team needs to produce and maintain. What stretches the timeline most isn't building the pages, it's defining what each one will say.
If you're structuring your product's website now, it's worth talking to Wama about your product's website. A good part of our portfolio is SaaS, with website, system and app living together in the same project.
