Choose a product you have genuinely tried and write an honest, specific account of that experience. Submitting an eligible proof activates a Free listing; owner review and verification are separate, and a suitable match or return testimonial is not guaranteed.
Find testimonial projectsWhat Counts as a SaaS Testimonial?
A testimonial is a person's account of an experience with your product. That person does not have to be a paying customer, but they should have used the product enough to support what they say. A beta tester can describe a beta experience; a design partner can describe a workflow they tested. Label the relationship clearly.
Keep adjacent evidence in its own category. A usability interview is research. A founder's account of building the product is founder context. A link from an industry article is an editorial mention. Each can help answer a buyer's question, but none should be presented as a customer testimonial. See the testimonial definition and types of social proof for indie developers for the distinctions.
How Do You Get a Testimonial Without Paying Customers?
Use a short, repeatable process: find someone who matches the intended user, let them try one real workflow, ask about the experience, and request permission to quote their answer.
1. Recruit someone who can speak to the problem
Start with beta sign-ups, people who agreed to a product interview, design partners, or members of a community where you already participate. Explain what is ready, what is rough, and how much time you are asking for. Do not describe an interested prospect as a user if they have not tried the product.
If you are still deciding what to build, use the pre-launch app feedback process first. Feedback can guide the product; a testimonial requires an actual experience to describe.
2. Give them one task and observe
Choose a task that reflects the product's main promise. For a hypothetical scheduling tool, that might be inviting a teammate and finding a shared time. Watch where the person hesitates and ask what they expected. Do not coach them through the difficult step and then describe the session as effortless.
A small beta round is for finding specific friction and learning how one person used the product. It cannot establish how common an outcome is across a market. Record the person's context and the limits of what they tested.
3. Ask about what happened, not whether they liked it
After the task, ask open questions such as: What were you trying to do before you opened the product? Which step was unclear? What, if anything, is easier now? What would stop you from using it again? A useful answer may be positive, mixed, or negative; do not steer someone toward praise.
If the person describes a concrete benefit, ask whether they would be comfortable sharing that experience publicly. Make clear that saying no will not affect their access or relationship with you.
4. Confirm the words and attribution
Ask permission for the final wording, name or role, link to a public profile if they want one, and the pages or materials where you plan to use it. If you draft from their notes, keep it faithful to the original and let them edit it. Do not add a metric, result, or endorsement they did not provide.
Illustrative request template, not a real testimonial: “You mentioned that [specific task] changed after you tried [product]. Would you be comfortable with us quoting your words on [page]? We can show you the exact wording and attribution first, and it is completely fine to decline.”
Keep a simple record of the approved text, date, attribution, product version, and agreed use. If the product changes enough to make the quote misleading, ask again or retire it.
Which Sources Can Produce Early Testimonials?
Beta users and free users are often the clearest source because they can describe hands-on use. Support messages and user interviews can also surface useful language, but ask permission before reusing a private message. A public launch comment can be quoted only with the author's approval and its original context intact.
A founder or peer can write about your product if they have tried it. A friendly relationship is not a substitute for use. If you have not launched and there is no product experience to quote, show evidence you do have: a transparent demo, a founder's relevant experience, a changelog, or clearly labeled research findings. Avoid anonymous placeholder quotes and invented customer counts.
How to Collect and Publish a Customer Quote with ProofSwap
If an early customer or beta user has already written something you may publish, an owner can add that existing written quote from My Projects → project → Wall of Proof & Widget. Get permission for the exact wording and attribution first. ProofSwap labels an owner-added quote separately; it is not a verified exchange or a customer-collected submission.
If you need to ask customers for a quote, the same project area has a private collection link. The project must already be activated and live. After you create the link, share it with the person yourself; ProofSwap does not email or contact submitters. The form asks the submitter for their name, optional role or company, optional profile link, the quote, and explicit permission to show it publicly. It collects no email address. New submissions stay private while pending. The project owner reviews each one and approves or rejects it. If the Free project has filled all three manual slots, a submission stays pending until a slot is available. With capacity available, approval publishes the quote on that project's public wall and embed, labeled Collected by followed by the project name; an owner-added quote is labeled Added by followed by the project name. Neither label means the quote was verified through an exchange.
These limits are separate. A Free project has three shared manual-proof slots for owner-added tweets, written quotes, and approved customer-collected quotes; verified exchange proofs use a separate source. The Free embed can return up to five total items per request. That display limit does not raise the three-slot manual cap. See the widget overview for the display workflow and plan details.
Hypothetical workflow, not a customer result: A beta tester has used a bookkeeping app to send one invoice. The founder can create a private collection link, share it after the test, and let the tester decide whether to submit a quote. The founder then reviews the exact quote and either approves it with the submitter's consent or keeps it private. If the tester only gave product feedback and does not want a public quote, the notes remain research, not social proof.
Can a Give-First Exchange Help?
A give-first exchange is one way to meet other founders and offer useful feedback or social proof. It does not guarantee a reciprocal quote, a particular timeline, or a result. A peer's testimonial belongs on your page only when it reflects their real experience with your product and they approve its use.
ProofSwap currently supports exchanges of tweets, written testimonials, video reviews, and app feedback. Members choose what their project can give and what it needs, submit proof for another project, and the receiving owner reviews it. Submitting one proof can activate a free project listing; the receiving owner reviews the exchange separately, and verification determines its exchange status. Receiving proof does not cost credits. The workflow structures participation, but it does not guarantee a match or a specific piece of proof. Read how ProofSwap works or browse projects seeking testimonials.
How Should You Publish the First Quote?
Place the strongest approved quote beside the claim or decision it helps explain. Add enough context for readers to judge it: what the person used, their relationship to the product, and when the experience took place. A specific sentence with clear attribution is more informative than a stack of anonymous praise.
Keep other evidence separate. Product usage numbers need a defined source and date. A market statistic supports a category claim, not a claim about your SaaS. An editorial mention can show that a publication chose to cover you, but it does not show that its author used the product. The broader guide to building app credibility before launch covers these other trust signals.
What Should You Do This Week?
Pick one workflow your product is meant to improve. Invite a small number of people who match the intended user, explain the current limits, and watch them try it. Ask what happened, then request permission only if they have a real experience they want to share. If the round produces feedback but no testimonial, that is still useful product evidence; do not force it into a quote.