SaaS Company

The site gets visited many times, by different people

Most small businesses get one visit from one person who decides on the spot. A software company almost never does. Someone hears your product mentioned in a forum, opens your homepage for a few seconds, and leaves. A week later they come back and look at features. Then they open your pricing page next to two competitors. Then they paste a link into a team chat for a colleague who has never heard of you. If the deal is big enough, someone in finance or IT turns up with a list of questions you never thought your website would have to answer.

So it helps to plan a SaaS website around those visits, not around a list of pages. Each visit has a different reader, a different question, and a different reason to leave. Once you can see them clearly, the structure of the site mostly follows. Not every product goes through all five. A cheap tool bought by one freelancer might only need the first three. A product sold to companies with an IT department needs all of them, plus a sales conversation.

Visit one: the few seconds where someone decides what you are

The first visit is usually short and often accidental. The visitor clicked a link, a review, or an ad, and they're trying to answer one question: what is this, and is it for someone like me? If they can't answer that fast, they leave and you never find out they were there.

The usual mistake is a headline that describes an aspiration, not a product. "Work smarter together" or "The future of operations" could be printed on the homepage of a thousand companies. Founders write lines like this because they're afraid that naming the product plainly will make it sound small. Usually the opposite happens: the plain description is what tells the right visitor they've found what they were looking for.

A useful test is to write the headline as if you were explaining the product to a stranger at a conference. "Scheduling software for physiotherapy clinics" is less exciting than "Reimagine patient care", but a clinic owner knows straight away that it's for them. If the product creates a new category, or does something people don't have a word for yet, explain it by what it replaces: "Stop chasing timesheets over email." Naming the old, painful way of doing things is often clearer than naming the new thing.

Under the headline, the first screen should show the product itself. A real screenshot or a short looping clip of the interface does more than any illustration, because it proves the product exists and gives the visitor a quick sense of how complicated it is. Abstract artwork, stock photos of people smiling at laptops, and 3D shapes all suggest you don't have much to show.

Put one primary action on that first screen, whether it's "Start free" or "Book a demo". You'll probably want a secondary link too, such as "See how it works", for people who aren't ready yet. More than two choices at this point tends to stall people.

Visit two: the person who will use it, checking whether it does their job

The second visit is from someone who is now taking you seriously. Usually this is the person who will use the product every day, and they're checking against a specific job they need done. They aren't reading your feature list for fun. They're looking for the one or two things that would rule you out.

That's why organising features by what the customer is trying to do works better than organising them by how your codebase is structured. A list headed "Automations, Integrations, Permissions, Reporting" makes the visitor translate your words into their problem. Sections like "Send invoices automatically when a job is marked complete" or "Let clients approve work without creating an account" do the translating for them. Each section should pair a short explanation with a screenshot of that exact part of the product, so the visitor sees the thing working and doesn't have to take your word for it.

Say who it's not for

It feels risky, but saying clearly what the product doesn't do, or who it isn't built for, saves both sides time. If you only support teams up to a certain size, or you don't handle a workflow a competitor is known for, the evaluator will find out eventually. If they find out from you, early, they trust everything else you say more. If they find out after a two-week trial, they feel misled and tell people so.

Integrations are often the deciding detail

For a lot of software, the real question is "does it connect to what we already use?" If integrations matter in your market, give them their own page with every one listed by name, a line on what each connection actually does, and an honest note where a connection goes through a third-party tool and isn't native. A logo wall with no detail invites suspicion, because evaluators have all been burned by an integration that turned out to sync one field once a day.

How it works, for products that need explaining

If getting started takes setup, such as importing data, connecting an account, or inviting a team, a short "how it works" sequence of three or four steps answers the unspoken worry that adopting your product will be a project. Only include it if it makes setup look easier than the visitor feared. If setup really is involved, say so and explain what help you provide.

Visit three: the comparison tab, open next to two competitors

