SaaS website design best practices: what each page has to do

We design and build SaaS marketing sites for a living, so we're not neutral, and we'll say where our own examples are thin. Two of our SaaS site designs, Finsaro and Agentory, are website templates sold to other founders, not sites for a client's own product. The third example is our own website. Every outside fact is linked and was read on 4 November 2026. We've left out the "this lifts conversion by 40%" figures that many guides quote, because we haven't verified them.

First, what is a SaaS website for?

A SaaS website has a different job from a normal company website. A company site says who you are. A SaaS site has to explain a product people can't see yet, and then move them to the next step: a free trial, a demo or a call.

How you sell decides how the site is built:

• Self-serve or free trial. The main button should lead into the product. The site works as the first step of onboarding, so the words on it should match the words inside the app.
• Demo or sales call. The site has to earn the demo. Say what the person will see and what they'll be able to decide afterwards, not just "Book a demo".
• Both. Many products have a trial for small teams and a call for big ones. Pick the main button for the visitor you most want, and make the second one visibly smaller.

Our own SaaS page puts the job in one line: make a stranger understand the product in eight seconds and book a demo in thirty. That's a rule of thumb from our work, not a measured benchmark. It's useful because it forces a choice about what goes first.

The pages a SaaS site needs, and the one job of each

Most SaaS marketing sites are built from the same handful of pages. The mistake is asking every page to do everything. Give each one a single job and a single action.

When we plan a site, the sitemap comes before any design. Each page gets a job and one action, and we agree the list in writing first, because moving a page later moves its search rankings with it. That's how we run our SaaS website design projects, and it costs almost nothing compared with fixing it later.

1. Say what the product does, above the fold

The first screen of the home page has to answer three questions: what is it, who is it for, and what do I get? In our experience, a headline that names an outcome is clearer than one that names a feature, and the worst of the three is one in your own internal jargon. If a visitor has to translate it, most won't.

Why the top of the page matters so much: Nielsen Norman Group, the usability research firm, tracked where people's eyes go on long pages. In its 2018 study, people spent about 57% of their viewing time above the fold, and 74% in the first two screenfuls. The same article says the figure was 80% in 2010, so people scroll more now, and they still look hardest at the top.

When we designed Agentory, a website for AI automation agencies, the problem was that automation is invisible: a lead is scored and a CRM record updated and nobody sees it happen. So the first screen shows the work, with a running pipeline card over a calm landscape photo, and the headline says what the work removes. A hero that has to explain something nobody can see needs to show it, not describe it.

What to put in the hero:

• One sentence that says what the product does, for whom.
• One line under it with the specific result.
• One main button, and at most one smaller one.
• A picture of the product doing its job, not a stock photo.

2. Build the navigation around buyer questions

The menu should read like the questions a buyer asks, in the order they ask them: what is it, how does it work, what does it cost, who else uses it. Keep labels plain. "Pricing" beats a clever word for pricing.

If the site has many pages, a mega menu can carry them. NN/g describes mega menus as big two-dimensional panels, grouped into sections and shown all at once, with no scrolling, and calls them "an excellent design choice" for accommodating many options. Their own examples also show how it goes wrong: groups that aren't visually separate, and labels that are hard to scan. A mega menu with eight similar labels is just a longer list.

Two practical rules from our own builds: every key page should be one click from the home page, and the menu has to work with one thumb on a phone, which means testing it there, not shrinking the desktop one.

3. Show the product early

SaaS buyers can't hold the product, so a screenshot or a short demo is the nearest thing. Show real screens, not a rendering of a laptop with a blurred interface.

For Finsaro, a website template for finance software, the first thing we designed wasn't a page. It was a finance dashboard, for a product that doesn't exist. The final version is built around the week ahead: net worth, cashflow, subscriptions and investments at the top, upcoming payments on a calendar. Then we took it apart, so its cards come back in the feature tiles, and every screen on the site belongs to one believable product. The home page leads with it: the dashboard fills the hero, and the sections beneath take it apart, feature by feature.

The lesson holds for a real product too. If the screenshots on your site look nothing like the app, the first login is a disappointment. Use real screens, cropped to the part that matters, and keep their style consistent with the rest of the page.

4. Put proof next to the claim

