Find SaaS Design Partners by Building in Public

The short answer

To find SaaS design partners through building in public, show a specific unresolved workflow and invite people who encounter it. Explore promising replies privately, then agree the activity, responsibilities, access, and review point. Public interest alone is not a co-development commitment. Share decisions without exposing private partner material.

To find SaaS design partners through building in public, show a specific unresolved workflow, invite people who encounter it, and move promising replies into a private conversation about working together. Agree on the feedback activity, responsibilities, and review point before counting anyone as a partner.

Public updates can give a potential partner useful context: the problem you understand, what you have built, and where their experience could change the product. They do not establish that a follower has the right workflow, time, or authority to participate. That needs a separate conversation.

The method below follows that transition, from visible product work to a bounded co-development relationship. It includes an invented translation-agency example. It is practical editorial guidance, not a tested recruitment formula or a promise of introductions, customers, or product-market fit.

Decide whether you need a design partner

Use design partner here to mean a prospective user or customer who helps shape an unfinished product through recurring, specific work with the team. The relationship concerns a problem they understand and a product direction that still has room to change.

The Unusual Ventures field guide to design partners describes early customers who co-create with a startup. Its qualification questions emphasize willingness to give feedback, relevant experience with the problem, clear expectations, and a timeline. Those are useful considerations; its particular company-size preferences are not universal requirements for a small SaaS.

Choose this approach when you need to understand a workflow over more than one conversation, compare a proposed change with real operating constraints, and return with a revision. Be prepared to explain what you can act on and what is outside the current product direction.

If you only need someone to attempt one ready task, a bounded beta invitation may be enough. If you need a complementary company for an integration or marketing experiment, use the guide to finding SaaS business partners. Naming the relationship precisely helps you ask for the right work.

Publish an unresolved decision that the right person can recognize

Start with a product decision whose answer depends on someone else’s working experience. Describe the job, the current difficulty, the approach you are considering, and the part you have not resolved. This gives a reader a reason to recognize themselves in the update.

Show enough detail to make the question concrete. A diagram using invented records, a short demonstration, or a comparison between two possible workflows can help. Label what is working and what is only a sketch. The next conversation should start from an honest picture of the product’s state.

The guide to turning a public demo into useful feedback explains how to show a task without making a rehearsed demonstration look like independent user success. For design-partner recruitment, the demonstration has another job: helping someone decide whether they have relevant experience to contribute over time.

Keep these updates where the intended role can encounter them. A founder audience can offer useful introductions or peer criticism, but it may not contain the people who perform your target workflow. Ask a relevant reader to share the context with the right colleague rather than assuming every engaged follower is a candidate.

Separate a promising reply from a working commitment

A reply is a starting point. Find out what the person actually does, how recently they encountered the problem, and what they are hoping to change. Let their account guide the next question rather than trying to fit every respondent into a partner program.

In First Round’s interview with Gong co-founder Eilon Reshef, Reshef describes design partners as people who believe in the product’s potential value and are willing to invest time in testing and feedback. The useful distinction is participation. Interest in the idea alone does not tell you what someone can contribute.

Ask for an example of the existing workflow before offering a list of features. You might learn that the problem belongs to another role, that the proposed solution misses an important handoff, or that the reader likes the concept but cannot take part. Each answer can still help you route the conversation appropriately.

Move detailed operating questions into a private exchange when they involve internal processes, customer material, or commercially sensitive context. Begin with a high-level description and safe examples. A person who comments publicly has not automatically agreed to publish their documents or have their organization named.

A fictional public update creates three different next steps

Consider an invented founder building a revision-handoff tool for small translation agencies. They are exploring how a coordinator tells a translator that a source file changed after work began. The prototype groups changes, but the founder does not know how the handoff should fit into an agency’s existing process.

Their public update shows an invented document and two handoff options. It explains that the grouping is a prototype, then asks agency coordinators how they currently decide which changes need a translator’s attention. The invitation offers a private workflow conversation, followed by a separate discussion about ongoing collaboration if the fit is useful.

Suppose three fictional replies arrive. A freelance translator offers a terminology suggestion. An agency coordinator describes a recurring problem with revised files. A software vendor asks about an integration. All three replies are useful, but they point to different next steps.

The founder thanks the translator and records the suggestion without describing them as an agency design partner. They ask the vendor about the integration separately. With the coordinator, they explore who handles the handoff, how changes are communicated today, and whether the team can make time to inspect a revision.

The coordinator’s role makes the conversation promising, not complete. The founder still needs to understand the actual workflow, who else would be involved, and whether the proposed activity is possible. Nothing in this example establishes demand, successful recruitment, or customer results; the people and product are fictional.

Agree on a small piece of work before widening access