At some point your site gets read side by side with alternatives. The visitor is switching tabs and looking for differences. If they can't spot any, they fall back on price or on whichever brand they've heard of.

You can either let them do this work alone or help. Comparison pages, written as "Us vs. [Competitor]" or "Alternatives to [Competitor]", meet people at exactly this moment. They only work if they're fair. A table where you win every row is obviously marketing, and the reader discounts the whole page. A page that says plainly where the competitor is stronger and who should choose them, and then explains who should choose you, reads as advice. Readers can tell the difference.

Keep these pages factual and up to date. Competitors change their pricing and features, and an out-of-date claim about a rival is worse than no claim at all. It looks careless at best and dishonest at worst. If you can't commit to checking them every few months, write about the approach you take ("why we built this for small teams and not enterprises") instead of naming rivals.

Proof from customers matters most during this visit, because it's the clearest way to separate two products that look alike on paper. The useful kind is specific: a named person, their role, their company, and what changed. "We cut month-end close from four days to one" from an identified finance lead is evidence. "Great product, highly recommend!" from "Sarah K." is decoration. Short case studies built around a customer that looks like your target buyer work better than a large number of vague quotes. If you're early and don't have many customers, a few honest, detailed stories beat a wall of logos you had to stretch to collect.

Visit four: the pricing page, read by someone doing maths

The pricing page is often one of the most visited pages on a software site. The person reading it isn't skimming. They're working out what they would actually pay with their team size, their usage, and their likely growth, and they're looking for the catch.

Hiding prices entirely behind "Contact us" is a real decision with real costs. For a product sold through large, negotiated contracts it can make sense. For anything a small team might buy on a card, it mostly makes people assume the price is high and go to a competitor who publishes theirs. A common middle ground is to publish self-serve tiers and keep a "talk to us" option only for the largest plan.

Whatever you publish, think about what someone needs to calculate their real cost:

• What the price is per: user, seat, account, usage unit, or a flat fee. Say whether "user" includes people who only view.
• Whether the displayed price is for annual or monthly billing. Showing the annual price large and the monthly price small, without saying so, feels like a trick when people notice, and they do notice.
• What happens at the limits. If a plan includes a set number of projects or contacts, what happens when someone goes over: a hard stop, an automatic upgrade, or an overage charge?
• What sets the tiers apart. Make the differences between plans meaningful and easy to scan. If the comparison table has forty rows, put the five that actually drive the decision at the top.
• Whether there's a free plan or a trial, how long the trial lasts, and whether a card is needed to start.
• How cancellation works. A sentence saying people can cancel any time from their account settings removes a surprisingly common worry.

A short FAQ underneath the pricing table is a good place for the awkward questions: discounts for non-profits or education, what currency you bill in, whether tax is included, what happens to data if someone downgrades. Every question answered here is one fewer reason to leave the page and email you, or simply leave.

Avoid fake urgency on pricing pages. Countdown timers and "only today" offers clash with what a software subscription is: an ongoing relationship where the buyer will judge you every month on whether to keep paying.

Visit five: the link that gets forwarded to the person who signs off

Once a product costs more than an individual can expense, the evaluator has to convince someone else. That person might be a manager, a founder, a finance lead, or an IT or security reviewer. They arrive through a forwarded link with no context and a sceptical eye, and they're asking different questions from the user: is this company stable, is our data safe, and what happens if it goes wrong?

Your site should give the evaluator something to forward. That can be a page written for decision-makers that sets out the business case, a short PDF overview, or simply a homepage clear enough to stand on its own. Ask yourself whether someone who never saw your demo could understand the value from the page they were sent.

For anything that touches customer data, a security page is often the difference between a deal moving forward and stalling in an inbox. Say what is actually true: where data is stored, how it's encrypted, how access is controlled, whether you support single sign-on, how backups work, and how to report a vulnerability. If you've completed a formal audit or certification, name it and say how to request the report. If you haven't, don't imply that you have. Describing your real practices plainly is better than borrowing the vocabulary of certifications you don't hold, because security reviewers will ask for the paperwork.

