The short answer
Do not replace missing proof with louder claims. Show the product, name the exact user and job, explain how it works, state what is unfinished, and offer a next step that matches the stage you are at.
An early product page can be credible without pretending the product is established.
Lead with identification, not a slogan
A visitor should be able to finish this sentence after the first screen:
[Product] helps [specific person] do [specific job] without [costly alternative].
“Work smarter” could describe a thousand products. “Turn customer interview transcripts into a tagged research library” gives the reader something to accept or reject.
Specificity reduces the amount of trust you need. People do not have to believe you are the best. They only have to recognise their problem.
Show the real product
Use a current screenshot, a short recording or a live example. If you do not have one, leave the image slot empty. A made-up dashboard creates the wrong kind of polish: it asks the visitor to trust a picture that is not evidence.
Caption the image with the job it shows. “The weekly review screen groups unresolved notes by client” is more helpful than “Powerful dashboard”.
Use process as early proof
Before testimonials, you can still show evidence:
- A working example with realistic input.
- A changelog with dated improvements.
- The source or method behind a result.
- A public issue you fixed after somebody reported it.
- A clear list of what the product does and does not do.
Proof is anything a visitor can inspect. A badge you awarded yourself is not proof.
Say what is unfinished
Early users are usually tolerant of missing features and intolerant of surprises. Tell them if data is deleted after a session, if mobile is rough, if only one file type works or if you still handle part of the process manually.
Limits help the right person opt in. They also make the rest of the page more believable.
Match the call to action to the product
A paid, repeatable product can ask somebody to start a trial. A rough prototype may need a smaller step:
- Try the demo with one real example.
- Join five pilot users.
- Send the file format you need supported.
- Answer one question about the workflow.
Do not write “Get started” if the next screen is a waitlist. Name what will actually happen.
A simple page order
- One sentence naming the user and job.
- A real view of the product, if one exists.
- Three steps showing how the job gets done.
- Inspectable proof: example, method or changelog.
- Honest limits and who the product is not for.
- One next step that matches the product’s maturity.
That is enough for a first version. Add testimonials when somebody has used the product long enough to say something specific.
You can submit a product without testimonials. Built In Public shows the founder, stage, current request and public work so a visitor can decide whether they want to help.