What Does a SaaS Website Need Before the Product Is Ready?

The private beta is six weeks out, the domain is bought, and somebody has finally asked the question that always arrives late: what goes on the website? The usual answer is a hero line, three feature cards, a screenshot of software nobody has finished, and a form. That page ships in a week. It stops being useful in three.

A pre-launch SaaS website has one job, and looking finished is not it. The job is to say what the product does, who it is for, and what happens after somebody signs up, accurately enough that the people who join the list are the people you actually want in the beta. Everything else on the page is decoration, and decoration is cheap to add later.

This is harder than it sounds, because the honest version of a pre-launch page is thinner than the marketing instinct wants it to be. You cannot show outcomes you have not produced. You cannot quote customers you do not have. What you can do is be exact about the problem, and exactness is rarer than proof. Before any of that, settle what you are building at all: a product, a service, or a feature, because the three want completely different websites.

What a pre-launch site is actually for

Three audiences read a pre-launch SaaS website and they want different things. Prospective users want to know whether this solves their problem and when they can have it. People you might hire want to know whether the thing is real and who is behind it. Anyone doing diligence, which includes partners, journalists and the occasional investor, wants the claims to be consistent and the entity behind them to exist. One small site can serve all three. It can only do that if it stops pretending to be a product page.

So the operating principle for the whole build is this: promise the problem, not the product. A visitor should leave knowing precisely which situation this software is for, and should be able to tell almost immediately whether that situation is theirs. That is a positioning exercise wearing a web design brief, and treating it as a design task is how teams end up with a beautiful page that says nothing.

The failure mode is a page that could describe forty other products. Generic capability language, the kind that streamlines workflows and brings all your data together, is what teams write when they have not decided who they are for. It reads as safe and performs as noise. Naming a specific situation costs you the visitors who were never going to convert. That is the point, not a side effect.

What a pre-launch page may honestly claim

There is a real line here, and it is worth drawing before the copy gets written rather than after somebody senior reads it and panics.

Claims that hold

You may describe the problem in as much detail as you like. You may describe what the software will do, in the future tense, provided you intend to build it. You may state who it is for and who it is explicitly not for. You may say what stage you are at: private beta, waitlist open, first accounts being onboarded one at a time. You may describe your approach and the decisions behind it, because those are yours to state. You may publish the pricing model before you publish a price, as long as you say it is provisional.

Claims that will not survive contact

Everything that implies a track record you have not accumulated. Logos of companies who once took a call. Testimonials assembled from friendly messages in a group chat. Numbers with no denominator, such as hours saved by people who have not used the thing. Integrations listed because they are on a roadmap. A comparison table where the competitor column is unflattering and quietly out of date. Each of these is discoverable, and the person who discovers it is usually the buyer you most wanted.

The right-hand column reads weaker on a slide and stronger in a sales conversation. It also survives the moment when somebody from the waitlist gets access and finds out what is actually there. That moment decides whether they tell anyone, and word of mouth from a first cohort is the only distribution a pre-launch product has.

The case against the fake product tour

The most common pre-launch mistake is an interactive tour of an interface that does not work. Rendered screens, an animated cursor, a dashboard full of invented charts, a fictional company name in the corner. It demos beautifully in an internal review. It is a liability everywhere else.

Three reasons. The first is expectation: every pixel in a fake tour is a promise, and the shipped product will differ from it in ways you cannot predict while it is still being designed. The second is cost, and it is larger than it looks, because polishing screens for unfinished software means designing it twice and throwing one away. The third is that a fake tour answers a question nobody asked. Visitors at this stage are not evaluating your interface. They are deciding whether the problem you describe is the problem they have.

A screenshot is a promise with a resolution. Show the problem you understand, not the product you have not finished.

There is a version of this that works, and it is narrow: one real screen, from the real build, captioned with what it does and what it does not do yet. Honest incompleteness reads as confidence, and it protects the thing you cannot afford to lose this early, which is the patience of the first cohort. Signups are easy to collect and easy to waste. The mechanics of that waste are the whole subject of why users sign up and never come back, and pre-launch is where the pattern is set.

Waitlist mechanics that survive the launch

A waitlist is not a mailing list with a nicer name. It is a queue carrying an implied contract: you gave us your address, we will give you access in some order, and we will tell you where you stand. Most pre-launch sites collect the address and honour none of the rest.

What the form should ask

Ask for the minimum that changes what you do next. If a field will not alter the order of invitations or the first message you send, it is friction with no return. In practice that means one required field and one or two optional ones, and a form that fits on a phone screen without scrolling.

1. Email, required. The only field that has to be there. Everything else is optional and should visibly look optional.
2. One qualifying question. Role, team size band, or the tool they use today. Pick the one that decides who you invite first, and ask only that one.
3. A free-text line. “What are you hoping this replaces?” is the highest-value question on a pre-launch site. The answers will rewrite your home page for you.
4. An explicit consent line. Say what you will send and roughly how often. Joining a waitlist is not permission to run a newsletter.
5. A stated position or cohort. Tell people what they just joined. “You are in the next cohort” beats a bare thank-you every time.

What happens after the submit

