How to Find Design Partners for Your Startup

You've got a problem hypothesis, a rough sense of who has it, and no product. The advice you keep hearing is "go talk to customers." Fine. But talking to customers produces a folder of Zoom recordings and a vague feeling that you're onto something. Design partners produce a product somebody pays for.

That's the difference, and it's the reason design partners are worth more to a first-time founder than another round of discovery calls. A design partner is a target customer who agrees to help shape your product before it exists, in exchange for early access, real influence over what gets built, and usually a price they'll never see offered again.

Bessemer published a piece in May 2026 arguing that this is the pre-launch edge most AI founders ignore. I'd push that further. If you have no distribution, no brand, and no logo anyone recognizes, a design partner program is the only validation method that ends in revenue instead of a slide about "strong customer interest."

Here's how to find design partners, what to actually offer them, and how to structure the arrangement so it doesn't quietly turn into eight months of unpaid consulting.

What is a design partner, and how is it different from a beta user?

A beta user tests a product that already exists. A design partner shapes a product that doesn't. That's the whole distinction, and it changes everything about how you recruit, what you ask for, and what you get back.

Beta programs answer one question: does this work? Design partner programs answer three much better ones: what should we build, for whom, and at what price? The relationship is higher touch. You're not shipping them a signup link and watching a dashboard. You're on a call every other week, watching them work, arguing about what matters.

There's a third category people confuse with both: the advisor. Advisors give opinions and get equity. Design partners give access to their actual workflow, their actual budget, and their actual procurement process, and they get a discount. Those are very different trades. Don't mix them up, and don't hand out equity for something a discounted contract buys.

The tell that you have a real design partner and not a friendly stranger: they change their behavior. They put your half-built thing in front of their team. They complain when it breaks. Someone who only ever says nice things on calls is a fan, not a partner.

When should you start looking for design partners?

Before you build. The right moment is when you have a clear problem hypothesis and no solution, because every week you build without a partner is a week you might be building the wrong thing.

Founders get this backwards constantly. They spend four months on an MVP, then go looking for people to react to it. By then you've already made a hundred decisions a design partner could have made for you, and now you're emotionally attached to all of them.

The two examples Bessemer highlights both started absurdly early. Ada's cofounders, Mike Murchison and David Hariri, went and worked the support desks at seven different companies before writing a line of code. Those seven companies became Ada's first design partners. Strella's cofounders, Lydia Hylton and Priya Krishnan, recruited 12 design partners before their AI interviewer was fully built.

So the honest answer is: earlier than feels comfortable. Yes, you'll be selling something that doesn't exist. That's the point. If nobody will commit time to a described product, the built version won't fix that.

How many design partners do you actually need?

Between five and 12 is the range most practitioners land on, and there's decent reasoning behind it. You need enough partners to see a pattern rather than one loud opinion, and few enough that you can stay high touch with all of them.

Strella ran a cohort of 12. Ada worked with seven. Some write-ups push for as few as three deep, paid relationships in a single ICP over a hundred shallow ones, and that's defensible too if your sales cycle is long and your ACV is big.

What actually matters is whether they're the same kind of customer. Five partners in one narrow segment will teach you more than 15 scattered across three industries, because with the scattered group every piece of feedback is a special case and you can't tell signal from noise. Pick a segment first. Recruit inside it.

One more constraint nobody mentions: a design partner costs you real hours. Biweekly calls, feedback synthesis, custom hand-holding when your product breaks. Twelve partners at two hours a month each is a part-time job. If you're solo, start at five.

How do you find design partners when nobody knows who you are?

Cold outreach, and it's not a fallback. It's the better option. A stranger who says yes with no relationship and no social obligation is a far more honest signal than a friend doing you a favor.

Strella recruited all 12 of its design partners through cold LinkedIn outreach and deliberately skipped warm intros. Lydia Hylton's reasoning is worth stealing: it's much harder to convince a stranger on the internet than someone doing you a favor, so if you can get a stranger to become a design partner, you likely have something.

The channels that work, roughly in order of yield:

1. LinkedIn search by exact title and industry. Not "operations." "Head of Revenue Operations at a 50 to 200 person fintech." Specificity is what makes the message land.
2. Communities where your ICP complains. Slack groups, Discords, subreddits, industry newsletters. Read for a few weeks first. Then reach out to the people whose posts describe the exact problem you're solving, quoting their post back to them.
3. Job postings. A company hiring three people to do the thing you automate has just published its pain in public, with a budget attached.
4. Accelerator cohorts and alumni, if you're in a program. High trust, and half of them are either your ICP or one intro away from it.
5. Investor intros. Useful, but treat the yes with suspicion. Some of it is politeness toward your investor.

Your outreach message should ask for a 20 minute conversation, not a demo. You don't have a demo. Name the pain in the first line, say what you're trying to build, say you're looking for a small number of companies to shape it, and stop. Four sentences. The founders who get replies are the ones who sound like they already understand the job, not the ones who sound like a product launch.

Before you send anything, write down who you're targeting and why, because your outreach is only as good as your segment definition. You can do that in a spreadsheet, a Notion doc, or a planning tool like Foundra that walks first-time founders through ICP definition and go-to-market alongside the rest of the plan. The format matters less than actually writing it down, since an unwritten ICP quietly expands to "anyone who replies."

What do you offer a design partner, and should they pay?

Offer influence first, price second. The thing a good design partner wants most is a product built around their workflow instead of somebody else's, and that's something only you can give and no incumbent will.

The standard package looks something like this: free or heavily discounted access during the build phase, locked-in preferential pricing when you launch (commonly cited ranges land around 30% to 50% off list for the first 12 to 24 months), direct access to the founders, and a real seat at the roadmap table.