A claim with nothing behind it is just a claim. Put the evidence close to it: a customer logo or a number under the headline, a short quote beside the feature it's about, a case study link at the end of the section it belongs to.

What counts as proof, in our rough order of strength:

• A named customer saying a specific thing about a specific result.
• A case study with real numbers and the customer's name.
• Usage numbers you can stand behind.
• Logos of customers who've agreed to be shown.
• Security and compliance badges you actually hold.

Don't invent any of it, and don't leave placeholder numbers on a live page. That sounds obvious, but it's a real risk on templates. On Agentory, every figure on the page is a stand-in, so we designed a slot for each result: hours saved, response times, and less manual work appear in the hero, on each case study and in a results section. The buyer drops in their own numbers and the page keeps arguing in outcomes.

On our own site, the proof is a small set of figures from the build: 24 days from the first line of code to a first version, and +41% enquiries in the first month. Both are on our website case study, next to how we built it. A figure without its context isn't proof, so read the context.

5. Show the price, or a real range

The pricing page is the one buyers go looking for. An NN/g article on B2B sites reports that business customers rank pricing as the most needed piece of information online, and says "we watch participants go to competitors' sites when websites do not show prices". Its advice for products whose price varies is to show sample prices: typical scenarios, a price range, or a starting price.

That article is from 2013 and covers B2B buyers in general, not SaaS buyers specifically, so we'd treat it as a long-standing baseline rather than the latest word.

What a good SaaS pricing page has:

• Plans named for who they're for, not only for their size.
• A side-by-side comparison of what each plan includes.
• The free tier or trial where it exists, not buried.
• Answers to the questions that stall a purchase: refunds, cancelling, billing, upgrades.

Finsaro's pricing page shows three plans side by side, a full comparison table beneath them, and the reassurances people look for before they pay: a refund window, no hidden fees, cancel any time. Every figure on it is a stand-in for the buyer's own. On our pricing page, we publish what we can: fixed-scope projects start from $5,000, and monthly plans are listed with their hours. If you sell something truly custom, a "from" price with the three things that move it is better than silence.

6. One main button, and a second for people who aren't ready

Every page needs a main action, and one is plenty. Put it at the top and again at the end of the page. For the visitors who aren't ready, add a quieter second button that lets them learn more, such as "See how it works" or "Read a case study".

Write the button for the result, not the mechanism: "Start your free trial" or "Book a 30-minute call" beats "Submit". If the button opens a form, tell people what happens after, and how long it takes.

7. Keep forms and sign-up short

Ask for what you need to start the conversation, and nothing else. Everything else can come later, once the person has a reason to give it. The ranking guides quote exact drop-offs per extra field. We haven't verified one, so we don't quote it, but the direction is easy to test on your own site.

Our own contact form asks for a name, an email, an optional WhatsApp number, the kind of project, a budget range and some project details. That's six fields, and only one is optional. If you wouldn't fill a field in yourself on a phone, cut it.

8. Make it fast

Speed is a design decision, not a developer detail. Heavy hero videos, unoptimised screenshots and five fonts all arrive on the visitor's screen before your pitch does.

Google's web.dev gives the thresholds for a good experience, the Core Web Vitals:

web.dev says to measure at the 75th percentile of page loads, split by mobile and desktop, so it's the slow phones that count, not your laptop. The cheapest fixes are in the design: fewer and smaller pictures, one video at most, and a font stack of two. On our own site, every upload is resized and compressed automatically, and our pictures got about a third lighter without anyone touching them.

9. Design the phone version at the same time

In our experience, a link shared in a chat opens on whatever device is nearest, so a first visit can be on a phone even when the purchase happens on a laptop. A site that's broken at 375 pixels loses those people at the first look.

We design desktop and mobile together, so the homepage you see in the first week is already both. Finsaro has its own phone layout for every page, not a squeezed desktop one. The classic bug is a table that pushes the page sideways: one on our own blog measured 472 pixels wide on a 375 pixel screen until we cut it to three columns. Check on a real phone, not only a narrowed browser window.

10. Make it readable for everyone

In our experience, accessibility is cheaper to get right early than to retrofit. The W3C's guideline on contrast says text needs a contrast ratio of at least 4.5:1 against its background, or 3:1 for large text. The W3C counts text as large from 18 point, or 14 point bold. Light grey text and text over a gradient are the first places to check.