The same reader often wants to see the legal basics: terms of service, a privacy policy, a data processing agreement if you serve customers in regions that expect one, and a page listing the subprocessors that handle customer data. Put these somewhere easy to find, usually the footer. When they're missing or hard to locate, a cautious buyer reads that as a young company that hasn't thought about it yet.

Signs that the company is stable matter to this reader too, even if nobody says so. An "About" page with real names and faces, a physical or registered business address, and a sign that the product is actively maintained (more on that below) all help answer the question "will they still be around in two years?"

The fork: self-serve signup, demo request, or both

Every software site eventually asks the visitor to do one of two things: start using the product themselves, or talk to someone. This choice shapes the whole site, so make it on purpose and not by copying a competitor.

Self-serve signup suits products that a single person can understand and get value from fairly quickly, at a price they can approve themselves. The site's job is then to get them into the product with as little friction as possible. Ask only for what you need to create the account, often just an email address and a password or a single sign-in button. Every extra field (company size, phone number, job title) loses some people. If your sales team wants that information, collect it later, inside the product, once the person has seen something worth staying for.

A demo request suits products that need configuration, involve several departments, or cost enough that buyers expect a conversation. Here the friction is the conversation itself, so the site should make it feel worth having. Say what happens in the call, how long it takes, and whether it's a real person showing the actual product or a sales qualification call. Let people book a time directly instead of filling in a form and waiting to be contacted. Waiting is where many demo requests go cold.

Many products need both: self-serve for small teams and a sales conversation for larger ones. That's fine, but make the routing obvious. "Start free" as the main button with "Talking to us about 50+ seats?" as a quieter link lets each visitor pick their own path without either one feeling second-class. What doesn't work is a site that pushes everyone to "Book a demo" when most visitors would happily have signed up alone, or one that offers only a free trial to a buyer who needs a security review and a contract.

If your product is hard to show in a static page, a recorded walkthrough of a few minutes is a useful middle step. It serves the person who wants to see the product without signing up or getting on a call, which describes a lot of visitors.

The pages that keep selling after someone signs up

With software, the sale isn't over at signup. Trial users decide whether to pay, and paying customers decide every billing cycle whether to stay. Several parts of your website do this ongoing selling, and they're easy to forget when planning.

Help documentation is read by prospects as well as customers. Evaluators often check the docs to see whether the product really does what the marketing says, and how much effort it takes. Public, searchable, well-organised docs signal a product that's mature and supported. Docs hidden behind a login hide that signal.

A changelog or "what's new" page shows that the product is alive. A buyer comparing two tools will notice if one shipped updates last week and the other's latest blog post is from two years ago. Short, dated entries in plain language are enough.

A status page, showing whether the service is up and listing past incidents, can feel like advertising your failures. In practice it does the opposite for most buyers: it shows you take reliability seriously and will be honest when something breaks.

Make it easy to reach support and see how to get help, with expected response times if you can commit to them. Customers who are considering upgrading often look at this first.

Deciding what to build first

If you're starting from scratch or rebuilding with limited time, build in the order of the visits that are costing you the most. For most early products that's the homepage headline and first screen, because if visit one fails, nothing else gets read. Next comes pricing, because it's where serious prospects do their deciding. Then features organised by the job the customer is doing, and a clear path through the signup or demo fork.

Security, legal, and comparison pages can follow once you're selling to buyers who ask for them. You'll know when that is, because those buyers will start emailing you the questions. Each of those emails is a sign that a page is missing.

Then watch what people do. Look at which pages visitors read just before they sign up or book a call, and which pages they leave from. Read the questions that come into sales and support, because each recurring question is something the website failed to answer. A software website is never really finished. It should change as often as the product does.