Should they pay something during the program? If you can get it, yes. Payment is the cleanest possible signal of intent, and practitioner write-ups tend to suggest that if you charge, charge at least 10% of expected contract value, because below that the commitment isn't real. But a paying design partner isn't mandatory. What is mandatory is a commitment that costs them something: guaranteed hours, workflow access, or a named executive sponsor who'll be on the calls.

What you don't offer is equity. Advisors cost equity. Design partners cost a discount and your time. Handing out warrants to your first five customers is a cap table problem you'll be explaining for years, and it buys you nothing you couldn't get with a better discount.

And the deal has to expire. Indefinite free access isn't a design partnership. It's a support contract you're paying for.

What goes into a design partner agreement?

One page, covering six things: what you're testing, what access they're giving you, the meeting rhythm, how long it runs, what happens to feedback and IP, and what the conversion conversation looks like when the term ends.

You don't need to draft this from scratch. Common Paper publishes a free standard Design Partner Agreement, currently at version 1.3, put together by a committee of attorneys from both vendor and procurement sides. It uses a short negotiated cover page plus standard terms hosted online, which means you're arguing about four fields instead of 14 pages.

The clause first-time founders miss is feedback ownership. Under the Common Paper standard, the provider retains all rights to the product, including features created in response to feedback, and the partner assigns their rights in that feedback to the provider. Get that in writing before someone's VP suggests a feature and then asks, six months later, whether they own it. Confidentiality matters too, in both directions, because they're showing you internal workflows and you're showing them something unfinished.

Two things worth adding that boilerplate usually skips. First, a hard end date, with a specific conversion date and price. Second, written success criteria: what has to be true at the end for both sides to call this a win. Without those, the program doesn't end. It just fades.

How do you run the program so it ends in revenue?

Set a hard deadline and a binary ask: go paid, or don't. Enthusiasm during the program means very little. Conversion at the end means almost everything.

The mechanics that work are boring. Biweekly calls on a fixed schedule. A shared doc of what changed since last time. A running list of requests with your actual priority order visible, so partners can see when they're outvoted and why. Strella met with each of its 12 partners biweekly across the whole program, and every one of them converted at the deadline. That's the outcome you're designing for.

Watch what the program teaches you about pricing, because that's the underrated output. Ada learned from real procurement conversations that enterprise buyers wanted predictable annual commitments rather than outcome-based billing tied to individual resolved tickets. Strella landed on seat-based pricing instead of per-project billing, specifically because per-project created budget approval friction every time someone wanted to use it. Neither of those came out of a spreadsheet. They came out of watching how customers actually buy.

Then hold the line at the deadline. "We love it, can we keep going free for another quarter" is a no. It's the most useful data point in the entire program, and founders routinely talk themselves out of hearing it.

If you want to go deeper on the interview mechanics behind these calls, we've written a separate walkthrough on customer discovery interviews, and the free tools cover the ICP and market sizing work that should happen before you start recruiting.

What kills design partner programs?

Four things, and they're all avoidable.

Building to one loud voice. Your most engaged partner is not your market. If a request only comes from one company, it's custom work, not a roadmap item.

No end date. Programs without deadlines don't fail, they just dissolve. Six months in you're doing free implementation for companies that were never going to buy.

Recruiting friends. A warm intro who says yes as a favor will also say nice things as a favor, and you'll believe them, because you want to.

Confusing usage with willingness to pay. A partner logging in daily for free tells you the product is useful. It tells you nothing about whether it's worth $2,000 a month. Only the invoice answers that.

Key takeaways

• A design partner shapes a product that doesn't exist yet. A beta user tests one that does. Recruit for the first.
• Start before you build. Ada's founders worked support desks at seven companies pre-code; Strella recruited 12 partners before the product was finished.
• Five to 12 partners in a single ICP is the working range. Narrow beats numerous.
• Cold outreach is the stronger signal, not the weaker one. A stranger's yes is worth more than a friend's.
• Offer influence and preferential pricing. Never offer equity.
• Use a one-page agreement (Common Paper's free template is at v1.3) and settle feedback ownership up front.
• End with a hard deadline and a binary conversion ask. Enthusiasm is noise, conversion is signal.

FAQ

What is a design partner program?

A structured pre-launch arrangement between a startup and a small group of target customers who co-develop the product in exchange for early access, roadmap influence, and preferential pricing. It's expected to end with those partners converting to paying customers.

How many design partners should I recruit?

Most practitioners recommend five to 12. Enough to see patterns across your ICP, few enough to stay high touch with each one. If you're a solo founder, start closer to five, since each partner realistically costs you a couple of hours a month.

Should design partners pay during the program?

Ideally yes, even a token amount, because payment is the clearest proof of intent. Common guidance is at least 10% of expected contract value if you charge at all. If they don't pay, get a different form of real commitment: guaranteed hours, workflow access, or a named executive sponsor.

Do design partners get equity?

No. Equity is for advisors. Design partners are compensated with discounted pricing and founder access. Warrants for early customers create cap table complexity that buys you nothing a better discount wouldn't.

Where do I find design partners if I have no network?

Cold LinkedIn outreach targeted by exact job title and company profile, communities where your ICP discusses the problem, and companies posting job listings for the work you're automating. Strella recruited all 12 of its design partners cold, on purpose, because a stranger's yes is a more honest signal.

How long should a design partnership last?

Long enough to build and test the core workflow, typically one to two quarters, with a fixed end date set at the start. Open-ended programs stop being validation and start being free implementation work.

What if a design partner won't convert at the end?

That's useful, not a failure. Ask exactly what would have made it a yes, and whether the blocker was price, priority, or product. One non-conversion is data. Four out of five is a signal to revisit the segment or the problem.