A SaaS site has an unusual problem. The product is invisible, the buyer can usually start it themselves, and the competition is one browser tab away. So the site is not a brochure sitting in front of the product. It is the first part of the product experience, and it gets judged in about the same way: can I tell what this does, can I tell what it costs, can I get in. Most SaaS sites lose people on one of those three questions, and it is usually the second.
SaaS website design works when the site does the job the product does: show it, price it, and let people start. That means a homepage built around a visible product, a public pricing page, use case and feature pages, documentation, and one primary call to action chosen by how the product is actually bought.
What pages does a SaaS site actually need?
Fewer than the sitemap you were handed, and probably different ones. Marketing teams tend to build outward from features while buyers move inward from a problem. The result is twelve feature pages, no use case pages, and a pricing page that says contact us.
Here is the set that does real work, with the job each one holds. If a page on your site does not map to a job in this table, it is probably a candidate for merging or deletion.
| Page | Job it does | Primary reader | Success signal |
|---|---|---|---|
| Homepage | Explain the category, the outcome and who it is for in under ten seconds | First time visitor, any role | Scroll past the hero and click through to a specific page |
| Product or platform overview | Show the thing working end to end | Evaluator, end user | Time on page, movement to pricing |
| Feature pages | Answer does it do X, and rank for feature searches | Evaluator comparing tools | Organic entries, movement to trial or pricing |
| Use case or industry pages | Translate features into a familiar workflow | Buyer with a problem, not a spec | Highest converting organic pages, typically |
| Pricing | Qualify, filter and give the internal champion numbers | Everyone, eventually | Most visited non home page in most accounts |
| Comparison and alternatives | Win the shortlist question on your own site | Late stage evaluator | Very high conversion rate, low volume |
| Documentation and API | Clear the technical veto and earn developer trust | Technical evaluator | Rarely converts directly, blocks deals when thin |
| Customers and case studies | Prove it works for a company like theirs | Buyer, champion | Assisted conversions, forwarded links |
| Security and trust | Clear procurement without a sales call | Security, legal, IT | Fewer stalled deals at the compliance step |
| Changelog | Signal that the product is alive and improving | Existing users, cautious buyers | Return visits, reduced churn objections |
Two of those get skipped most often and cost the most when missing: a proper security page, and a changelog. Both answer the quiet question every buyer has about whether this company will still exist and still be shipping in eighteen months.
Why does hiding your pricing cost you?
The argument for hiding price is that it lets sales frame value in context. Sometimes true, mostly for genuinely complex enterprise deals with heavy implementation. For everyone else, hiding price does three things you would not choose deliberately.
It hands the buyer's imagination the job of setting your price, and they usually guess wrong in whichever direction ends the conversation. It removes you from every comparison article, every review roundup and every answer engine response that lists cost, because there is nothing to cite. And it forces a sales call before the buyer is ready, which selects for tyre kickers with time and repels the busy senior person you actually want.
If your pricing genuinely varies by deployment, publish the model rather than the number. Say what the price depends on, name the variables, give a starting point, and give an example configuration with a real total. That is enough for a champion to build an internal case, which is the actual job of the pricing page.
When a client cannot publish list pricing, we build a configurator that returns a range instead of a quote. It asks three or four questions, shows an honest band, and offers a call for the exact figure. In our projects this recovers most of the qualification benefit without leaving the page blank.
How should a pricing page be structured?
Three or four plans is the practical ceiling. Beyond that people stop comparing and start leaving. Anchor with the plan you want most customers on, and make it visually distinct without shouting. Order features by what buyers ask about rather than by what your product roadmap calls them, and write them in the buyer's language, not the internal feature name.
- Name the plans after who they are for, not after metals. Team, Business and Enterprise beats Silver, Gold and Platinum.
- State the billing unit clearly, and say what happens when usage exceeds the tier.
- Show monthly and annual side by side with the actual saving in dollars, not just a percentage.
- Put the top five objection answers directly under the table as a short FAQ, not on a separate page.
- Repeat the trial or demo action at the bottom of the page, because that is where the decision happens.
- Add one short customer quote about value, positioned next to the highest priced plan.
Avoid feature tables that run forty rows deep with checkmarks. If the comparison genuinely needs that much detail, collapse it by default and let people expand what they care about. Also avoid the pattern where the most useful integration sits in the top tier only. Buyers read that as a trap and say so in reviews.
Free trial or demo as the primary call to action?
The right answer follows the product, not fashion. Ask whether a new user can reach a genuinely useful moment on their own within about fifteen minutes. If yes, lead with the trial or a free tier. If the product needs data imported, permissions configured or a workflow mapped before it does anything, a trial just gives people a chance to fail privately, and the demo is the honest option.
| Primary CTA | Fits when | Watch out for |
|---|---|---|
| Free trial, no card | Self serve setup, fast time to value, lower price point | Volume of unqualified signups, activation drop off |
| Free tier | Product has network or usage effects, land and expand model | Cannibalising paid plans if the free limits are too generous |
| Interactive product tour | Complex product, buyers want to look before committing | Tours that show the polished demo account rather than reality |
| Book a demo | Implementation heavy, higher contract value, committee buying | Slow follow up, which wastes the highest intent action you have |
Whichever you lead with, offer the other as a secondary path. Some buyers will never take a call and some will never self serve, and both are real. What does not work is three equally weighted buttons in the header, which reads as indecision and reduces clicks on all of them. If the trial is your primary action, remember that the signup flow is now part of your conversion work, not a separate engineering concern.
How do you show a product nobody can touch?
Screenshots do more than illustration copy ever will, provided they are legible. The most common mistake is a full dashboard shrunk to fit a section, which becomes an unreadable smudge on a phone. Crop to the part that matters, annotate it lightly, and let the caption carry the claim.
Short looping clips of a single action work better than a three minute overview video, because nobody watches three minutes on a first visit. An interactive tour embedded in the page earns its build cost when the product is visual. And be careful with heavily art directed product imagery: floating cards, invented UI and abstract gradients look good in the pitch and disappoint on first login. Buyers notice the gap.
We ask for a real workspace with real data patterns, then design the screenshots around it. Fake data with names like Acme and numbers like 100 percent growth reads as a mockup instantly. Realistic messy data reads as software people actually use.
What homepage structure works for SaaS?
A pattern that holds up across most SaaS categories: a specific hero that names the outcome and the audience, a proof strip, a short section showing the product doing one thing well, two or three use case blocks that link deeper, a differentiation section that says what you do not do, social proof with a real result, a pricing signal, and a closing action.
Two things to resist. The first is explaining your whole product on the homepage, which produces a page nobody finishes. The homepage is a router, and its job is to get people to the right deeper page quickly. The second is chasing a competitor's layout because it looks current. Their homepage was built for their funnel, their price point and their level of category awareness, none of which you can see from outside.
Speed still matters more than any of this. A heavy hero animation that delays the first meaningful paint punishes you on mobile and on paid traffic, where the click is already paid for. If you are buying visits through paid channels, the page weight is a line item. It is worth treating the homepage build as part of the core design and development scope rather than something the marketing team edits into existence over time.
Frequently asked questions
What should a SaaS homepage say above the fold?
Name the outcome, the audience and the category in plain words, then offer one primary action plus a lower commitment alternative. Test it by imagining a competitor pasting your headline onto their site. If it would fit unchanged, it describes the category rather than your product and needs rewriting.
Should a SaaS company publish pricing publicly?
Usually yes. Hiding price removes you from comparison content, makes buyers guess, and forces a sales call too early. If pricing genuinely varies, publish the model, the variables that change it and a worked example with a real total. A contact form alone is the weakest possible pricing page.
Is a free trial better than a demo?
It depends on how fast a new user reaches value. If they can get somewhere useful alone in about fifteen minutes, lead with the trial. If setup needs data, permissions or configuration, a trial lets people fail quietly and a demo works better. Always offer the other route as a secondary option.
How many pages should a SaaS website have at launch?
Usually 15 to 30 pages: homepage, product overview, four to eight feature or use case pages, pricing, comparisons, case studies, security, docs and standard company pages. Expand later based on search demand and the questions sales keeps answering, rather than trying to build every page before launch.
Do comparison pages against competitors work?
They convert better than almost any other page type because they reach people at the shortlist stage. The condition is fairness: describe the competitor accurately, admit where they are stronger, and say who each tool suits. Misleading comparison pages get called out publicly and cost more trust than they earn traffic.
How often should a SaaS site be redesigned?
Full rebuilds every two to three years are common, but steady change matters more. Keep a stable design system and update pages as positioning, pricing and product move. Leaving a site untouched for four years and then replacing everything at once tends to cost ranking and conversion simultaneously.
The takeaway
Judge every page by the job it does rather than by how it looks in the deck. Show the product honestly, publish enough pricing for a champion to build a case internally, and pick a primary action that matches how long your product takes to be useful. Then keep the site moving as the product does, because a SaaS site that has not changed in two years is telling buyers something.