How to Design a Page for a Product Still in Beta

How do you design a page for a product that is still in beta?

Make the unfinished parts legible rather than hiding them. The page's job is not to look like a finished product, it is to help the right early user self-select and the wrong one leave quickly. Everything else on the page follows from accepting that.

The instinct is the opposite. Beta pages tend to borrow the visual language of mature products, complete with confident feature grids and a logo strip of companies that have not actually used the thing. It reads as polished and it converts the wrong people.

Converting the wrong people is genuinely costly at this stage, because your early users are also your feedback loop. Someone who signs up expecting a finished product and finds a beta gives you churn and a bad impression rather than the thing you actually needed, which was a useful bug report.

Should you even say the word beta?

Yes, and say it in the hero rather than in a footnote. The word does less damage than people fear and the omission does more, because a visitor who discovers the product is unfinished after signing up feels misled even if you never technically lied.

What matters more than the label is what you attach to it. "Beta" alone is a disclaimer. "In beta, which means the reporting module is not built yet and the data model is still changing most weeks" is information, and information is what lets somebody decide.

There is a small category of exception where the label creates procurement problems, typically when selling into larger organisations. Even there I would not remove the word, I would move the conversation, because a buyer who finds out later has a much bigger problem than a buyer who knew.

What replaces social proof when you have none?

Specificity. You cannot show testimonials you do not have, and inventing them is both dishonest and easy to detect, so the substitute is a level of detail that signals the thing is real and someone has thought hard about it.

Concretely, that means showing what the product actually does today, naming the problem precisely enough that somebody with it recognises themselves, and being explicit about who built it and why. A founder explaining the origin of the problem in their own words does more work than a fabricated quote ever could.

What you must not do is dress up weak proof as strong proof. A logo strip of companies in a pilot, presented as customers, is the exact move that makes a page untrustworthy, and it is the reason I keep arguing for testimonial sections that are actually believable. Labelled honestly, a pilot is interesting. Presented as adoption, it is a lie with a design system.

Where does the honesty go on the page?

Above the call to action, always. The reader should encounter the limitations before they are asked to act, not after, because the whole point is to let the wrong person leave before they spend anything, including their attention.

In practice I would put a short, plain section directly before the signup that says what exists, what does not, and what will change. Not apologetic, not buried in an accordion, just stated. That section is the single most valuable thing on a beta page and it is the one most teams cut.

The reason it works is that it converts the page from a pitch into a filter. A page that filters is more useful than a page that persuades when your constraint is the quality of your early users rather than the quantity, which is the same logic as a services page built to filter out bad-fit leads.

What should the call to action actually ask for?

The smallest commitment that still produces a real signal. A waitlist email is nearly free to give and therefore tells you almost nothing. A short form describing the visitor's situation costs them two minutes and tells you whether they are the user you need.

I would rather have thirty people who wrote a sentence about their problem than four hundred who typed an address. The second number looks better on a slide and the first one is what lets you build the right thing.

Ask for one qualifying detail and nothing more. What are you currently doing instead, or how often does this problem come up. One question, optional if you like, because even the people who skip it have told you something by skipping it.

How do you show an unfinished product?

As it is. Real screens with real state, including the parts that look rough, rather than idealised renders of a version that does not exist. A polished mockup of an unbuilt interface is the visual equivalent of a fabricated testimonial.

This is uncomfortable for anyone who designs for a living, and I say that as someone who does. There is a strong pull toward showing the intended version, particularly when the current one has placeholder labels and awkward spacing. Resist it, or label the mockup clearly as a mockup.

The compromise that works is to show the real thing for what exists and to describe in words what does not, rather than illustrating the future. Words are honest about being a plan in a way that a rendered interface is not.

What do you do about pricing?

Say something, even if the something is that you have not decided. A blank pricing page on a beta product reads as evasion, and the visitor's imagination fills the gap with a number that is usually wrong in whichever direction loses you the conversation.

The honest options are a stated range, a statement of what it will be based on, or a commitment about the beta period itself, such as what happens to early users when pricing arrives. That last one is the question every serious early user is actually asking.

My own work is priced as fixed fees, typically between one thousand and ten thousand dollars, and the reason I publish that is the same reason I am telling you to publish something. A number, or even a range, does more qualifying work before a conversation than any amount of positioning does during one.

How does this page change as the product matures?

The honest section shrinks and the proof section grows, and the order of the page mostly stays the same. That is a feature, because it means you are not rebuilding the page at launch, you are editing it as reality changes.

Plan for that from the start by building the limitations section as something you can shorten rather than something structurally load-bearing. If removing the caveats would leave a hole in the layout, you have designed a page that resists its own success.

The same applies to your proof section. Leave the space for testimonials empty rather than filling it with something weak, and put a real one in the moment you earn it. An obviously reserved space is more honest than a filled one, and it costs you less credibility than the alternative.

What is the most common mistake here?

Designing for the investor rather than the user. A surprising number of beta pages are built to look impressive in a deck or a link sent to a potential backer, and that audience wants something very different from the one that would actually use the product.

The tell is a page heavy on vision and light on what the thing does today. Vision language is fine in its place, but a user trying to decide whether to spend twenty minutes on your beta needs to know what happens when they log in, and that question goes unanswered on most of these pages.

The other frequent mistake is trying to serve both audiences at once, which produces a page that half-commits to each. If you genuinely need an investor-facing page, build a second one rather than compromising this one, which is the same reasoning as designing one page for two different buyers and knowing when not to.

What should you do next?

Open your current beta page and find the sentence that tells a visitor what is not built yet. If there is not one, write it, and put it directly above your call to action before you change anything else on the page.

Then look at what you are asking for. If it is just an email address, add one question about the visitor's situation, and accept that your signup number will fall. The number falling is the point, because the people who remain are the ones you can learn from.

If you are about to put a beta in front of people and you are not sure how much to admit, let's chat. In my experience the answer is almost always more than feels comfortable, and the page gets better rather than weaker for it.