Write a short working brief after the workflow conversation. Capture the problem in the participant’s terms, the product decision you want to investigate, what each side will do, and when you will review the arrangement. Keep it specific enough that both sides can correct a misunderstanding.

• The participant brings a safe description or permitted example of the current workflow.

• The founder prepares a prototype change and explains its limits.

• Both sides agree on the feedback activity and the time it requires.

• The brief records which requests are in scope and what remains undecided.

• A review point determines whether to continue, change the work, or stop.

For the fictional agency, the first activity could be a walkthrough of an invented source-file revision. The coordinator explains how responsibility moves between people; the founder tests whether the proposed handoff represents that process. A later session could inspect a revised prototype. These are proposed activities, not evidence that the workflow has improved.

Discuss access and any required approvals before introducing real work. Early software may be unsuitable for a live process. A design-partner conversation does not establish production readiness, permission to process customer data, or acceptance by the participant’s organization. Keep the work within what both sides have actually agreed.

Make the exchange worthwhile without promising every requested feature. The participant may gain a chance to influence a problem they care about, while the founder gains context they could not infer from public reactions. State the limits of that influence and keep responsibility for product decisions clear.

Discuss commercial expectations without inventing a universal rule

Explain whether the proposed activity is paid, free, or separate from a later product purchase. Clarify the current offer before participation begins, including any limits on access or support. If those details are undecided, resolve them rather than letting the phrase design partner imply an offer you have not made.

Reshef’s account of Gong’s early approach places less emphasis on charging the first design partners. The Unusual Ventures guide asks founders to define what would support a later purchase. These perspectives offer questions to consider; they do not establish one payment rule for every product and stage.

For your own arrangement, distinguish participation from a commercial decision. Someone can provide useful context without becoming a buyer. Someone can be willing to pay while still being a poor fit for the workflow you are investigating. Record what each commitment actually means.

Avoid trading an indefinite promise for a vague commitment. If you offer a discount or extended access, describe its real scope and duration. If you cannot support custom implementation, say so before the work depends on it. The working brief should make those expectations easy to revisit.

Keep public progress separate from private partner material

Building in public can continue during co-development. Share your own decision, the tradeoff you are investigating, and a safe explanation of what changed. A public update does not need a participant’s name, internal documents, or private comments to show meaningful product work.

In the fictional example, the founder might publish that the prototype now distinguishes a changed paragraph from a change requiring reassignment. They could demonstrate the distinction with the invented document. They should describe it as a revision to investigate, rather than announcing that agencies have validated the workflow.

If you want to use a partner’s name, quotation, screenshot, or specific example, obtain permission for that material and its intended public use. Keep publicity optional in the working conversation. A willingness to help shape software is not the same decision as publicly endorsing it.

Keep a private record of what informed the change. Distinguish what a participant described, what you observed during an activity, what you inferred, and what you decided. That makes the later public account easier to write accurately without exposing the underlying private exchange.

Review the relationship through the work it produces

At the agreed review point, return to the original uncertainty. Did the activities clarify the handoff? Could you inspect the relevant constraint? Did both sides have enough time? A useful outcome might be narrowing the product direction or discovering that this participant’s workflow belongs outside it.

Look for what the relationship helped you understand rather than counting impressive names. Keep expressions of interest, agreed participation, completed activities, observed product use, and commercial commitments separate. A larger list does not resolve the uncertainty if the planned work never happens.

Also check how much one relationship is shaping the product. Record which requests appear specific to that participant and which assumptions still need comparison elsewhere. You can learn deeply from one workflow without representing it as typical of your entire market.

Choose a clear next step together: another defined activity, a different scope, a purchase discussion, or a courteous end to the collaboration. Do not let an early label turn into an indefinite obligation. Update your public invitation if the kind of help you need has changed.

Start with one unresolved decision you can show honestly. Publish enough context for a relevant person to recognize the problem, then make room for a private conversation about the work. Count a design partner when there is an agreed relationship you can describe accurately, and let the next public update reflect what you actually learned.

Sources

Unusual Ventures: Working with design partners — practitioner guidance on co-creation, qualification, expectations, and timelines; accessed October 18, 2026.

First Round Review: Gong’s path to product-market fit — edited interview with Eilon Reshef on time, testing, feedback, and Gong’s early payment approach; accessed October 18, 2026.

Buildside Journal: Writing a SaaS beta invitation — a separate workflow for recruiting people to attempt a bounded test.

Frequently asked questions

A note from Uriel Bitton

The translation-agency product, replies, and proposed activities in this article are fictional. The guidance applies practitioner sources to a public-to-private co-development workflow; it does not report Uriel’s customer results or a tested recruitment formula.

Keep building with us

Get practical founder lessons and product updates in your inbox.

Subscribe or Join Buildside.

Keep reading