On this page
A design partner is an early customer who helps you shape a product before it launches, in return for early access, influence over what gets built and usually a discount. To get design partners, write down the problem and the customer you are building for, list people who have that problem badly, qualify them on urgency and decision power, ask three to seven of them for a time-boxed commitment, put the terms in writing, meet every week, and end each partnership with a decision: they pay, or you part ways.
Most advice on design partners is written for venture-backed software startups with a sales team and a lawyer on call. If you are building alone, the idea is the same but the limits are different.
You can only run as many weekly calls as you have hours, and every hour spent on a partner who will never pay is an hour not spent building.
This guide walks through the seven steps to find and run design partners, then answers the questions people ask next: how many you need, whether design partners should be paid, and what goes in a design partner agreement. It ends with a complete worked example and the mistakes that waste a design partnership.
One note on the term: this is about design partners in the startup sense, not design agencies that use the name.
How to Get Design Partners in Seven Steps
Work through these in order. Each step narrows the list, and the narrowing is the point: five committed partners teach you more than twenty polite ones.
- Write down the problem and the customer. One sentence for the problem, one for the person who has it. "Freelance designers lose a day a month chasing late invoices" is specific enough to find people. "Small businesses need better tools" is not. If you have not tested the problem yet, start with our guide to problem-solution fit.
- Build a long list. Start with warm introductions: past colleagues, clients, people who replied to your posts. a16z's framework for finding a design partner recommends warm introductions first, then public posts on X or LinkedIn and targeted cold outreach. Aim for 20 to 30 names.
- Qualify every name. Keep only people who match on four things: they have the problem often, solving it is a priority, they can decide to use your product (or get it approved), and they will give blunt feedback. Someone who is enthusiastic but is not the person who would use or buy the product is a polite conversation, not a design partner.
- Make a clear ask. Say what you want from them (a weekly 30-minute call, real use of the product, honest feedback) and what they get in return (early access, a say in the roadmap, a lower price later). A vague "would you like to help?" gets a vague yes.
- Put the terms in writing. A short agreement sets the length, the meeting rhythm, who owns the feedback and what happens at the end. Common Paper publishes a free standard version, covered in the agreement section below.
- Run it every week. Hold one longer kickoff to agree the three or four problems you will solve, then a short weekly check-in: what they tried, what broke, what you shipped, what they need next. Keep a shared chat channel for anything in between.
- End with a decision. At the agreed end date, each partner either becomes a paying customer, extends with a reason, or leaves. A partnership with no end date drifts into free consulting.
Aziz's take: Step 3 is where most founders cheat. You will want to keep the friendly people who say yes quickly. Keep the ones who are annoyed by the problem instead. Irritation predicts usage, politeness does not.
What Is a Design Partner?
A design partner is a customer who takes on the risk of working with a product that is not finished, because their problem is urgent enough to be worth it. In return, you build around their needs more closely than a normal supplier would.
Jake Stein of Common Paper, in How To Work With Design Partners, describes the relationship as co-creation rather than a sale.
The term gets mixed up with beta testers and pilots. They are different jobs:
| Design partner | Beta tester | Pilot | |
|---|---|---|---|
| When | Before the product is defined | Product built, being polished | Product finished, being evaluated |
| What they do | Shape the problem, features and price | Report bugs and rough edges | Test whether it solves their problem |
| Commitment | Weekly calls for months | Use it and report issues | A trial with agreed success measures |
| Goal | Learn what to build | Make it work properly | Win a full contract |
Design partners belong to the earliest stage of a business, before you have a product people pay for. Our guide to startup stages shows where that sits, and our guide to what an MVP is covers what you build alongside them.
How Many Design Partners You Need
The sources that rank for this question do not agree on one number, but they agree on the shape: a handful, not dozens.
| Source | Recommended number | Reasoning |
|---|---|---|
| Common Paper | Five or fewer | So the founder can look after each relationship personally |
| Horizon Capital | Three to seven | Fewer than two risks building for one edge case, more than ten splits the feedback |
| a16z | Five to ten to start | More than 20 creates more expectations than a team can manage |
Sources: Common Paper's guide to working with design partners, Horizon Capital's founder's guide to choosing design partners and a16z's framework.
If you are building alone, plan for three to five. The limit is your calendar: five weekly calls, plus the notes and the fixes that follow each one, can fill two working days a week. Signing a sixth partner usually means one of the first five gets less attention, and the feedback gets worse for everyone.
Should Design Partners Be Paid?
You do not pay design partners. The real question is whether they pay you, and there are three common answers:
- Free. No money changes hands during the partnership. a16z argues feedback matters more than payment early on, because pricing talks can slow down building, while still treating willingness to pay as a good sign.
- Discounted. Partners pay a reduced price, or agree now to a discounted price from launch. Common Paper notes design partners typically get a steep discount, and recommends agreeing future pricing and the point at which they become regular customers.
- Paid upfront. Partners pay part of a first contract before launch. Mika Reyes, in How to Run an Effective Design Partnership, recommends asking for 10% to 50% of the contract value upfront, and never less than 10%.
Whichever you choose, write down the price they will pay after launch before the partnership starts. A partner who has agreed a number in advance is deciding whether the product is worth it. A partner who has never discussed money is deciding whether to start paying for something that used to be free, which is a much harder yes.
Aziz's take: If you are bootstrapping, ask for some money, even a small deposit. It is the fastest way to find out who has the problem badly enough. A partner who will not pay anything before launch is telling you something about whether they will pay after it.
What Goes in a Design Partner Agreement
A design partner agreement is short, usually a few pages, and much lighter than a full customer contract. Common Paper publishes a free Design Partner Agreement that anyone can use and modify under a CC BY 4.0 licence. Its sections cover the points every agreement needs:
- The program: early access to the product, and what each side commits to, such as feedback sessions and their frequency.
- Fees: whether the partner pays anything, and how much.
- Term and termination: how long it runs and how either side can end it.
- Confidentiality: what each side must keep private.
- Intellectual property: you keep the product, and the feedback partners give you belongs to you.
- Warranties: a clear statement that the product is unfinished and comes with no guarantees.
The intellectual property clause is the one not to skip. Common Paper points out that a letter of intent does not assign intellectual property, and investors or buyers of your business will later want proof that people who shaped the product handed over their rights to it.
The standard also leaves out limitation of liability and data privacy terms, so add those if your product handles customer data.
A Worked Example: Design Partners for a Solo Founder
Here is a full design partner program for an illustrative founder building an invoice-chasing tool for freelance designers. The numbers are made up to show the method, not taken from a real business.
Steps 1 to 3: from 26 names to 5 partners
| Stage | Count | What happened |
|---|---|---|
| Long list | 26 | Former colleagues, past clients and people who replied to one LinkedIn post about late invoices |
| Had a call | 14 | A 20-minute call about the last invoice they chased, not about the product |
| Qualified | 7 | Chase invoices every month, have tried a workaround, decide their own tools |
| Signed | 5 | Two said yes but could not commit to a weekly call, so they went on a waitlist |
The calls in the second stage follow the method in our guide to interviewing customers the right way: ask about the last time the problem happened, not whether they would like a product that fixes it.
Steps 4 and 5: the terms
- Length: 12 weeks, starting at a 60-minute kickoff.
- Partner commits to: a 30-minute call each week, sending real invoices through the tool, and one written review at the end.
- Founder commits to: a fix or feature shipped every week, and a reply in the shared channel within one working day.
- Money: a $50 deposit now, credited against the first year, and a price of $15 a month from launch instead of the planned $25.
- Paperwork: the Common Paper standard agreement, with the term, fees and the 12-week end date on the cover page.
Steps 6 and 7: what the 12 weeks produced
| Partner | Week 12 outcome | What the founder learned |
|---|---|---|
| A | Converted at $15 a month | Reminder emails matter more than the dashboard |
| B | Converted at $15 a month | Wanted reminders sent from their own email address |
| C | Converted at $15 a month | Asked for late-fee wording that matches their contract |
| D | Extended four weeks | Invoices through an agency, needs a second approver |
| E | Ended, deposit refunded | Only one late payer a year, so the problem was not urgent |
Three of five converted, one needed a feature the founder had not planned, and one turned out never to have the problem badly enough. Partner E is not a failure of the program. It is the qualification step being corrected by real use, which is exactly what the 12 weeks are for.
What Goes Wrong With Design Partners
- Building for one partner. The loudest partner asks for the most. If only one of five needs a feature, it goes on a list, not into the product. a16z warns against building custom software for a single customer.
- Too many partners. Each partner adds a weekly call and a list of requests. Past five, a solo founder spends more time managing partners than building.
- Selling yourself instead of the product. If partners are happy because you fix things for them by hand, you are running a consulting business. The product has to do the work by the end of the partnership.
- No end date. Without a date, nobody has to decide. Set 60 to 90 days, the length Horizon Capital suggests for a first trial, or up to a few months for a larger product.
- Never discussing price. Leaving money until launch day turns a design partner into a free user who is surprised by the bill.
- No written terms. A handshake does not settle who owns the feedback or what happens at the end, and a letter of intent does not assign intellectual property.
Running design partners well is one of the strongest ways to test whether you are getting close to product-market fit, because paying partners who keep using the product are its earliest evidence.