The same fixes help everyone: real headings in order, descriptive link text, pictures with alt text, and buttons you can reach with a keyboard.

11. If you're redesigning, protect what already ranks

None of the five top-ranking guides we read cover this, and it's where redesigns lose the most. A redesign that moves every page is how a site loses the traffic it already had.

Our own site was the example. Ten of its fifteen pages were broken or redirected, and none showed up when founders searched for what we do. That's why, in our own FAQ on redesigns, we say that every existing URL is mapped to a new one before launch, and that most traffic lost to a redesign is redirects nobody mapped.

The short version:

1. List every URL on the old site and what it earns.
2. Keep the ones that work; change structure on purpose, not by accident.
3. Map every old URL to a new one before launch.
4. Check the redirects after launch, and keep watching the numbers for a month.

12. Build it so your team can edit it

A site your team can't change is a site that goes stale. We build in Webflow or Framer so marketing can publish a page on a Tuesday afternoon without a ticket, and we set up components and a CMS so new pages come from parts that already exist. That's how a site avoids drifting into fifteen slightly different button styles.

Webflow tends to suit a site with real content behind it, such as a case study library or a changelog. Framer suits a smaller, more visual site that has to move. We compare them in Framer vs Webflow. Our own site is built in code instead, so that AI could build and ship every part of it, and publishing a new case study takes about 15 minutes. That figure is for our site, not for Webflow or Framer. Whichever you pick, the test is the same: can the person who owns the message change it today?

13. Measure, change one thing, measure again

A site is never finished. After launch, look at what people do: where they leave, which pages they read before booking, which buttons get clicked. Fix the page that leaks. Change one thing at a time, or you won't know what worked.

The numbers to watch first are simple: visits to the pricing page, clicks on the main button, form completions, and the share of visits from phones. If you have too few visitors to test, that's useful to know too: talk to five customers about how they found you, and read the answers instead.

A pre-launch checklist

• The home page says what the product does, for whom, in one sentence.
• Every page has one job and one main action.
• The price, or a real price range, is easy to find.
• Proof sits beside the claims, and none of it is made up.
• The site loads fast on a mid-range phone.
• Contrast, headings, alt text and keyboard use are checked.
• Every old URL is mapped, if this is a redesign.
• Someone on your team can edit it without us.

Questions people ask

What makes a good SaaS website?

It says what the product does in the first screen, shows the product, puts proof next to its claims, makes the price easy to find and gives one clear next step. It also loads fast and works on a phone.

What pages does a SaaS website need?

At least a home page, a product or features page, a pricing page and a way to contact or sign up. Most add use cases or solutions, case studies, an about page and a blog or help centre as they grow.

What should a SaaS home page include?

A headline that says what the product does, a line on the result, one main button, a look at the product, proof from real customers, and a short route to pricing.

Should I show pricing on a SaaS website?

Yes, or a real range or starting price. A 2013 NN/g article on B2B sites reports that business buyers rank price as the most needed information, and says its researchers watched participants go to competitors' sites when prices weren't shown.

Free trial or demo?

A free trial or free plan suits a product people can try alone in minutes. A demo suits a product that needs setup, data or several people to decide. Many companies offer both, with one as the main button.

How long does it take to design a SaaS website?

For most of the sites we do, four to eight weeks. The pitch takes two to three days to work out, structure about a week, and design and build run together after that. You see the home page in the first week.

How much does a SaaS website cost?

We quote a fixed price against a written page list before work starts, and the main drivers are how many unique templates there are, how much CMS structure is needed, who writes the copy and whether an old site has to be migrated. Our fixed-scope projects start from $5,000, and the details are on our pricing page.

Webflow or Framer for a SaaS site?

Webflow when there's real content behind the site and search matters. Framer when the site is smaller, more visual and needs motion. See Framer vs Webflow.

Should I hire an agency or build it myself?

If you have a designer and a developer with time, you can. If you'd rather not, our guide to the best SaaS website design agencies lists who we'd look at, us included.

If you're planning a SaaS site or a redesign, book a call and bring your current one, even if it's only the link. We'll tell you what we'd change first, and what our SaaS website design work would cover.