At launch, a SaaS website needs a home page that says what the product does and for whom, a pricing page, a features or product page, terms of service and a privacy policy, and obvious sign-up and log-in links. Add a docs or help link, a short about and contact page, and a changelog as soon as you have something to put on them. Customer stories, comparison pages, an integrations directory, careers and a blog can wait until you have the material to fill them.
The rule behind that list: launch with the pages that answer what a first-time visitor needs to know before signing up, and add pages when you have real evidence to put on them. An empty "Customers" page is worse than none. If you want a fast first version, FNJ's AI website builder for SaaS designs these pages from your product description and a site you admire.
The launch set at a glance
| Page | What it must answer | At launch? |
|---|---|---|
| Home | What is it, who is it for, why is it better, what do I do next | Yes |
| Pricing | How much, what's included, when do I need to upgrade | Yes |
| Features or product | What exactly does it do, and how | Yes (can start as home page sections) |
| Sign up and log in | Where do I start, how do I get back in | Yes (links into your app) |
| Terms and privacy | What are the rules, what happens to my data | Yes |
| Docs or help | How do I use it, how do I get support | A link at launch |
| About and contact | Who is behind it, how do I reach a person | Yes, kept short |
| Changelog | Is this actively maintained | At launch or soon after |
| Customers, comparisons, careers, blog | Proof and depth | Later |
Home: four answers on the first screen
The first screen should answer four questions, in this order:
- What it is, in plain words. "Scheduling software for physical therapy clinics" is clear. "The operating system for modern care" is not.
- Who it's for. Naming the audience makes the right people lean in and the wrong ones leave, which is what you want.
- Why it's better than what they do now. One concrete difference: "Patients rebook from a text message, no app to install."
- What to do next. One primary button.
Choose that button by how you sell. A self-serve product says "Start" or "Create an account". A sales-led product says "Book a demo". A product that isn't ready says "Join the waitlist", and at that stage a single page may be all you need (see landing page vs website). Two equal buttons split attention; a secondary text link such as "See pricing" is fine.
Show the actual product. A current screenshot or a short loop of the interface does more than an abstract illustration, because it answers the question "what will I be looking at all day?"
Put Log in in the top-right corner. Existing users will come through the marketing site looking for the app, and they shouldn't have to hunt.
On proof, use only what's real. At launch you might have beta users happy to be quoted (with permission), a design partner whose logo you're allowed to show, or nothing at all. Nothing is fine. A short note from the founders about why they built it is honest proof of a different kind. Invented logos and placeholder testimonials do lasting damage once someone notices.
Pricing: answer what people would otherwise email you
A pricing page must answer:
- What it costs, monthly and yearly if you offer both, with the currency and whether tax is included.
- What each tier includes, in terms users understand ("up to 3 team members", "unlimited projects") rather than internal feature names.
- What makes someone upgrade. The limit that moves people from one tier to the next should be obvious.
- How a trial or no-cost plan works, if you have one: how long it lasts, whether a card is needed, and what happens at the end.
- How cancelling and refunds work.
- What "Contact us" means on an enterprise tier: who it's for, and roughly where pricing starts if you can say.
For a self-serve product, hiding prices behind "Contact sales" at launch pushes people who wanted to try it today into a conversation they may not want. Add a short FAQ under the tiers for billing questions. Then check every number on the page against the billing in your app: a price that doesn't match checkout is both a support ticket and a trust problem.
Features or product page
At launch one product page is usually enough, and for a simple product its content can live in sections on the home page. Organize it by what users get done, not by your app's menu. "Send reminders automatically" is a job; "Notifications module" is a menu item.
For each feature, write one sentence on what it does and one on why it matters, and add a screenshot. List integrations only if they work today, because a row of "coming soon" logos reads as padding. Split features into their own pages later, when people search for them by name or when sales calls keep circling back to one of them.
Sign-up, log-in and where the app begins
Many SaaS teams keep the marketing site separate from the app: the site at example.com, the app at app.example.com, and docs at docs.example.com or in a help tool. That lets you change marketing pages without an app release, and keeps the site fast because it's mostly static pages.
Check the boundary before launch. Every Sign up button should go to the sign-up screen, Log in should go to log-in, and plan buttons on the pricing page should pass the chosen plan if your app supports it. If you're deciding how to build the marketing site itself, our comparison of Next.js and static HTML for a marketing site covers the trade-off.
Docs and help: a link is enough to start
Full documentation can live in a dedicated docs tool. On the marketing site you need a Docs or Help link in the menu or footer, a getting-started guide somewhere, and a way to reach support (an email address is fine). If you run a status page, link it from the footer.
Changelog: cheap to start, useful from week one
A changelog answers a question every early buyer has: is this product being actively worked on? Dated entries that show steady progress persuade in a way a features list can't, and each entry gives you something to share.
Keep entries short: the date, what changed, why it matters to a user, and a screenshot when it's visual. Write for customers, not for the engineering team: "You can now export reports as CSV" rather than "Refactored export service".
About and contact
Buyers, especially business buyers, want to know who is behind a new product. A short about page with the founders' names and photos, why you built it and where the company is based is enough. Contact can be a section on the same page: a support email, a sales email if you have a sales process, and a postal address if your legal pages need one.
Legal pages
Before you take sign-ups you'll typically need terms of service and a privacy policy, and depending on where you and your users are, possibly a cookie notice and a data processing agreement for business customers. Requirements vary by country and by the data you handle. This is general information, not legal advice; have a lawyer review your documents. Link them in the footer and from the sign-up screen.
What can wait, and when to add it
| Page | Add it when |
|---|---|
| Customer stories | Customers have results and agree to be named |
| Comparison or alternative pages | You know which tools people compare you with, from sales calls and sign-up questions |
| Use-case or industry pages | You see distinct groups of customers with different needs |
| Integrations directory | The list is long enough that people need to browse it |
| Security page | Business buyers start sending security questionnaires |
| Careers | You're hiring |
| Blog | You can publish useful posts regularly |
| Press kit | Journalists or partners ask for logos and screenshots |
Launch-day checklist
- Every page has its own search title and description
- A social preview image is set, because launch links get shared
- Sign up, Log in and pricing buttons point at the right app addresses
- Prices on the site match prices in billing
- Terms and privacy are linked in the footer and at sign-up
- Screenshots show the current product
- The site reads well at phone width, not just on a laptop
- A helpful 404 page and a working favicon
- Analytics installed if you use them, and covered in your privacy policy
For the technical side on a Next.js site, see our Next.js SEO checklist for the App Router.
Building your launch site with FNJ
FNJ's AI website builder designs a SaaS marketing site from your product description and a site you admire: home, features, pricing, FAQ, and pages such as about or a changelog when you ask for them, at desktop, tablet and phone widths, each with its own search title and description. You export it as a Next.js App Router project or static HTML and deploy it next to your app. It doesn't build sign-up flows, log-ins or dashboards, so its buttons point at your app, and there's no blog engine, so a changelog is a page you edit and redeploy. See how it works on the AI website builder for SaaS page.
Frequently asked questions
What pages does a SaaS website need at launch?
A home page, a pricing page, a features or product page, terms of service and a privacy policy, and clear sign-up and log-in links. A short about and contact page, a docs link and a changelog are worth adding at launch or soon after.
Should a SaaS startup show pricing on its website?
For self-serve products, yes. Hidden prices push visitors who want to try the product today into a sales conversation they may not want. For enterprise tiers, say who they're for and where pricing starts if you can.
Does a SaaS website need a blog at launch?
No. A blog helps when you can publish useful posts regularly, and an empty or abandoned one hurts more than it helps. A changelog is a better first habit because it shows the product is moving.
Should a SaaS marketing site and app be on the same domain?
They often share a domain but run separately, for example the site at example.com and the app at app.example.com. Keeping them separate lets you update marketing pages without an app release.
What legal pages does a SaaS website need?
Typically terms of service and a privacy policy, plus a cookie notice or a data processing agreement depending on where you and your users are. Rules vary by country; this is general information, not legal advice.