The confirmation screen and the first email are where most waitlists quietly die. A thank-you page with no next action wastes the highest-intent moment you will ever get from that person. Give them exactly one thing to do: read the piece explaining your approach, answer the one question you actually want answered, or forward the page to the colleague with the same problem. Then send something within the week, and keep sending on a rhythm you can hold while shipping. A waitlist that goes silent for a quarter converts like a cold list, because by then it is one.

Content that compounds while you build

This is the part that pays. The months before launch are the only period when a team has both the knowledge and the spare hours to publish properly, and search does not care that your product is unfinished. Everything you write about the problem is indexable now and still true after launch. Content and organic growth is slow in a way that suits this period exactly: the work you do while nobody is watching is compounding by the time you have something to sell.

What to write is not mysterious. It is the material a normal week of building already generates, written down instead of lost in a call.

• The problem, in the customer’s words. Describe the situation you keep hearing on calls without mentioning your product once. This is the page that gets found and the page that gets forwarded.
• The decisions, and why. Why you chose one model over another, what you refuse to build, what the first version got wrong. Nobody else can write this, which is why it is worth writing.
• The comparison you would give a friend. Honest about where the alternatives are genuinely better. It converts the readers worth converting and filters the rest.
• The how-to that does not need you. Solve part of the problem with a spreadsheet, a script or a checklist. Useful today, and evidence that you understand the work.
• The pricing thinking. Publishing how you intend to charge, before the number exists, surfaces objections while they are still cheap to answer.

One practical constraint decides whether any of this happens: publishing must not queue behind the product team. If every article needs a developer, the schedule slips, then stops, then becomes a quarterly guilt item. Whatever you use, the requirement is that a non-engineer can publish without a release. A structured content workspace such as Acrosite takes one approach to that, generating the required files, committing them to GitHub and triggering the configured deployment, so writing runs on its own rhythm instead of the sprint’s.

Two kinds of work compete for the same people here: the product, which is never finished, and the site, which could always be better. Our parent company has written about that split directly in client work and product work. The honest resolution is usually to time-box the site hard and let the writing run continuously, rather than letting the site expand into whatever the loudest person wants this week.

The pages you actually need

Fewer than you think, and two of them are the ones teams skip. The set that earns its keep: a home page that names the problem and the audience; one page describing the product in the future tense with a single real screen; a pricing page publishing the model even if the number is provisional; an about page with real names and a real registered entity; and the waitlist confirmation. That is the whole site. Anything else is a page you will rewrite after the first ten users tell you what you got wrong.

The two that get skipped are the about page and the pricing page, and both are skipped for the same reason: they feel premature. They are not. The about page is what a cautious buyer checks before typing an email address, and a page with no humans on it reads as a shell company. The pricing page, even without a price, is what stops the wrong prospects joining a queue they will leave. Publishing the model is a filter, and a filter is the cheapest qualification you will ever build.

Build it small and fast. There is no argument at this stage for a heavy stack and a real argument against one, because every hour spent on the marketing site’s architecture is an hour not spent on the product. What matters is that it loads quickly, reads well on a phone, and can be edited without a deploy queue. That is an afternoon of website design and development decisions, not a quarter of them.

What to measure when there is no product yet

Signup count is the metric everyone reports and the one that predicts least. A waitlist number is a vanity figure until somebody gets access. The interesting question is whether the people on the list match the people you built for, and you can only answer that if you asked something.

Measure three things instead. The share of signups who answer the free-text question, because willingness to type is the closest proxy for intent available before a product exists. The share who match your intended segment. And, once invitations start going out, whether invited users reach the first useful moment at all. That last one becomes the metric that matters for the rest of the product’s life, which is the argument in activation beats acquisition, and pre-launch is the cheapest time to start watching it.

Set the baseline now, while the site is small and the traffic is low, because a baseline taken later is contaminated by the launch itself. Write down what the page does today: how many visitors reach the form, how many complete it, where they arrived from. When you change the page, and you will change it constantly, you will at least know what you changed it from. That discipline is the whole of proving a design change worked, and it is far easier to begin before launch than after.

One more, and it costs nothing: keep the objections. Every reply to a waitlist email containing the phrase “does it” is a feature request and a positioning signal at the same time. Sort them into buckets. The money bucket will tell you more about pricing a product nobody has compared than any competitor spreadsheet will.

Where we would start

If the beta is under three months away: build the five pages, publish the waitlist with one qualifying question, write the three emails, and put every remaining hour into problem-side writing. Skip the product tour entirely. Take one screenshot of the real build the week before launch and caption it honestly. That plan is boring, and it is the one that still looks correct in six months.

If the beta is further out, invert the ratio: less site, more publishing. A team with three quarters of runway holds the rarest asset in software marketing, which is time to become findable before it needs to be found. The site can sit at three pages for most of that period. What it cannot do is stay silent, because a domain with nothing on it accumulates nothing. This is the shape of work we run as a product launch engagement, and the writing usually starts before the design does.

The honest limitation: none of this rescues a product without a reason to exist. A pre-launch site cannot manufacture differentiation, and if you write the problem page and it describes a whole category rather than a specific gap, you have learned something valuable very cheaply. The right response then is to go back to the product, not to hire a copywriter.

And if a fake dashboard mockup is currently sitting in a review queue waiting for your sign-off, do not sign it. Ship the thin, true version, keep the difference in build hours, and spend them on the beta. If you want a second read on a pre-launch page before it goes live, send us the draft and tell us what the product will not do.